[andrewmcwatters]

None of this would be so difficult if the CSS specifications were well defined.

But they’re not, so we all have to more or less guess what the intrinsic algorithms for drawing fundamental aspects of the web are supposed to be.

Such a failure of the CSS specs.

[jeroenhd]

I've watched videos about implementing CSS fixes in Ladybird (https://www.youtube.com/@awesomekling) and whenever the web specs get pulled up, I find them pretty clear most of the time. There's a lot of context required if you want to read the details about one specific thing, but all the necessary context is usually linked and readily available if you need it.

That complexity does lead to bugs (and bugs in Chrome can become part of the de-facto standard if the Chrome devs don't fix the bug fast enough) but the spec itself seems quite complete in most areas. In the few areas that are underspecified, simply seeing what other browsers do usually fixes the problem as there's usually an overlap in behaviour between at least two out of three remaining browser render engines.

The basic algorithms and rendering steps are all laid out pretty well in the spec. Even Quirks Mode has a standard (https://quirks.spec.whatwg.org/), though that's far from complete as every browser has its own compatibility quirks because of browser detection and branded CSS properties.

I know CSS documentation used to be awful, but the current version of the WHATWG spec is quite readable in my opinion and doesn't leave as much room for confusion anymore.

[andrewmcwatters]

WHATWG doesn't control the box model specification or layout. There is officially no CSS processing model. The specifications are detailed implicitly.

[Centigonal]

Dumb question: if CSS is under-specified and everyone designs their sites for Chrome, could we analyze Chromium's CSS rendering code and use that to create a more well-defined CSS spec which other browsers can implement?

[sonofhans]

Perl was in exactly that situation many years ago. The specification for Perl 5.x was `perl` itself; if `perl` was found to conflict with the spec, sometimes the spec would change.

It was a nightmare, and part of the reason (I believe) that Perl 6 got so over-specified. It meant you couldn’t count on the spec, that you never knew if something was a bug or intended behavior.

HTML4 was in a similar situation. Microsoft and Netscape developed competing variations of under-specified features, leading to a decade of the worst Dark Ages for web development.

So if we use Chromium’s CSS engine, then either (a) Google now controls a fundamental part of the web (and there’s no evidence that they’ll behave in any sort of responsible manner), or (b) we now have the same specification problem.

Getting complex code and specs to agree 100% is a Hard Problem, unsolved almost everywhere. Giving more power to Google won’t help.

[vlovich123]

For a while while Google had a minority and everyone was still targeting IE instead of the standard, they would detect that and take a different rendering path even if it meant preserving broken behavior. At the same time they tried to fix/improve the spec and wage a publicity campaign against Microsoft for not following standards.

While that’s not necessarily a capability a smaller not well funded browser might have, certainly they have lots of forums to advertise “hey Google is doing this incorrect thing, this is how we detect existing sites relying on that buggy behavior, and this is how you fix it”. You could even show a banner while browsing “standard confirming vs not”. You leave that banner out for places the standard is underspecified to be fair and reinstitute it once you’ve got it clarified, assuming websites are still relying on those nonstandard paths / Chrome isn’t addressing the behavior.

That being said, it’s no surprise this is the situation when all commercial investment into browser tech is by commercial companies giving it away for free. Think about the hundreds of millions of dollars being pored in. That’s not out of the goodness of their heart and it’s going to be difficult to impossible for anyone else to compete.

For what it’s worth I think a huge regulatory improvement to monopoly laws would be an anti-dumping provisions for software. You’re not allowed to sell something below what it costs you to make (including accounting for R&D) and the only person’s effort your allowed to 0-rate is your own and any unpaid volunteers you convince to join you. It would mean that browsers would now cost actual money that could fund third party efforts (ie if my budget for browsers is X then maybe I want to invest in a browser that treats me better). Of course the challenge with this model is that it makes it hard to actually enforce. Are you giving a feature away for free or are you improving an existing product and it’s part of that overall cost? How do you budget recurring revenues for products that want to amortize the cost over periodic payments instead of upfront ones? Etc etc. I don’t necessarily know what the answers are. There may be none. But certainly Google’s control of the web comes from the fact that they’re poring in huge amounts of money to maintain a controlling interest over the thing that enables a good chunk of their revenue stream. It’s not as important to Apple and we see them not investing as heavily (it’s important for the product but it’s not intrinsically strategically as key hence the historic neglect). Same goes to Microsoft which ceded its spot in the internet ecosystem to Google back in the day.

Anyway, what I’m trying to say is that Google’s control won’t weaken because you cede to duplicate their particular implementation. Their control weakens when you can take away their market share and for a smaller entrant you want to replicate as much behavior verbatim as possible to lower friction for users. It doesn’t matter what the spec says. Aggressively prioritize what is important to customers and serve the market where Google is incapable of doing it. For example, memory usage is a trivial one to get them on. They’ve lost control of that beast and can’t figure out how to get better. Clobber them in the head over that failure. They can’t handle many simultaneous tabs. Make your browser work smoothly and without crashing or using terabytes of memory even if it’s handling 100k tabs. If I were to take on that endeavor, that’s how I would take on Google (and no, I wouldn’t use Blink as a starting point because you’re just picking up all the tech debt and you’re not going to do a better job than Google at trying to shovel shit away - you need to start greenfield like Chrome did and firefox and opera did for a time when they showed what a performance hog IE was and how it didn’t even have valuable features that people cares about). Similarly, ship the browser with adblock and actively fight websites that waste resources. Prioritize aggressively the user’s health and digital well being (meaningful privacy improvements by closing as many side channel data gathering techniques as possible) and respect the well being of the machine you’re running on.

[charcircuit]

>you need to start greenfield like Chrome

Chrome wasn't entirely greenfield. The rendering engine is a fork of webkit's.

[reitanqild]

Which was forked from KDE I think?

[Centigonal]

yep - KHTML!

[jitl]

tl;dr

[bfgeek]

The issue with this approach is that it would encode all the bugs and quirks into the specification which isn't a good idea.

(I'm an engineer on Blink's layout engine).

We've recently finished re-architecting Blink's layout engine, part of the reason why we did this investment was we were concerned that we couldn't fix WebKit era bugs (e.g. too many sites would depend on them due to our shared heritage). This makes other engines jobs (e.g. Gecko) super difficult as they'd need to encode even more quirks than they have time for.

I think we've broadly mitigated a large part of that risk. There are still large parts of CSS which are underspecified, e.g. tables/block/float layout. But its slowly getting better.

[sfink]

And this is kind of a huge deal. 3 different implementations rather than 2 is kind of like the old saying "never go to sea with two chronometers, take one or three".

I'm not saying Blink exactly matched WebKit anymore, before your re-architecture. But it shared a lot.

If you have a difference in behavior between 2 implementations, then it's easy to see think of it as saying one or the other is right. And which one is right will be partly influenced by the amount of exposure the feature has had, multiplied by market share. Which is not a great criterion to use if you want a spec that hangs together, especially if a reimagining like Servo is going to come along and rub against the grain of every arbitrary decision ever made.

[rtpg]

Is CSS under-specified? when I've been curious about some thing, there has been a pretty detailed spec. There are differences in behavior on newer things as things get worked out, but I feel like so much is due to actual bugs relative to the spec than the spec itself.

Is there an example of under-specification that sticks around in practice?

[ibash]

That’s basically what’s happening, chrome implements something, it gets put into the standard, some others choose to implement or not.

[nicoburns]

In many cases has already happened (although most of it was written when IE, Firefox and Opera were the browsers to align with and Chrome just implemented the spec). There are bits that are still underspecified, but work is already ongoing to specify those.

[MBCook]

Isn’t CSS, like so many things, limited by backwards compatibility? They can’t clean slate it and call it CSS 4, no one would bother.

Everything they do has to work with the old stuff, or be very explicit that you’re changing the rules (like adding “display: flex”).

I suspect there is also a fair amount of “this is what everyone did so try not to break it” in there too, much like HTML.

I’m not sure anyone could make a clean spec under those circumstances.

[Dalewyn]

No, backwards compatibility is the responsibility of the browser, a la quirks mode[1][2] in ye olde days.

HTML6 or CSS4 could have a fresh, clean start and there's nothing preventing that.

[1]: https://en.wikipedia.org/wiki/Quirks_mode

[2]: https://www.quirksmode.org/css/quirksmode.html

[tannhaeuser]

What's preventing that is the large installed base of sites on the 'net. Quite possibly, the majority of web content has already been created (1), and it's getting worse as old sites are shut down.

Also, Safari is a thing (and personally I prefer FF for webdev, though Moz is certainly working hard to turn me away).

(1) those worth reading anyway, rather than generated content

[madeofpalk]

What would be the point of that if no browser would support it?

See also, https://wiki.csswg.org/faq#versioning-css-fixing-design-mist...

[Dalewyn]

I'm not sure what you're getting at?

The browser landscape today is composed of practically just one browser: Chrome. It is easier than ever to get browsers (read: Chrome) to implement different rendering schemes based on identifiers or descriptors provided by web devs.

Supporting the latest and greatest is a great marketing ploy, browsers (read: Chrome) are incentivized to support them. Browsers that don't will be forced to support them lest they become even further irrelevant.

Quirks Mode happened, Quirks Mode V2 can happen.

[madeofpalk]

I think it is a very bad idea for a single browser vendor to deliberately subvert standards process and attempt to steamroll the web with their own proprietary tech!

[Dalewyn]

You're still not getting it. When there's only one browser to care about, it's easy to get it to support the latest and greatest standard.

W3C comes out with HTML6? Not supporting that would be terrible marketing, especially if other then-irrelevant browsers adopt it.

[rektide]

Really? The spec might maybe be hard? Perhaps? I don't know for sure.

But there is a long long long legacy of CSS Acid Tests that have been very well established & expected, that should guide most implementations to success.

I forget what it's called but a bunch of the major browsers get together each year & find a couple things to agree to focus on & make happen each year. Trying to just play catchup & go through the years catching up seems semi intuitive a path to getting to modern. I agree that maybe not all these specs have gotten great test suites set up, but I feel like CSS in general realized this was a problem we'll over a decade ago & upped their game. Maybe the situation has decayed since, I dont K ke, but would love more idea of where we lie atm.

[andrewmcwatters]

The old Web Standards Compliance Acid Tests aren't used by implementors.

[rektide]

Do you have any references or links or whatnot to support this? I thought css group was still big into testing. They're no longer called acid tests but I thought it was all still alive & well.

[andrewmcwatters]

They are, they just don't use the Acid 1, 2, or 3 tests that you're familiar with. They currently use a manual test suite, which requires humans to look at reference output and compare it to what the rasterizer and compositor are doing.