3 ms·

Would there have been a way to avoid this mess? - a browser must reject any invalid HTML in order to force the developers to fix their HTML - a browser mus

Would there have been a way to avoid this mess? - a browser must reject any invalid HTML in order to force the developers to fix their HTML - a browser must try hard to make sense of messed up HTML, otherwise users will switch to a competing browser that renders the mess for them Theoretically all browser vendors could coordinate so that everyone rejects invalid HTML, but there is probably no good way to avoid defectors. Why did this not happen for other technologies? My first thought was that there is no compilation step which allows forcing the developer to fix things without giving the end user any power through their choice of browser. But that seems not quite right, why do Bash or Python or your C++ compiler not make a best guess what your code is supposed to do? Because there is or was only one dominant implementation and therefore no competition? Because document markup is much more robust against small errors and probably remains readable while your code likely just crashes? That is probably one of the most important ones, I think. What role did browser specific features, evolving standards and incomplete implementations play? What is the end result? Nothing for the end user, they do not care whether the browser has to deal with nice HTML or a mess. Developer writing HTML get to be more sloppy at the price of a lot of additional complexity and pain where ever code has to deal with HTML. This might actually have some negative impact on end users because of bugs or security issues stemming from the additional complexity. Maybe it made HTML somewhat more accessible to the casual user as they could get away with some mistakes. But was this worth it, could better tooling not have achieved the same with good error messages helping to fix errors?

lifthrasiir 3y ago
It is not really the mess---see the next chapter, 13.2 Parsing HTML documents, to see the actual mess. In fact, the HTML specification defines two concrete syntaxes for HTML where the first one is for `text/html` and another is for `application/xhtml+xml`. The latter has been never deprecated (thought the name XHTML was abolished). Moreover the spec states that: > Some authors find it helpful to be in the practice of always quoting all attributes and always including all optional tags, preferring the consistency derived from such custom over the minor benefits of terseness afforded by making use of the flexibility of the HTML syntax. To aid such authors, conformance checkers can provide modes of operation wherein such conventions are enforced. In the other words it recognizes the benefit from explicit tags, but also recognizes the benefit from optional tags. So they are equally conforming.
solardev 3y ago
Historically this was tried as XHTML Strict. It never caught on much and was soon forgotten about. https://en.wikipedia.org/wiki/XHTML https://en.wikipedia.org/wiki/XHTML At the end of the day, HTML's flexibility as a markup language is what made it popular and usable by anyone, and ambiguity is the price we pay for it. These days the DOM semantics are even less important as everything is done in JS anyway for all but the simplest documents
- danbruc 3y ago
  HTML was essentially always rigorously defined through a SGML DTD. XHTML also conforms to a DTD which additionally conforms to XML which is itself a restricted subset of SGML. SGML offers huge flexibility, for example with regard to implicitly closing tags or redefining all kinds of aspects; you could easily replace the angle brackets with whatever you want and have your HTML document look like (START div)Hello (START b)world\b/!\div/ why ever you would want this. But despite all the flexibility offered by SGML and because probably nobody implemented HTML parsing by using a SGML parser, we ended up with malformed HTML documents who's interpretation was essentially defined by whatever the ad hoc HTML parser implementations in browser did. HTML5 finally abandoned the idea of basing HTML on SGML and a DTD and instead essentially formalized the status quo of HTML parsing and put it into the specification. At least this is my understanding as a non-web developer who gets to work with HTML only occasionally.
  - solardev 3y ago
    The informality of HTML wasn't solely a matter of markup strictness though. There were too many differences in CSS rendering (ACID tests), Javascript runtimes, SVG and PNG rendering, scrollbar and border and frame and iframe displays, etc. With so many variables, it couldn't NOT be a browser dependent implementation. The W3C was too strict where it didn't really matter (the basic markup) and too loose where it did matter (everything else).
    - danbruc 3y ago
      A lot of this is also hindsight. HTML started as a document markup language, so the structure was important but not the exact layout details. This was certainly considered a feature, everyone could make documents look the way they preferred. At that time probably nobody imagined that HTML would eventually be used to build controls and then entire applications out of them. Also there was no specification right from the start and the feature set was very limited, so that everyone started implementing their interpretation of HTML and adding their extensions. Trying to combine and standardize all the things existing in the wild would necessarily be a hard task. Many early extensions were probably also quite ad hoc and even if not they most likely did not take into account interactions with extensions from others. But in the end this could probably never have happened much differently, future developments and requirements could not be known in any detail and even if nobody would ever have spent a decade to write good specifications for a new technology which might or might not get adopted.
perilunar 3y ago
> force the developers to fix their HTML Developers? In the early days of the web it wasn't developers writing HTML. It was anybody who wanted to publish anything on the web. Real programmers didn't touch it. That is why browsers had to be tolerant of bad code.
- danbruc 3y ago
  They did not have to, they could have rejected broken HTML. Writing valid HTML is not really harder than writing invalid but still parsable HTML, it just requires some additional tedious work fixing all the mistakes. Would this have been bad for adoption? Maybe.
cush 3y ago
> Because document markup is much more robust against small errors and probably remains readable while your code likely just crashes? Exactly. The parser is designed to parse documents, not code. The document has a structure (like sections, paragraphs, tables, etc). When the structure doesn’t quite make sense, the parser still displays the content (the blog, story, words, etc). > But was this worth it, could better tooling not have achieved the same with good error messages helping to fix errors? You need to think about compatibility, especially backwards compatibility. If the standard was so strict that any error resulted in the browser rejecting to parse the document, then as the specification evolved every website would need to be updated. The lack of constraints around standards also means that different browsers can evolve and implement different features at different cadences.

lifthrasiir 3y ago

It is not really the mess---see the next chapter, 13.2 Parsing HTML documents, to see the actual mess. In fact, the HTML specification defines two concrete syntaxes for HTML where the first one is for `text/html` and another is for `application/xhtml+xml`. The latter has been never deprecated (thought the name XHTML was abolished). Moreover the spec states that: > Some authors find it helpful to be in the practice of always quoting all attributes and always including all optional tags, preferring the consistency derived from such custom over the minor benefits of terseness afforded by making use of the flexibility of the HTML syntax. To aid such authors, conformance checkers can provide modes of operation wherein such conventions are enforced. In the other words it recognizes the benefit from explicit tags, but also recognizes the benefit from optional tags. So they are equally conforming.

solardev 3y ago

Historically this was tried as XHTML Strict. It never caught on much and was soon forgotten about. https://en.wikipedia.org/wiki/XHTML https://en.wikipedia.org/wiki/XHTML At the end of the day, HTML's flexibility as a markup language is what made it popular and usable by anyone, and ambiguity is the price we pay for it. These days the DOM semantics are even less important as everything is done in JS anyway for all but the simplest documents

danbruc 3y ago
HTML was essentially always rigorously defined through a SGML DTD. XHTML also conforms to a DTD which additionally conforms to XML which is itself a restricted subset of SGML. SGML offers huge flexibility, for example with regard to implicitly closing tags or redefining all kinds of aspects; you could easily replace the angle brackets with whatever you want and have your HTML document look like (START div)Hello (START b)world\b/!\div/ why ever you would want this. But despite all the flexibility offered by SGML and because probably nobody implemented HTML parsing by using a SGML parser, we ended up with malformed HTML documents who's interpretation was essentially defined by whatever the ad hoc HTML parser implementations in browser did. HTML5 finally abandoned the idea of basing HTML on SGML and a DTD and instead essentially formalized the status quo of HTML parsing and put it into the specification. At least this is my understanding as a non-web developer who gets to work with HTML only occasionally.
- solardev 3y ago
  The informality of HTML wasn't solely a matter of markup strictness though. There were too many differences in CSS rendering (ACID tests), Javascript runtimes, SVG and PNG rendering, scrollbar and border and frame and iframe displays, etc. With so many variables, it couldn't NOT be a browser dependent implementation. The W3C was too strict where it didn't really matter (the basic markup) and too loose where it did matter (everything else).
  - danbruc 3y ago
    A lot of this is also hindsight. HTML started as a document markup language, so the structure was important but not the exact layout details. This was certainly considered a feature, everyone could make documents look the way they preferred. At that time probably nobody imagined that HTML would eventually be used to build controls and then entire applications out of them. Also there was no specification right from the start and the feature set was very limited, so that everyone started implementing their interpretation of HTML and adding their extensions. Trying to combine and standardize all the things existing in the wild would necessarily be a hard task. Many early extensions were probably also quite ad hoc and even if not they most likely did not take into account interactions with extensions from others. But in the end this could probably never have happened much differently, future developments and requirements could not be known in any detail and even if nobody would ever have spent a decade to write good specifications for a new technology which might or might not get adopted.

perilunar 3y ago

> force the developers to fix their HTML Developers? In the early days of the web it wasn't developers writing HTML. It was anybody who wanted to publish anything on the web. Real programmers didn't touch it. That is why browsers had to be tolerant of bad code.

danbruc 3y ago
They did not have to, they could have rejected broken HTML. Writing valid HTML is not really harder than writing invalid but still parsable HTML, it just requires some additional tedious work fixing all the mistakes. Would this have been bad for adoption? Maybe.

cush 3y ago

> Because document markup is much more robust against small errors and probably remains readable while your code likely just crashes? Exactly. The parser is designed to parse documents, not code. The document has a structure (like sections, paragraphs, tables, etc). When the structure doesn’t quite make sense, the parser still displays the content (the blog, story, words, etc). > But was this worth it, could better tooling not have achieved the same with good error messages helping to fix errors? You need to think about compatibility, especially backwards compatibility. If the standard was so strict that any error resulted in the browser rejecting to parse the document, then as the specification evolved every website would need to be updated. The lack of constraints around standards also means that different browsers can evolve and implement different features at different cadences.