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
-
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 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
-
@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
@dillo also specifically about the prompt api, i'm pretty sure basically everyone except google opposes it right now (or at least has concerns with it)
-
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 One end of the spectrum is a 600-line markup language in which I can do grid 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
@dillo
I despise the very concept of a "living standard" with the heat of a thousand fiery suns. -
@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" />
️
