After taking a quick look at the "Prompt API" document, I decided to write some design notes towards a fork of the #Web.
-
@dillo
I despise the very concept of a "living standard" with the heat of a thousand fiery suns. -
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 would sure love to see this happen. I would definitely participate, the current web disgust me.
-
@dillo a subset of xml could be reasonable, but agree, it should be strict.
one big thing to do also would be handling security. would there be forms ? what about embedded pages (web iframes) ? what image formats would be required to support ? similarly, would the transport protocol be redone ? http is pretty bad, and newer versions are quite complex, surely something simpler is possible
other than that, though, i like the idea
i also think something like css , for styling (but also strict, and people use a preprocessor to expand if they need something better) would be good, allows each place to have a distinct style
@SRAZKVT I don't have definitive answers to many of those questions.
Ideally it should be transport agnostic, so we can transparently replace http for another one.
-
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 If we drop scripting (including css) and the expectation of the same rendering in all user agents (from what people expect user agents to do), it may make writing new user agents easy enough to have an appreciable effect, even without simplifying the HTML grammar a lot. And new user agents should support old websites written in non-XML HTML—reimplementations of Web-like things exist (for example gemini), but after all, I want a fork, not something new.
Does something exist or can we establish something like an open “small user agents group” or whatever where we can start by collectively writing on a website “Let it be known: User agents are henceforth not expected to implement CSS or JavaScript”?
-
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
Nice!
I have been basically doing this, (others to I think).
All my new sites have been very minimal html
with zero javascript. I have a wiki and a task tracker.
They both support convieniences like multi select check
boxes (select all / select none).
It's very nice, because I am interacting with data not
a "web page". They work in dillo. Sometimes I have
to fiddle with the caching headers on really dynamic
stuff.
-
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
