Hacker News Reader

Comment by andrewmcwatters | Hacker News Reader

CSS keeps getting larger and larger which I think on its face is actually fine, since all of the standards are extended modules. So if you think about it that way, as an implementor you can choose which standards you want to incorporate and have total coverage for particular parts of the spec.

But the state of CSS for implementors is still abysmal, in my opinion, and I'd like to see more of the spec formally defined for some of the most fundamental parts of it.

It would be nice if the spec matured for implementors, too.

Like, could we please get a formal definition of the CSS processing model? The lack of one means that particular events MAY OR MAY NOT exist in user agents.

Those events may exist in large implementations--and when a CSS standard eventually pops up to utilize those vendor specific events, some implementations may not even have them, because they process CSS in an entirely different way!

View on HN

If you want CSS to be the same across browsers then help implement CSS tests and file bugs

https://www.w3.org/Style/CSS/Test/Overview.en.html

https://web-platform-tests.org/

better specs are great, but tests will actually find the edge cases and lead to more convergence.

As someone who's recently been working on an implementation of CSS Grid, and reading through a lot of CSS specs, I completely agree. There's a lot that isn't in the specs. The CSS Grid one isn't even that bad, but the spec for "flow layout" (block and inline) looks like a complete mess.

An HTML5 moment for CSS would be very welcome.

Yes! You know exactly what I'm talking about!!

I'm hysterical about the state of affairs for these exact sorts of things, but comparatively almost no one is an implementor, so most people have no idea how bad it can be.

IIRC the way someone reimplemented flexbox was to take the layout tests and iterate until their implementation passed.

https://yogalayout.com/

Yes, but the fact that someone had to do this makes it clear that the spec isn't complete. A complete spec would state the algorithm unambiguously. You might still need to fix bugs based on tests, but you shouldn't need to be working about behaviour because it's unspecified.

Not my experience at all. It doesn't matter how well written a spec is. No tests = no conformance. End of story. Most people can't hold an entire spec in their head or think through all the ramifications of the edge cases. Even the spec writers. I work on several specs. I work with people who work on specs. They're all mortal. No test = divergence. Always and without fail.

There may be layout tests for flexbox (I haven't looked into them, because I don't care about them as much as normal flow) but there are basically no layout tests for CSS 2.1 that aren't fully manual.

So basically for 25 years, as far as I understand, no one said, hey given a set of known layout constraints and rasterization parameters, let's create automated tests.

For 25 years.

Maybe I'm wrong, but I keep looking for these tests and the ones that exist for normal flow are a nonstarter.

There was acid2, so merely "almost none" rather than actually none

This is why, I can only assert I can do "fullstack" for native applications on Windows and Android, for web development I am certainly on backend side, no way I can keep track of what CSS works where, and which incantations to make divs behave like native controls.

It's also nearly 100% guaranteed that while people say they're a master at CSS, there are probably only a miniscule amount of people who have read how CSS rasterizers actually work.

I'd almost bet there are probably more people who have reimplemented OpenGL in software than people who have read and understand how CSS compositors work.

For example, if you asked someone how user agents create backing tiles for CSS, they'd look at you like you spoke in a foreign language.

You totally don't need to know this stuff, but if you were doing say, high-perf UIs in WebKit (iOS), you'd probably at least want to know how to hint to WebKit that something needs its own render target or how to minimize subtree redraw.

I built massively performant large UIs for payroll systems on iPad years ago and found that if you optimized your UI just right, you could get smooth scroll performance that showed cracks in how fast the iPad was able to draw backing tiles at the time.

You'd get whole squares black scrolled into view while WebKit asynchronously drew in elements.

Why does a payroll system UI need game-engine level performance?

Reply on news.ycombinator.com