After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
-
After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
On forking the Web
@dillo > Text should be able to wrap the screen size, so that the same document can be read both in small and large screens.
What about custom layouts? If you don't intend to include any CSS into the fork, then surely tables will be a part of the markup, and therefore people will abuse them for layouts?
-
After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
On forking the Web
> So it would need to be reviewed if HTML/XML is a suitable format for simple parsing.
I haven't implemented a browser, yet, but my initial reaction to this is that XML comes with schemas, which would be very useful for enforcing a grammar. The tools already exist. Don't throw out the baby... etc.
-
> So it would need to be reviewed if HTML/XML is a suitable format for simple parsing.
I haven't implemented a browser, yet, but my initial reaction to this is that XML comes with schemas, which would be very useful for enforcing a grammar. The tools already exist. Don't throw out the baby... etc.
@dillo I could even imagine that XML namespaces could come in handy to define a core grammar and allow for extendability, without changing the core every week. Maybe that's a terrible idea, and we would end up with each website coming with a list of extensions the browser needs to support. On the other hand, can't be worse than what we have now.
Could be nice if the browser would just ignore extensions it doesn't support and that then has to be considered when implementing a website. 
-
After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
On forking the Web
@dillo maybe consider:
Absolute URLs are exclusively for hyperlinks to another webpage.
Webpages should have been restricted to load files only by relative URLs & never load any file by absolute URLs.
Also, per website style design was a terrible UX and accessibility mistake
#Stylesheets should've been something you install in your own browser such that "the web" would have the uniform look and feel you prefer.
Just a thought
-
@dillo I could even imagine that XML namespaces could come in handy to define a core grammar and allow for extendability, without changing the core every week. Maybe that's a terrible idea, and we would end up with each website coming with a list of extensions the browser needs to support. On the other hand, can't be worse than what we have now.
Could be nice if the browser would just ignore extensions it doesn't support and that then has to be considered when implementing a website. @dillo Maybe different extensions to the markup could be supported via different plugins in the browsers.
-
@dillo Maybe different extensions to the markup could be supported via different plugins in the browsers.
@i_dabble @dillo when it comes to extensions, i think having a standard extensions body (like how irc has ircv3, and how xmpp has xeps) is a good approach, and the extensions themselves should always be designed in such a way that they are purely optional
if an extension becomes ubiquitous enough though, it should become a part of the core markup
-
@dillo maybe consider:
Absolute URLs are exclusively for hyperlinks to another webpage.
Webpages should have been restricted to load files only by relative URLs & never load any file by absolute URLs.
Also, per website style design was a terrible UX and accessibility mistake
#Stylesheets should've been something you install in your own browser such that "the web" would have the uniform look and feel you prefer.
Just a thought
@DLC @dillo i don't think stylesheets are fundamentally flawed, but i do think for certain things the website should be able to specify for example the layout, and a few cases benefit also from things like text colours (code highlighting in blog posts)
it should be minimalised, but style shouldn't be banned
-
@i_dabble @dillo when it comes to extensions, i think having a standard extensions body (like how irc has ircv3, and how xmpp has xeps) is a good approach, and the extensions themselves should always be designed in such a way that they are purely optional
if an extension becomes ubiquitous enough though, it should become a part of the core markup
-
After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
On forking the Web
@dillo That sounds like #geminiprotocol (https://geminiprotocol.net/) in many ways. I assume you know about it, so I wonder why it is not a good candidate in your eyes. Too restrictive (no inline links)? Too different (no HTTP)?
-
@DLC @dillo i don't think stylesheets are fundamentally flawed, but i do think for certain things the website should be able to specify for example the layout, and a few cases benefit also from things like text colours (code highlighting in blog posts)
it should be minimalised, but style shouldn't be banned
@SRAZKVT I don't think so either, but they belong in the client? Not per website…
Let the website declare the layout it prefers:
<section layout="weblog, article">
Use semantic tags:
<note layout="footnote">text</note>
<note layout="panel">text</note>
<bq style="code:APL">code</bq><em font="color: red" >…</em>
<table id="tab1" src="rel/url/table.cvs">
Desc
</table>See <table id="tab1" />
<figure id="fig1" src="rel/url/img.jpg">
Desc
</figure>See <figure id="fig1" />
-
After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
On forking the Web
@dillo I remember reading the HTML 4.01 spec forwards and backwards, marveling at how well written it was. I'd start from it again and only backport the good parts from HTML 5: structural elements like header / nav / footer, newer HTML entities like ☆ and stuff like that. Might have to drop a few things in the process.
Heck, let's go back to HTML 3.2 and start again from there, like text browsers did.
-
After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
On forking the Web
From the orange site, "Strict grammar for declaring documents is merely a fetish".
Isn't that the best name for a document format to be load in the #Dillo browser?
-
@DLC @dillo i don't think stylesheets are fundamentally flawed, but i do think for certain things the website should be able to specify for example the layout, and a few cases benefit also from things like text colours (code highlighting in blog posts)
it should be minimalised, but style shouldn't be banned
@SRAZKVT @DLC the problem with CSS is not so much in design of CSS itself but in the complexity of HTML which make each page have its own set of unique CSS rules.
I agree with authors being able to suggest a set of styles, but those should be optional on the client. That way you can reliably set your own scheme for all the pages **and still be sure that it will reliably work**.
This is also important for readability, not only for the aesthetics of the page.
-
@SRAZKVT @DLC the problem with CSS is not so much in design of CSS itself but in the complexity of HTML which make each page have its own set of unique CSS rules.
I agree with authors being able to suggest a set of styles, but those should be optional on the client. That way you can reliably set your own scheme for all the pages **and still be sure that it will reliably work**.
This is also important for readability, not only for the aesthetics of the page.
@SRAZKVT in any case, for this initial approach I'm only considering structure not presentation.
Ideally it should be possible to output three formats: screen, print and non-visual output.
It is probably a good idea to start from the non-visual output and work backwards from there, so accessibility is guaranteed by design.
-
R relay@relay.infosec.exchange shared this topic
