Which even just remembering now gave me some small terror
"Site-specific hacks break native video controls in YouTube embeds" https://bugs.webkit.org/show_bug.cgi?id=245612
So many hours spent debugging this...
https://github.com/WebKit/WebKit/blob/f134a54c03b71e8e3c4da0...
https://github.com/WebKit/WebKit/blob/f134a54c03b71e8e3c4da0...
Also not as disgusting as Quirks.cpp, but I was debugging some video decoding stuff in Chrome this week and found some fun things today, special code to work around various GPU driver bugs.
https://source.chromium.org/chromium/chromium/src/+/main:gpu...
https://source.chromium.org/chromium/chromium/src/+/main:gpu...
And a separate implementation of MSAA for Intel GPUs
https://source.chromium.org/chromium/chromium/src/+/main:gpu...
It is however absolutely the behavior of web developers, that's why the web used to be filled with IE only sites, and why we are now getting chrome only sites. It is much easier to blame other engines that ask whether your site is depending on implementation details.
The TLDR for this is: the modern web is very well specified, and all browser engines work very hard to conform to those specs, and now when divergent behavior is found the erroneous engine is corrected, or if the specification itself was incomplete considerable effort is expended making sure it is complete so that it is possible to ensure conforming implementations. The driving force for this was engine developers, not site developers.
Anyway.
The entire point of the html5 and subsequent "living" spec, and the death of ES4 and subsequent ES3.1 and ES5 specs, and then ES's "living spec" was dealing with the carnage of the early web and the Netscape vs IE insanity it produced. This was a huge amount of effort driven almost entirely by the engine developers, specifically so that the specs could actually be used to implement browser engines. The existing W3C and ECMA specifications were useless as they frequently did not match reality, where they did match reality they had gaps where things were not specified, and frequently they simply did not acknowledge features existed.
It took a huge amount of effort to determine the exact specification for parsing html, such that it could be adopted without breaking things. It took a huge amount of effort to go through the DOM APIs, the node traversal, event propagation, and on and on to specify them.
The same thing happened with ecmascript. A lot of effort for many years was spent replacing the existing spec, ignoring a bunch of time wasted by some parts of the committee creating ES4, making it so that the ecmascript specification actually matched reality.
There were places where we found that there were mutually incompatible behaviors between Gecko and Trident, but in most cases we were able to replace old badly written specs, with real specifications that were compatible with reality, and were sufficiently detailed that they could be used to implement a new engine, and be confident that their engine would actually be usable.
The immense work required for this also means that the spec authors and committees are acutely aware of the need for exact and precise specification of new features. So it is expected that new specifications completely specify all behavior.
As an example, I recall that after originally implementing support for IMEs in webkit on windows, I spent weeks stepping through how key down, up, and press events were fired in the DOM when a user was typing with an IME. The spec at that point failed to say what events should be fired in that case - text entry is not keydown/press/up once IMEs are involved, do not assume one keyup will result in a single character change - it was a months long effort to get to something that only managed to specify keydown/up/press, none of the actual complexity of IMEs. The specification has since expanded to be more capable of handling IMEs, but they have an example of what the "keys typed by a user" vs "key events you receive" [1], and alas my work is now largely "legacy" :D [2]
The problem as ever, is that it is very easy for web developers to rely on some implementation detail that a specification failed to dictate, and then say any browser engine that does not behave identically is wrong. This is what webdevs did with IE, and now it's what webdevs do with Chrome. It is always easier for a webdev to paste "this site requires ie/chrome" than to work out if what they're doing is actually specified behavior. Sure, it's possible it's a bug in the other engine, but if you are saying "install chrome" you're saying it doesn't work in Gecko or WebKit, so it's much more likely to be a site bug.