3 ms·

No, that's definitely not the worst part. The worst part is there is no nice way to convert the abstract language from CSS 2.1, the part that everyone cares abo

No, that's definitely not the worst part. The worst part is there is no nice way to convert the abstract language from CSS 2.1, the part that everyone cares about right before JavaScript integration, into a standards-compliant algorithm. Why? Because no definition for it exists. It is left as an exercise to the reader. WHATWG doesn't improve on this either, in fact, they completely leave it out, whereas at least W3C's original work makes it clear that it's descriptive and you need to figure out an algorithm that makes it work. Edit: The section describing the processing model for CSS is non-normative. The authors provide an example flow, but a normative algorithm doesn't exist for CSS.[1] [1]: https://www.w3.org/TR/CSS2/intro.html#processing-model https://www.w3.org/TR/CSS2/intro.html#processing-model

tannhaeuser 4y ago
FWIW, I know two (partial, kinda) formal specifications of CSS normal flow and float layout, both of which are finished ie dead projects: [1]: https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.pdf https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.... [2]: https://github.com/uwplse/cassius https://github.com/uwplse/cassius (not counting the 1990s constraint CSS effort). The first was merely part of a parallel compiler project and also covers table layout, whereas the second is a Racket (Scheme) program to formulate the HTML doc and CSS rules as a theory for submitting to z3 SMT to solve all kinds of decision problems (it can also produce a rendering). Not sure that's very helpful; it would be cool if W3C can invest some time into better specs (not just prose).