Open khushalsagar opened 2 years ago
A third option also is to not change the UA-stylesheet for SVGs (they remain overflow:hidden
in the UA-stylesheet which is the case today).
Based on the resolution in #7144, hidden
on replaced elements (including SVG) should have a used value of clip
. See comment here.
Given the above, no change to the UA-stylesheet for SVG should behave the same as adding overflow: clip
to the stylesheet since they result in the same used value. I think the safest option is to special-case overflow:clip
on SVGs in flex layout to be backwards compatible with the current behaviour.
The CSS Working Group just discussed overflow clip on SVG elements and flex layout
, and agreed to the following:
RESOLVED: in the UA style sheet, we keep `svg { overflow: hidden; }`
RESOLVED: in the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value
RESOLVED: overflow:hidden on replaced elements gets coerced to overflow:clip at paint time
Quoting one resolution:
In the flex spec, for auto min sizing, instead of saying scroll container, we read the computed overflow property value
It wasn't explicitly stated, but I think it's implied that we'll need this change for the automatic minimum size for grid items as well.
@fantasai @tabatkins grid also uses scroll container, do we want the same "look at the computed overflow value" instead?
Ah I guess Daniel's comment is exactly my comment too :)
@emilio @dholbert - We noticed some new tests came in. It looks like you were asserting that we don't read the computed value of the element in grid like we do in flexbox - is that understanding correct?
(also the tests are kinda asserting unspecified things we believe - like if scrollbars are allowed on buttons etc, but we can fix that in the tests separately).
It looks like you were asserting that we don't read the computed value of the element in grid like we do in flexbox - is that understanding correct?
Not quite. I think Gecko does treat grid/flex consistently[i] but we do seem to treat them differently from Chromium/WebKit.
Looking at e.g. http://wpt.live/css/css-grid/stretch-grid-item-text-input-overflow.html (one of the recent test changes), I think the idea of the changes was:
(1) overflow:clip and overflow:visible should behave the same, RE impact on automatic minimum size (this part likely isn't controversial)
(2) inherently-scrollable things like <input>
shouldn't have their min-size be conditioned on their explicit overflow
value (this is the part where engines differ I think)
During code-review, I only noticed change (1) and didn't think too much about (2), but it does seem like (2) is in contradiction to the resolution here and is a divergence from other browsers, so we may need to rethink/revert that part.
[i] RE treating grid/flex consistently, here's an example:
data:text/html,
<style>f { display: flex; width: 1px;}g { display: grid; width: 1px}</style>
<f><input></f>
<f><input style="overflow:auto"></f>
<g><input></g>
<g><input style="overflow:auto"></g>
Firefox Nightly renders all 4 lines the same (no shrinking).
Chrome renders the 2nd and 4th one as being small (shrinking).
So: we're both being consistent between flex (top 2) vs. grid (bottom 2), but the implementations disagree about whether explicit overflow
makes an automatic-minimum-size difference here. (And the test's recent changes currently make it expect the Firefox Nightly behavior.)
(also the tests are kinda asserting unspecified things we believe - like if scrollbars are allowed on buttons etc, but we can fix that in the tests separately).
Mmm right, that seems to be https://wpt.fyi/results/css/css-grid/stretch-grid-item-button-overflow.html (which I think is just a button-flavored version of the text-input
testcase). I think that one is similarly expecting that overflow
has no effect on buttons (in terms of creating scrollbars and also in terms of min-sizing impact), but that's perhaps unjustified on both counts.
(I posted https://bugzilla.mozilla.org/show_bug.cgi?id=1871412#c7 to discuss next-steps on our end.)
<input>
has non-scrollable overflow per spec, see https://html.spec.whatwg.org/#form-controls
The button case might be different / unspecified tho
<input>
has non-scrollable overflow per spec, see https://html.spec.whatwg.org/#form-controls
Note that this is a somewhat recent change tho, and in particular note https://github.com/whatwg/html/pull/10025 which is a proposed tweak to that.
<input>
has non-scrollable overflow per spec, see https://html.spec.whatwg.org/#form-controls
Aha, indeed, I misdiagnosed what was going on with the input
elements there. (I thought we were checking whether a scroll container was/wasn't being generated by overflow
; but we're in fact just checking the computed value like we're supposed to, per the resolution here.)
So I think that means Firefox's rendering of http://wpt.live/css/css-grid/stretch-grid-item-text-input-overflow.html (and my data URI in my previous comment) is correct, because the computed value of overflow
is always clip
regardless of author-specified styles (via that !important UA stylesheet rule from the HTML spec that emilio linked to).
And it looks like we're roughly in agreement on http://wpt.live/css/css-grid/stretch-grid-item-button-overflow.html, if we disregard the column of overflow:scroll
buttons. I'll file a followup bug on doing that or similar.
I filed bug 1873301 to track the behavioral difference for button scrollability, and I filed bug 1873300 on fixing the WPT to not depend on either of the possible behaviors.
This issue is related to the change in #7144 which included a change to add
overflow: clip
to svg elements in UA stylesheet. This causes a compat issue with the following test case:SVG has a min-width/min-height value of auto via default value for these properties. Before the resolution in #7144, SVG also had
overflow: hidden
applied to it via UA stylesheet.During flex layout, the minimum width computed for this SVG element with these inputs was 0. Theoretically this aligns with the spec based on the text here: "the used value of a main axis automatic minimum size on a flex item that is not a scroll container is its content-based minimum size". overflow: hidden causes the element to be a scroll container. But it's specifically not the case for SVG and neither of Chrome/Firefox/Safari make the element scrollable. The relevant spec text is here.
With the change in #7144, the SVG element now gets a value of 'clip' for 'overflow'. This value lines up with how 'hidden' is used on these elements in each browser above. But a side-effect of this is that min-width/min-height:auto now uses the content-based-minimum-size on this element which is incompatible with existing behaviour. The options to fix this are:
Leaning towards 2) since 'overflow: visible' is likely to be a common use by developers for SVG. SVG has respected overflow:visible to not clip content before #7144.
@bfgeek FYI.