3 ms·

> WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser. No they didn't. In fact

> WHATWG specifies how HTML actually works. You can follow the WHATWG standard and actually implement a web browser, or an HTML parser. No they didn't. In fact there are whole sections of the web standards that have no normative details on how to implement them other than descriptive notes about how the end results should function. It's a core reason why the Internet Explorer team had issues with CSS composition. It's UNDEFINED. Not sure what "standard" you're reading. No implementor wants to write against a "living standard" that you have to fork for a pinned date of what your rasterizer conforms to. WHATWG just links to a bunch of W3C actual versioned standards for the majority of specifications, most of which they didn't actually want to do work on. Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. Oh by the way, for people who actually read the specifications required to build a full web browser know that you still actually have to read WebKit, Chromium, and Gecko/Quantum codebases to understand what they have all silently agreed to do that isn't documented in the specifications. Why? Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want.

JoshTriplett 4y ago
> It's a core reason why the Internet Explorer team had issues with CSS composition I may be entirely mistaken, but isn't that just because WHATWG hasn't forked CSS away from W3C? Perhaps this is an indication that they should? > Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. They're something that was previously (as far as I know) completely undocumented, for which there's now a publicly documented algorithm that actually parses real web content. I think that's a good approach to provide for more things, and there are still plenty of things for which we don't have enough information like that. > Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want. Other than the utter garbage fire that is DRM, what other aspects are "intentionally undefined"? (Genuine question, would love to learn this, and would be unpleasantly surprised to find out that there are more.)
- andrewmcwatters 4y ago
  The most important ones..., like, how is a website drawn? Well, there's intentionally no such definition. And people wonder why Internet Explorer was so "bad," it wasn't that IE was bad, the standards themselves are garbage. Foundational visual user agent compositing is based today on CSS 2.1, and all CSS modules that build on top of it. Newer algorithms like flexbox have a formal algorithm with minor undefined details documented. The entire box model has no normative processing standard. It basically tells implementors, "Well, it should look like this, but you know if you want to do something different, that's fine. We don't tell you how to process glyphs or lines, so figure it out." Let me put it this way: there is no such thing as a collection of web standards that you can read today and implement a visually similar output to mainstream evergreen browsers. They don't exist. It's a farce, a lie, an illusion. However, you want to articulate it, there it is. Some subsets are formally defined and provide an actual algorithm you can implement, others describe an output with no processing model, further some standards exist which implicitly require that an undefined formal processing model exists. You MUST read existing web browser codebases and their explicit comments which specifically say things like, "This is what WebKit/Blink/Gecko/Quantum does, so we do it here, too," in order to create a web browser that does something similar. It can be as basic as line processing to as nuanced as box shadow processing, or as complex as how subtrees affect framebuffers. Yes, there are CSS properties dedicated to altering the implementation level details of a CSS processing model that doesn't formally exist. I know this specifically because I wrote a compositor that conforms to a subset of CSS 2.1 and additional CSS Modules. I STILL don't know how one writes a performant compositor today because what you're supposed to do is write one with a tile-based rasterizer and virtualized graphics commands. You can't just rasterize subtrees to framebuffers because the calculated CSS may result in dimensions larger than what your hardware can support for backing layers. Try finding that in the CSS standards. HTML parsing may have a formal standard now, I've never read it, but the fundamental truth is that it didn't matter if one existed anyway. There was no such thing as a conforming HTML parser prior to then, so what implementors did was read how other web browsers parsed HTML, because that was what users and developers expected, so that was the "true" standard. This problem still exists today, just in other places. There are also NO REAL TESTS. There are some manual, human-based, use-your-eyeballs web browser tests that exist, but you can't use them, because they rely on circular logic. You can't test a web browser by referencing some ground truth that is produced by the web browser when you're testing the exact features that generate said "ground truth." It's also impossible by definition to test browser rendered output because the output is implementation specific. There's no comparing output to a reference rasterization, because now you're dependent on properties that in the specification are left to the implementor to decide what they want to do.

JoshTriplett 4y ago

> It's a core reason why the Internet Explorer team had issues with CSS composition I may be entirely mistaken, but isn't that just because WHATWG hasn't forked CSS away from W3C? Perhaps this is an indication that they should? > Maybe HTML parsing is one of them, but HTML parsing mechanics are perhaps the least interesting of all of the specifications. They're something that was previously (as far as I know) completely undocumented, for which there's now a publicly documented algorithm that actually parses real web content. I think that's a good approach to provide for more things, and there are still plenty of things for which we don't have enough information like that. > Because further still, there are whole sections of web standards that are intentionally undefined and left to vendors to implement however they want. Other than the utter garbage fire that is DRM, what other aspects are "intentionally undefined"? (Genuine question, would love to learn this, and would be unpleasantly surprised to find out that there are more.)

andrewmcwatters 4y ago
The most important ones..., like, how is a website drawn? Well, there's intentionally no such definition. And people wonder why Internet Explorer was so "bad," it wasn't that IE was bad, the standards themselves are garbage. Foundational visual user agent compositing is based today on CSS 2.1, and all CSS modules that build on top of it. Newer algorithms like flexbox have a formal algorithm with minor undefined details documented. The entire box model has no normative processing standard. It basically tells implementors, "Well, it should look like this, but you know if you want to do something different, that's fine. We don't tell you how to process glyphs or lines, so figure it out." Let me put it this way: there is no such thing as a collection of web standards that you can read today and implement a visually similar output to mainstream evergreen browsers. They don't exist. It's a farce, a lie, an illusion. However, you want to articulate it, there it is. Some subsets are formally defined and provide an actual algorithm you can implement, others describe an output with no processing model, further some standards exist which implicitly require that an undefined formal processing model exists. You MUST read existing web browser codebases and their explicit comments which specifically say things like, "This is what WebKit/Blink/Gecko/Quantum does, so we do it here, too," in order to create a web browser that does something similar. It can be as basic as line processing to as nuanced as box shadow processing, or as complex as how subtrees affect framebuffers. Yes, there are CSS properties dedicated to altering the implementation level details of a CSS processing model that doesn't formally exist. I know this specifically because I wrote a compositor that conforms to a subset of CSS 2.1 and additional CSS Modules. I STILL don't know how one writes a performant compositor today because what you're supposed to do is write one with a tile-based rasterizer and virtualized graphics commands. You can't just rasterize subtrees to framebuffers because the calculated CSS may result in dimensions larger than what your hardware can support for backing layers. Try finding that in the CSS standards. HTML parsing may have a formal standard now, I've never read it, but the fundamental truth is that it didn't matter if one existed anyway. There was no such thing as a conforming HTML parser prior to then, so what implementors did was read how other web browsers parsed HTML, because that was what users and developers expected, so that was the "true" standard. This problem still exists today, just in other places. There are also NO REAL TESTS. There are some manual, human-based, use-your-eyeballs web browser tests that exist, but you can't use them, because they rely on circular logic. You can't test a web browser by referencing some ground truth that is produced by the web browser when you're testing the exact features that generate said "ground truth." It's also impossible by definition to test browser rendered output because the output is implementation specific. There's no comparing output to a reference rasterization, because now you're dependent on properties that in the specification are left to the implementor to decide what they want to do.