a drastically simpler set of web standards, so that making web browsers would become much simpler
Yes, yes, yes!
would be relatively fast moving, not focused on backwards compatibility
No, no, no! Constant churn is precisely the problem with the web today, as it is what creates all that complexity and bloat. What you really need is a simple and stable set of standards, ideally something that won't change in decades (somewhat like how ASCII has been) so that any implementors don't have to engage in mindless trendchasing.
In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2. Browsers like Dillo and NetSurf handle them well, and site like HN and Craigslist are an example of what the resulting format is like.
Unfortunately, HTML4 and CSS2 are severely underspecified, so actually implementing them interoperably without reverse-engineering is impossible. Oh, and some places where they _are_ clearly specified that specification is more or less broken. For example, implementing comment parsing per the letter of the HTML4 spec is extremely not-web-compatible, and I doubt that either Dillo or NetSurf do it...
Now if you know which things to avoid (e.g. never put "--" inside your comments) and don't care about "pixel-perfect" rendering or any sort of interesting layout, HTML4 and CSS2 are not terrible. But if you care about any of that, watch out for dragons.
And before someone brings up "tables" for "interesting layout": table layout is unspecified. In CSS2, and CSS3 for that matter. Not only is it unspecified, it's not entirely interoperable across browsers even now, after literally decades of reverse-engineering each other. And for extra fun, WebKit/Blink's implementation is definitely not interoperable with the IE (Trident) implementation most table-based layouts targeted... As one example, changing the order of rows in the table can change the column widths in Blink but not in Trident.
Anyway, if one wanted to start with HTML4 and CSS2, one _could_ try to turn them into proper standards that can be interoperably implemented. It would take quite a lot of effort to do that, I suspect. 50 person-years is my initial guess, but there are a _lot_ of unknowns involved and a lot would depend on how much of the HTML5 and CSS-post-2 work that defined things rigorously could be leveraged.
and don't care about "pixel-perfect" rendering or any sort of interesting layout
A common theme in all these "reinvent the web/browser" discussion is going back to the web as a hyperlinked document library and not an application platform, in which case pixel-perfect rendering is neither necesary nor even a goal.
For example, implementing comment parsing per the letter of the HTML4 spec is extremely not-web-compatible
HTML5 parsing is completely specified and definitely compatible, even the error cases. Any stream of bytes will turn into a DOM. (Philosophical question: are they even errors anymore, if all implementations will produce the same output?) Perhaps that would be a good starting point.
> A common theme in all these "reinvent the web/browser" discussion is going back to the web as a hyperlinked document library and not an application platform, in which case pixel-perfect rendering is neither necesary nor even a goal.
And how exactly would one even put this genie back in the lamp?
Which Markdown? There are so many to choose from....
In seriousness: Most Markdowns are 1) fairly similar and 2) sufficient for the vast majority of documents. If the goal is a stable, mature, and complete markup language, I'd be inclined to give LaTeX top billing. Markdown can of course generate LaTeX.
(La)TeX is a bad fit because its document model is based on paginated documents with a fixed page size, whereas HTML documents are intended for variable viewport size. LaTeX is to HTML as PDF is to EPUB.
LaTeX can, whether through the old model of dvi, or modern tools such as xlatex and pandoc, directly produce numerous document formats or "endpoints" as I consider them, including HTML, ePub, plain ASCII (or UTF-8) text, or paginated formats including ps, PDF, and djvu. LaTeX is not itself fundamentally print-oriented. The fact that it can and does produce excellent print-formatted output is a feature, not a bug.
What it is, and pointedly in ways that HTML lacks, is capable of intrinsically handling document-centric (not merely "print") elements including footnotes, endnotes, and formulae, all of which still require kludges after over a quarter century on the Web.
Markdown itself does not address several typographic or document conventions, including formulae, but also odd omissions such as underline and coloured text. Whether those get shimmed into Markdown, or an alternate (light- or heavy-weight) markup language is adopted, isn't clear, but those are very annoying lapses.
For the vast majority of documents, this does not matter. Most online content, say news media, use little more than paragraph, italic, and anchor elements. Even bold and list are rarely used. Authoring in Markdown should be almost wholly sufficient, but it's (La)TeX which has sufficient richness of expression to serve as the common underlying document format language.
Late edit: It also occurs that another principle angle of attack on HTMK alternatives, raised elsewhere in this thread, is that these cannot guarantee pixel-perfect presentation. That results in rather a "damned if you do, damned if you don't" situation: propopsed markup alternatives either cannot guarantee layout or over-guarantee layout. These objections rather want for consistency.
And how would one exactly get users to actually go with less featured browsers that only show hyperlinked documents, rather than sticking to the jack-of-all-trades browsers that they are using today?
> HTML5 parsing is completely specified and definitely compatible, even the error cases.
Counter argument: then why do conditional comments behave differently in each browser engine?
I am not talking about trident, but about CSS hacks for presto, gecko, webkit and blink as well.
If every browser would render as specified, we wouldn't have that outcome.
As developers test on webkit/blink primarily, chances are very likely things will not behave the same in other engines, and if blink violates the spec then everybody will also have to violate the spec.
The internet is built on such bad standards that you cannot even rely on HTTP to work correctly. 206 partial content headers behave differently among all web servers and proxies, and even nginx violates the spec there when it comes to multiple ranges, let alone chunked transfer encoding support.
Regarding your philosophical question: a markup language that accepts any byte sequence is clearly useless and a travesty of the concept of markup languages as an authoring format.
A little fact I wanted to add here: tables are unspecified when it comes to their display model. All display models have been changed to reflect the flow model (e.g. display: inline-block means display: inline flow-root behind the scenes).
But the funny thing is: they forgot to specify display: table and everything in it.
If you're interested in all the values that are only buried down somewhere in the specs, I'm building a CSS parser [1] that probably will never be completed.
HTML4 is specified as SGML vocabulary so I don't see the problem with parsing it, especially if you leave out the script element which introduced irregularities. Yes SGML was seen as complex in 1996, but it's relatively sane compared to the 2020's web stack. Developing a core SGML parser (with mandatory automaton construction and tag inference) can be done in about 0.5 man-years. And developing a CSS 2 renderer should be possible in less than 49.5 years.
Which of the view tens or so ascii's you mean? Probably us-ascii right? I.e. a thing so limited that it's only supports english and not even most of the other Latin writing based languages.
On the other side if we speak about plain text it hasn't be that stable at all for many years and only somewhat stabilized now with Unicode + utf-8 and utf-16 for legacy reasons. And even now we still frequently get Unicode updates.
The idea that us-ascii is enough/usable/acceptable for anything interfacing with users is IMHO a bubble limited to (small? part of) IT people from certain english native countries.
> In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2.
CSS2 isn't simple. It's also fundamentally unsuited for web applications, which IMHO was still also true for CSS3 until recently (css gid). I mean think about how frameworks (e.g. bootstrap) for years did all kinds of tricks to emulate a css gird like features.
Also HTML5 tags like header/footer/article etc. are a must have IMHO and something like custom elements for better composition and reuse are a must have, too.
The problem with the current complexity of the web lies in my opinion in the combination of how all kind of features where bolted on top of a foundation which wasn't designed for given use cases and many of this features being over engineered.
So I believe such an approach needs to fundamentally revamp or replace both the DOM API and CSS.
(But honestly tables suck bad time, I did wrote some table base hobby website back in 2009? or so and it wasn't nice (the experience, not the website which was quite fine). Sure basing a GUI on a grid is the best thing to do in many cases but tables are no grids. Grids are more flexible.)
I’m not defending table based layout but in fairness different device sizes was less of an issue back then because almost all browsing was done on a PC or Mac and thus dynamic layout wasn't even something you needed to considerate.
> different device sizes was less of an issue back then because almost all browsing was done on a PC or Mac and thus dynamic layout wasn't even something you needed to considerate.
It saddens me when Web sites assume they are in a full-screen window :(
Impressive that you remembered having two sets of nested parentheses going by the end of your comment and closed them correctly. Perhaps that's part of the problem...
I never really understood what people have against float. I think it works fine for most use cases and is not to difficult.
Now table layouts where quite a pain because they got very complex very fast. Flexbox and Grid are fine I guess, but I always found them a bit harder to understand than float and did not so much they offered that I needed.
This is true, <table> elements are for tabular data. But look at almost any web layout, and you will notice things are in a table layout most of the time. Even flexbox conceptualizes the flow of children as flex-direction: row/column. I think tabular concepts like rows and columns just make sense to humans making websites, and our 2D x/y axis conditioning.
The real issue with using <table> is semanticism, breaking DOM flow (sometimes creates issues for screen readers), and separation of concerns wrt data and style like you mentioned. Also, <table>s are hard to style over, like wtf is display: table-cell? Nobody seems to know.
But the number of times I see a colleague or fellow frontend cretin re-creating a tabular interface with a bunch of <div class="row"> etc... or wondering how to dynamically size the nested columns to fit the largest cell, I remind them: just use a table. Please.
You might notice that Hacker News layout uses <table>.
All I can say is whatever, man. The semantic web and all the RDF tuple goodness we were supposed to get is mostly a dead dream. Make whatever works for your users. Accept that things aren't going to be pure and perfect. If tables gets me to where I need to be, then that's what I'll use. Worked 20 years ago, works now, will work 20 years from now too.
Bring back DSSSL. After all, what language has a better ratio of fundamental simplicity to expressive power than Scheme? Much of the emergent complexity of styles is due to CSS selectors being intentionally non-Turing-complete.
Ah, that’s meant as a qualitative figure of speech, not a measurable objective function. Intended to express that Scheme is a simple language that remains apparently simple even when you build tremendously powerful constructs within it and upon it.
In this case by contrast with CSS where no matter how much sophistication one tries to introduce into the styles its capabilities seem to be horizontally asymptotic or very substantially sublinear.
I reach for the word ratio because the concept (of two parameters whose magnitude varies and that would be meaningful in some relation) is a friend, and the word “better” is a writing trick to avoid having to define exactly what those are whilst still expressing the sentiment.
> I reach for the word ratio because the concept (of two parameters whose magnitude varies and that would be meaningful in some relation) is a friend, and the word “better” is a writing trick to avoid having to define exactly what those are whilst still expressing the sentiment.
The use of ratio is entirely appropriate for conveying this, even in non-technical settings (and such use is pretty common). But to my ear, there's a definite implication that the relationship involves the two things typically moving in the same direction (and roughly linearly) such that it's notable when they've moved in opposite directions. (It's still very much qualitative - we're not really going to be able to assign meaningful numbers). Had you spoken of complexity/power, I wouldn't have noticed anything unusual.
Even so, I only really commented because I was enjoying playing with the idea of a simplicity/power ratio being somehow informative.
Wouldn't the first stable release of HTML count as "a drastically simpler set of web standards" together with the fact that any browser should support it?
Everything else is to me a matter of compression. Netflix's success seemed to me 50% good marketing and content and 50% compression and data handling.
It is wrong to think that a webpage has some sort of canonical view on it. And FB, Twitter and even Forbes is all about generating the impression of group perspective being one thing as opposed to be views on one, perhaps elusive, thing.
HTML4 and CSS2 are drastically underspecified. Even for sites where that's a sufficient feature set, you need to reverse-engineer browsers to figure out error handling and such.
Yes, yes, yes!
would be relatively fast moving, not focused on backwards compatibility
No, no, no! Constant churn is precisely the problem with the web today, as it is what creates all that complexity and bloat. What you really need is a simple and stable set of standards, ideally something that won't change in decades (somewhat like how ASCII has been) so that any implementors don't have to engage in mindless trendchasing.
In fact, we already have a simpler set of web standards. It's called HTML4 and CSS2. Browsers like Dillo and NetSurf handle them well, and site like HN and Craigslist are an example of what the resulting format is like.