7 ms·

Unfortunately, HTML4 and CSS2 are severely underspecified, so actually implementing them interoperably without reverse-engineering is impossible. Oh, and some

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.

userbinator 6y ago
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.
- tannhaeuser 6y ago
  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.
- bobthepanda 6y ago
  > 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?
  - taneq 6y ago
    Have HTML5 as an application platform and markdown or something as a hyperlinked document format?
    - dredmorbius 6y ago
      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.
      - majewsky 6y ago
        (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.
        dredmorbius 6y ago
        No it is not. 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.
tannhaeuser 6y ago
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.
cookiengineer 6y ago
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. [1] https://github.com/tholian-network/stealth/blob/X0/stealth/source/parser/CSS/NORMAL.mjs#L125 https://github.com/tholian-network/stealth/blob/X0/stealth/s...

userbinator 6y ago

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.

tannhaeuser 6y ago
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.
bobthepanda 6y ago
> 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?
- taneq 6y ago
  Have HTML5 as an application platform and markdown or something as a hyperlinked document format?
  - dredmorbius 6y ago
    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.
    - majewsky 6y ago
      (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.
      - dredmorbius 6y ago
        No it is not. 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.

tannhaeuser 6y ago

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.

cookiengineer 6y ago

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. [1] https://github.com/tholian-network/stealth/blob/X0/stealth/source/parser/CSS/NORMAL.mjs#L125 https://github.com/tholian-network/stealth/blob/X0/stealth/s...