Normalize.css: consider overflow-anchor: none?

[MarkoCen]

Since version 56, Chrome enables Scroll Anchoring feature by default, and most of other browsers have not support it yet.

Turned this feature on already affect some of popular libraries, for example ui-grid scrolling issue

Should we consider setting overflow-anchor: none to disable this feature?

[bardiharborow]

I'd consider this sort of thing a "useful default", though. Certainly frameworks will need to opt-out in certain circumstances (e.g. twbs/bootstrap#1384), but completely nullifying such intentional browser behaviour by default seems excessive.

[thierryk]

but completely nullifying such intentional browser behaviour by default seems excessive.

but isn't what normalize is about? Normalizing styles across browsers...

[gouch]

I personally view normalize as a tool to help build layouts cross browser (by smoothing gotchas like one browser using padding for list items and another using margin).

Taking on the role of browser behavior police seems a self destructive mission. Browser makers constantly try to make the user experience better. If normalize starts nullifying every change, then it amounts to IE6-ifiying the web, just with 2016 features.

Browsers are gonna evolve, and not in sync with each other, and I think normalize should give that process time, to see if a new consensus happens among browsers, before bringing down the feature nullification hammer.

[jonathantneal]

@gouch, yes, and we have specs to guide us on expected behavior that other browsers yet honor. We do not set the web back.

[thierryk]

Playing devil's advocate...

I think the issue here is that Normalize becomes opinionated and not reliable enough in relation to its "mission statement" which tells authors what they should expect from it.

• Normalizes styles for a wide range of elements.
• Corrects bugs and common browser inconsistencies.

Many devs onboard Normalize on the promise that it takes care of inconsistencies between browsers but this is no longer the case when Normalize decides that a brand new browser feature (vendor specific) is deemed "cool" enough to not be normalized.

To me, the responsibility of Normalize is to level things (good or bad) and the responsibility of devs is to understand this. In other words, authors should not rely on Normalize to implement opinionated styles (as in allowing discrepancies) they should rather understand what Normalize is meant to be and stye things accordingly.

In this case, Normalize could use overflow-anchor: none and authors would overwrite that with a simple overflow-anchor: auto. And note that in the case of angular-ui-grid there would be nothing to overwrite as it is the style they would need.

This is not about "setting the web back", it is about respecting user's expectations. It is about doing what Normalize is supposed to do: normalize styles and corrects common browser inconsistencies. After all, we are not talking about "unsetting" a style that Chrome supports according to specs—overflow-anchor is just a draft.

This being said, I don't think Normalize should take care of every style/experiment a vendor decides to ship. Normalize should rather clearly defines what it is supposed to take care of.

[jonathantneal]

From the beginning, whenever browsers have disagreed, normalize has followed the spec, even when it hurt a little; from fixed to relative margins on headings in old IE to abbr[title] being an underline instead of border-bottom. The exception to this rule was the old opinionated styles which never really fit in and only ever caused problems. Now, if you feel the tag line for the project is mistaken, a suggestive PR would be reviewed. :)

[thierryk]

Now, if you feel the tag line for the project is mistaken, a suggestive PR would be reviewed. :)

I'm just trying to start a discussion here. If you recall, I've tried that in the past but it didn't go anywhere ;)

I personally do not care what the project on-boards or not as long as it follows a specific set of rules so devs know exactly what to expect from Normalize (which would also make them more confident regarding new releases).

[bardiharborow]

@thierryk Normalize's "mission statement" also states:

• Preserves useful defaults, unlike many CSS resets.

In the majority of cases, Scroll Anchoring seems to be a useful default, and in the fraction of cases where it is not, custom CSS should handle that. Additionally, Normalize is moving to drop "opinionated" styles in 6.0.0 and focus patching fixing critical browser bugs. In my opinion, this is well on the "opinionated" side of things.

[thierryk]

@bardiharborow, you said:

Preserves useful defaults, unlike many CSS resets.

Not really since the styling of margin on body is a reset. So you see that it is not that clear, and that's exactly what I'm trying to discuss here—the fact that users do not really know what to expect from Normalize.

I just think Normalize is trying to address too many issues...

In my opinion, Normalize should relate to UA styles sheets, in which case the margin of body would not be reset and styles like overflow-anchor would be ignored, because it is vendor specific.

That's my POV but I think it could be anything else as long as it follows a specific set of rules that would help make clear decisions. When something new come up, we should be able to address it without having to resort to some kind of "voting"...

[jonathantneal]

@thierryk, thanks. I’m closing this and preserving Chrome’s implementation.