5 ms·

In the Introduction: > IE6 had an interesting HTML parser. It did not necessarily produce a tree; rather it would produce a graph, to more faithfully preserve

In the Introduction: > IE6 had an interesting HTML parser. It did not necessarily produce a tree; rather it would produce a graph, to more faithfully preserve author intent. Ill-formed markup, e.g., , would result in an ill-formed DOM. This could cause scripts to go into infinite loops by just trying to iterate over the DOM. Huh, didn’t know that. It’s the sort of thing that makes me wonder, “hmm, was that what was happening that time all those years ago?” > The problem is I now have to determine which of these four options to make the other three browsers implement (that is, which do I put in the spec). What do you think is the most likely to be accepted by the others? As a reminder, the options are incestual elements that can be their own uncles, elements who have secret lives in the rendering engine, elements that change their mind about who their parents are half-way through their childhood, and quantum elements whose parents change depending on whether you observe their birth or not. That whole section is great reading, showing just a little bit of the madness that preceded the specification of HTML parsing, and how monumental a job it was.

itsbits 5y ago
> Huh, didn’t know that. It’s the sort of thing that makes me wonder, “hmm, was that what was happening that time all those years ago?” I think it was always a graph. I remember reading DOM implementation years ago, where a node will have siblings references as well making it graph DS.
- chrismorgan 5y ago
  Sure, you’ve always been able to access siblings directly from nodes, rather than having to go up and down again, but that’s just a shortcut rather than being an inherent part of the logical data structure, since nodes don’t own their siblings, but rather their siblings are computed from their parent’s children. This here is talking about the DOM actually producing a non-tree structure, where one text node is a child of multiple elements.
  - itsbits 5y ago
    check this implementation https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/ https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d... graph doesn't mean multiple parents all the time. if you have references of other nodes in current node data(not just as children) as long as you can travel across Data structure, enough to say it as graph structure.
sanxiyn 5y ago
This blog post explains IE6 DOM implementation in detail. https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/ https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d...
tragomaskhalos 5y ago
We can argue about whether or not "Be liberal in what you accept" is a well-intentioned but utterly terrible engineering principle overall, but surely it is beyond debate that when applied to HTML it has been incalculably costly over the years.
- heavenlyblue 5y ago
  And it also allowed the web to grow tremendously and in a decentralised fashion. Today’s web is more formalised but we have walled gardens everywhere. What is better?
  - ninju 5y ago
    I don't see how supporting malformed documents has allowed the internet to grow in a decentralized fashion? The decision of some website/internet property owners to decide to 'wall' themselves off has nothing to do with the desire to create well formed documents. They've done this walling off already
    - heavenlyblue 5y ago
      Nobody desires to to create well formed documents :) it’s just a rudiment of the technology we use, not the main objective
- lloydatkinson 5y ago
  I've always thought this was a terrible quote that has led people to create half arsed contracts, bad validation, and all round buggy software. "Be strict in what you accept and what you return." is a better methodology. You're right, look at what a dumpster fire HTML and general HTTP servers are under the hood as a result of building protocols on top of sloppy text formats.
trhway 5y ago
>Ill-formed markup, e.g., , would result in an ill-formed DOM. our parser back then would never produce ill-formed DOM, and in this case it would have produced DOM as if for - i.e. it would have inserted upon meeting to match the and would have dropped the unmatched as result after .
- fifilura 5y ago
 That is the DOM part yes. But it wouldn't solve the expected emphasized rendering of the supposed text after . The parser I know best would store a special pointer from the element to where it ends, i.e. the text element between and and keep track of that state to end rendering after passing the closing tag.
giancarlostoro 5y ago
Wow. That would explain the perception about IE being so slow. That's really hilarious to think about. Also might explain why XHTML needed to take off back in the day.
benibela 5y ago
I tried to build a non-tree HTML parser that stores tags would have become a linked list of four nodes --> --> --> To efficiently find siblings there are forward/backwards links from to like in a skip list. I have implemented this list, but never actually used it that way. It became too confusing. So I now remove mismatched tags, while creating the list, making it equivalent to a tree. Now I probably should rewrite it to not actually store closing tags.
- montroser 5y ago
 Sounds somewhat similar to linkedom[1], which performs nicely. [1]: https://github.com/WebReflection/linkedom https://github.com/WebReflection/linkedom

itsbits 5y ago

> Huh, didn’t know that. It’s the sort of thing that makes me wonder, “hmm, was that what was happening that time all those years ago?” I think it was always a graph. I remember reading DOM implementation years ago, where a node will have siblings references as well making it graph DS.

chrismorgan 5y ago
Sure, you’ve always been able to access siblings directly from nodes, rather than having to go up and down again, but that’s just a shortcut rather than being an inherent part of the logical data structure, since nodes don’t own their siblings, but rather their siblings are computed from their parent’s children. This here is talking about the DOM actually producing a non-tree structure, where one text node is a child of multiple elements.
- itsbits 5y ago
  check this implementation https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/ https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d... graph doesn't mean multiple parents all the time. if you have references of other nodes in current node data(not just as children) as long as you can travel across Data structure, enough to say it as graph structure.

sanxiyn 5y ago

This blog post explains IE6 DOM implementation in detail. https://blogs.windows.com/msedgedev/2017/04/19/modernizing-dom-tree-microsoft-edge/ https://blogs.windows.com/msedgedev/2017/04/19/modernizing-d...

tragomaskhalos 5y ago

We can argue about whether or not "Be liberal in what you accept" is a well-intentioned but utterly terrible engineering principle overall, but surely it is beyond debate that when applied to HTML it has been incalculably costly over the years.

heavenlyblue 5y ago
And it also allowed the web to grow tremendously and in a decentralised fashion. Today’s web is more formalised but we have walled gardens everywhere. What is better?
- ninju 5y ago
  I don't see how supporting malformed documents has allowed the internet to grow in a decentralized fashion? The decision of some website/internet property owners to decide to 'wall' themselves off has nothing to do with the desire to create well formed documents. They've done this walling off already
  - heavenlyblue 5y ago
    Nobody desires to to create well formed documents :) it’s just a rudiment of the technology we use, not the main objective
lloydatkinson 5y ago
I've always thought this was a terrible quote that has led people to create half arsed contracts, bad validation, and all round buggy software. "Be strict in what you accept and what you return." is a better methodology. You're right, look at what a dumpster fire HTML and general HTTP servers are under the hood as a result of building protocols on top of sloppy text formats.

trhway 5y ago

>Ill-formed markup, e.g., , would result in an ill-formed DOM. our parser back then would never produce ill-formed DOM, and in this case it would have produced DOM as if for - i.e. it would have inserted upon meeting to match the and would have dropped the unmatched as result after .

fifilura 5y ago
That is the DOM part yes. But it wouldn't solve the expected emphasized rendering of the supposed text after . The parser I know best would store a special pointer from the element to where it ends, i.e. the text element between and and keep track of that state to end rendering after passing the closing tag.

giancarlostoro 5y ago

Wow. That would explain the perception about IE being so slow. That's really hilarious to think about. Also might explain why XHTML needed to take off back in the day.

benibela 5y ago

I tried to build a non-tree HTML parser that stores tags would have become a linked list of four nodes --> --> --> To efficiently find siblings there are forward/backwards links from to like in a skip list. I have implemented this list, but never actually used it that way. It became too confusing. So I now remove mismatched tags, while creating the list, making it equivalent to a tree. Now I probably should rewrite it to not actually store closing tags.

montroser 5y ago
Sounds somewhat similar to linkedom[1], which performs nicely. [1]: https://github.com/WebReflection/linkedom https://github.com/WebReflection/linkedom