Right now, normalize.css has a rule to make all input elements have overflow:visible. This has no effect in Chrome and Safari, and it has an effect in IE/Edge/Firefox which makes them diverge from Chrome/Safari, which can then cause interop problems for sites that use normalize.css. So, it's a net negative right now. Could it be removed?
Investigation:
Below is a testcase I used to test the effect of this rule (with explicitly-sized tiny widgets whose contents are larger than the explicit size, where possible), on every input type that is listed on MDN:
overflow unspecified (default):
http://jsfiddle.net/dholbert/sghn2tz4/embedded/result,css,html
overflow:visible added (as in normalize.css)
http://jsfiddle.net/dholbert/sghn2tz4/1/embedded/result,css,html
Notable differences between these versions, on each major browser engine:
- In IE11 and Edge 18, for
input type="button,reset,submit", the overflowing button label becomes visible if you provide overflow:visible. There are no other differences.
- in Firefox 68 (nightly), for
input type="file", the "Browse" button-label and "..." filename area become visible if you provide overflow:visible There are no other differences.
- In Chrome 75 (dev) and Safari 12, there's no difference between the two versions.
Most notably, the widgets that start overflowing via overflow:visible in IE/Edge/Firefox are always clipped in Chrome/Safari, even with overflow:visible specified.
Conclusions:
In the majority-market-share browser engine family (Blink/WebKit), overflow:visible has no effect on input elements. And in other engines, the only effect is to cause these engines to diverge from the Blink/WebKit behavior.
So, unless there's a reason to keep this rule that I'm not seeing, it'd be great if we could remove it, to avoid introducing web compatibility issues mozilla/send#1295 .
Thanks!
Right now, normalize.css has a rule to make all
inputelements haveoverflow:visible. This has no effect in Chrome and Safari, and it has an effect in IE/Edge/Firefox which makes them diverge from Chrome/Safari, which can then cause interop problems for sites that use normalize.css. So, it's a net negative right now. Could it be removed?Investigation:
Below is a testcase I used to test the effect of this rule (with explicitly-sized tiny widgets whose contents are larger than the explicit size, where possible), on every input type that is listed on MDN:
overflowunspecified (default):http://jsfiddle.net/dholbert/sghn2tz4/embedded/result,css,html
overflow:visibleadded (as innormalize.css)http://jsfiddle.net/dholbert/sghn2tz4/1/embedded/result,css,html
Notable differences between these versions, on each major browser engine:
input type="button,reset,submit", the overflowing button label becomes visible if you provideoverflow:visible. There are no other differences.input type="file", the "Browse" button-label and "..." filename area become visible if you provideoverflow:visibleThere are no other differences.Most notably, the widgets that start overflowing via
overflow:visiblein IE/Edge/Firefox are always clipped in Chrome/Safari, even withoverflow:visiblespecified.Conclusions:
In the majority-market-share browser engine family (Blink/WebKit),
overflow:visiblehas no effect on input elements. And in other engines, the only effect is to cause these engines to diverge from the Blink/WebKit behavior.So, unless there's a reason to keep this rule that I'm not seeing, it'd be great if we could remove it, to avoid introducing web compatibility issues mozilla/send#1295 .
Thanks!