3 ms·
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,"
by 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.