Unfortunately, as is often the case when one learns of a new CSS property or a Web API, the browser support is just not there yet. Safari, for example, doesn't support this at all: https://caniuse.com/mdn-css_properties_contain
Writing good browser based software is about delivering the best possible experience for all users regardless of their browser choice. That doesn't mean withholding beneficial features just because they're not available everywhere. It means writing software to take advantage of every possible benefit that improves the user experience, and detecting browser support where necessary to provide fallbacks and polyfills if you need them.
In this case it's just a performance hint, so Safari users would have the same experience they do now. Everyone else would benefit.
This is how you end up with "the performance sucks if you don't use chrome" complaints though. I imagine Google makes use of optimizations only possible in Chrome quite often making their applications provide sub par experiences on other browsers.
This is how you end up with "the performance sucks if you don't use chrome" complaints though.
Not it isn't. You get that by only testing in Chrome, and not putting the work in for other browser users. If you test in other browsers and the performance sucks then you should work to make it as good as possible in those other browsers as well.
Aiming for the same experience everywhere is how you don't use things like the 'contain' hint because it's not available in Safari, and then everyone gets a slower website because of it.
Don't undermine every user's experience just because one browser is lagging behind.
In my opinion, good applications perform predictably across different browsers, which means they rely on highly available features across all browsers... meaning they don't use things specific to a single browser/device....
What you're arguing for here is what Google did - they didn't implement 'contain', so everyone got the equivalent of the Safari browser experience. If Google had done what I'm suggesting here then users who are on Chrome, Firefox, Edge, etc would have a much better experience. Safari users wouldn't see any difference. Why would you make the user experience for many people worse than it could just because they don't use Safari?
Everyone should get the best possible experience for their chosen browser, even if that means users get different experiences.
> "they didn't implement 'contain', so everyone got the equivalent of the Safari browser experience."
Not sure that the Google developers knew that feature existed. Most people in this comment thread were unaware of this feature too, seems reasonable that the Google developers might not have been aware either.
> "Everyone should get the best possible experience for their chosen browser, even if that means users get different experiences."
I like that quote. Good websites do give the best experience a device can handle, rather than cater to what the worst devices are capable of.
I don't think this matter much? It's just a performance optimization, Safari can remain slow while all modern browsers benefit. Unknown CSS values should be ignored so there should be no impact on actual usability.
Seems to me like it's excellent for daily use despite the lack of compatibility of outdated browsers.
It matters because it causes a new stacking context. Z-index only affects elements within the same stacking context, so you then can get weird behaviour that one floating tooltip overlaps something in Firefox/Chrome but doesn't in Safari because Safari doesn't create the stacking context.
Browser support aside, it seems very counterintuitive. https://developer.mozilla.org/en-US/docs/Web/CSS/contain suggests that it can cause pages to render differently, which is very strange, considering that the description implies that it only effects when the browser repaints/re-processes region, and not what the result is.
"When" can definitely affect the end result if the page elements are arranged such that they break the rules implied by the contain logic.
For example, the `paint` rule implies that child elements have their renderable pixels completely within the containing parent. If the containing parent is moved off screen, computation of whether any of its children need to be painted is skipped. That will cause the child to vanish if it extends outside the parent.
Browsers give no control over when areas are repainted. If you change a bit of CSS or DOM, it will be repainted in the next frame. There is no way to say 'dont paint this yet'.
The thing the contain property does is ensure that a particular Dom change won't affect pixels outside the element involved, which means the browser won't need to do any extra repainting.