- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 23 May 2023 01:34:25 -0400
- To: W3C style mailing list <www-style@w3.org>
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Overflow
------------
Standardize `overlay` as a synonym for `auto`
https://github.com/w3c/csswg-drafts/issues/8063
- RESOLVED: overlay is legacy value alias for 'overflow: auto'
Interaction of object-overflow/view-box with overflow/clip-margin?
https://github.com/w3c/csswg-drafts/issues/7144
- ACTION: fantasai to draft the magic initial value in overflow-4,
and leave the issue open and use it to drive future discussions
Interaction of overflow: clip/hidden and rounded borders
https://github.com/w3c/csswg-drafts/issues/7434
- RESOLVED: border radius doesn't round the clipping region
when combining overflow: visible and clip
overflow-clip-margin longhands
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8381
fantasai: question is how does the shorthand looks like
fantasai: one is to use different delimiter as grid
fantasai: another is to have box then up to four lengths
fantasai: then /missed/
fantasai: oriol proposed 1-to-4 lengths-and-box
fantasai: I prefer oriol proposal, then (2)
<TabAtkins> I support option 2 (single box keyword, 1-4 lengths)
TabAtkins: seems to be the one that matches up most cleanly what
people want to do
TabAtkins: single keyword and multiple length addresses most cases
fantasai: (4) allows you to do one keyword but also multiple
fantasai: full expansion might be unusual but you don't have to use it
fantasai: and it allows all of them
astearns: all combinations are allowed in the longhands
astearns: oriol, are you ok with (2) or wanna argue for (4)
oriol: no strong opinion, would be fine with (2) or even just
restricting to 1 keyword + length
proposal is to start with one keyword, we can always expand if needed
RESOLVED: Go with (2) for now (single box keyword, 1-4 lengths)
overflow-clip-margin longhands
https://github.com/w3c/csswg-drafts/issues/8381
- RESOLVED: Go with (2) for now (single box keyword, 1-4 lengths)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0006.html
Logs: https://www.w3.org/2023/02/15-css-irc
Present:
Rachel Andrew
Emilio Cobos Álvarez
Tab Atkins
David Baron
Yehonatan Daniv
Elika J. Etemad
Robert Flack
Simon Fraser
Alan Stearns
Miriam Suzanne
Scribe: emilio
CSS Overflow
============
Standardize `overlay` as a synonym for `auto`
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8063
emilio: Was skeptical at first, because I thought only Safari had
overlay scrollbars
emilio: but they also have classic scrollbars in OS preferences
emilio: so I think aliasing to auto is better
emilio: chrome folks also wanted to do it
emilio: helpful for compat
emilio: only annoyance is it doesn't do what it says
emilio: but we already discussed that tweaking overlay vs non-overlay
should be user choice, not author choice
astearns: smfr, anything to add about aliasing 'overflow: overlay'
to 'overflow: auto' ?
smfr: I'm in favor. We agree that it should be user choice rather than
author choice
smfr: overlay vs non-overlay escaping onto the Web was a mistake
astearns: Proposed to specify 'overflow: overlay' as alias
fantasai: legacy value alias?
emilio: Yeah, I think that would be best
<fantasai> https://www.w3.org/TR/css-cascade-5/#legacy-name-alias
<fantasai> https://www.w3.org/TR/css-cascade-5/#value-aliasing
RESOLVED: overlay is legacy value alias for 'overflow: auto'
Interaction of object-overflow/view-box with overflow/clip-margin?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7144
fantasai: lots of discussion after the OP
fantasai: we decided to extend overflow to apply to replaced elements
fantasai: and make their overflow ink other than scrollable
fantasai: then decided that scrollable overflow values behaved as clip
fantasai: and host lang defines this
fantasai: issue is that replaced elements can or not be replaced
depending on whether they load or not
fantasai: same for `content: url()`
fantasai: so you might get alt text clipped or not
fantasai: so proposed a new initial value
fantasai: but oriol pointed that that is unfortunate
fantasai: so proposal is to make the new value remain auto but return
something else in gCS
oriol: I think kushal's proposal to handle it with two properties
looks nice
fantasai: new initial value or doing different things depending on
whether the element is replaced or not seems like a
workaround and it might not be worth it
fantasai: I have an additional proposal using three properties in the
issue
fantasai: we'd re-add object-overflow
fantasai: I think by adding it these interactions / corner-cases can
be explained by the third property
fantasai: I think only inconsistency would be svg
fantasai: which currently aren't clipped but are replaced
fantasai: but this can be a simple rule in the UA sheet
dbaron: is the svg behavior consistent between svg-in-document and
svg-as-image?
fantasai: svg-as-image definitely clips by default
dbaron: maybe svg and markup is a different case from images anyways
fantasai: I think so, I think you might want to apply it to <svg>
elements in the UA sheet
dbaron: maybe object-overflow shouldn't apply to svg elements within
the document
astearns: so object-overflow was something that was introduced then
removed?
fantasai: yeah we tried to make overflow work instead, but I think
there are some problems with that
dbaron: I believe there's some connection to the view-transitions work
here? Suspect that's why kushal was interested
<ydaniv> embedded SVG has overflow hidden rule in the UA, and it can
be overridden
emilio: Concern with making overflow just work
emilio: there's other cases where it doesn't create a scrollable
element, is the concern just backwards compat?
fantasai: not just that
fantasai: the problem is that whether an element is replaced or not
(and thus whether it should clip by default) depends on
stuff that can't be selected against
fantasai: so we can't make it just a simple UA sheet rule etc.
fantasai: and if you use CSS to turn something into a replaced element
you'd get visible which might not be what authors expect
emilio: at least for everything but the 'content' case, I think it
could be addressed with CSS?
emilio: we have internal pseudo-classes for images that are broken
emilio: so we could conditionally apply the new overflow value, clip
vs visible, based on that pseudo element
emilio: still problematic for 'content' though
emilio: idk if that's a huge issue? not sure it's used a lot
emilio: might be able to get away with it
emilio: authors can set clip themselves
fantasai: yes, but it's weird if it doesn't clip!
emilio: you want img/svg/etc to have overflow:clip by default in the
UA sheet
emilio: and ... then the weird case is content
emilio: but could make broken images be visible again using pseudos
emilio: also, overflow doesn't apply to inline boxes so they'd be
visible
fantasai: not all images are 'display: inline'
astearns: so emilio suggests that with the existing properties UA
sheet could express it
astearns: but there'd be no author facility for replaced element
fallback
ydaniv: People override overflow on SVG elements
ydaniv: and it works
fantasai: I think using a UA sheet might be complicated from an
author's point
fantasai: and the other two other alternatives (new initial value or
splitting into another property) would be easy to understand
astearns: would it be easy to start with the magic initial value and
add the new property if that's not sufficient?
fantasai: we could though it'd be weird to have two different things
doing the same thing
oriol: there was also the problem that it's not just about whether
overflow should clip but also what the initial clipping area is
oriol: I don't recall how this model was addressing this problem
oriol: But by adding a third property that'd be more reasonable
fantasai: agree
emilio: if we add a magic initial value for 'overflow' and
'overflow-clip-box' as well
emilio: but not expose it to content, make the resolved value
(getComputedStyle) would be the used value
emilio: wouldn't that basically address the issue, without introducing
new magic for authors?
emilio: if authors say 'overflow: visible', that just works
emilio: then authors don't need to worry about it, and I don't think
it'd be harder to implement
emilio: maybe it's harder to understand
emilio: we don't need a good name for magic auto, because it's not
exposed to authors
fantasai: we could just call it 'normal'
astearns: so the magic is that it's a value that authors don't use and
never see because gCS lies
fantasai: so to recap 3 options...
1. selectors in UA sheet
2. magic initial value that disappears in gCS
3. separate properties
fantasai: I think any could work the questions is what's better
astearns: kushal seemed fine with the magic value, did they express
opinion on the extra property?
astearns: Maybe go back to the issue but restrict to the magic value
or extra property options?
emilio: I think the magic value would be nicer for authors
emilio: things just work as you specify stuff
emilio: but it may benefit from some experimentation
fantasai: I think the major thing to consider is "do you as an author
want to control overflow application independently for a
single element independent on whether it ends up replaced
or not"
fantasai: do I want to set overflow differently depending on whether
or not it ends up being replaced
fantasai: let's say I do overflow: auto on an <object> but take the
same layout space
fantasai: then the replaced element would get a different value either
fantasai: if we decide having the values in sync is fine then we can
do a single property
fantasai: if not, then we need separate values
emilio: why is overflow special compared to replaced/non-replaced?
We could expose that via pseudo-classes
emilio: that also allows changing any other property
emilio: If we decide that use case is valuable, we have issues on file
for exposing whether an image is broken or not etc.
astearns: My intuition matches Emilio's, wanting to apply different
things depending on state isn't worth a separate property
in this case
astearns: but only lightly in that camp, could go either way
astearns: So if people want to resolve on having a magic initial value
and work that through, happy to do that, but maybe better to
take it back to the issue for these specific questions
fantasai: I'd be also fine with leaving it open but drafting the
initial value in overflow-4
fantasai: and posting a comment on the issue
astearns: would you volunteer to do that?
fantasai: yes
ACTION: fantasai to draft the magic value in overflow-4
... and leave the issue open and use it to drive future discussions
Interaction of overflow: clip/hidden and rounded borders
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7434
dbaron: I missed oriol's last comment, but I think it's relatively
simple
dbaron: I noticed that the spec allows overflow to be clip in one axis
but visible in other axis
dbaron: which is something that was introduced when clip was introduced
dbaron: when we introduced clip the question is how it interacts with
rounding of borders
dbaron: I thought the simple question is that you clip in one axis but
not on the other border radius has no effect
dbaron: oriol posted screenshots, and I'm not sure browsers are doing
this new clip and visible behavior
oriol: the behavior in browsers is... webkit has a bug where content
is not painted... Chromium if it has overflow: visible clip as
just clip only with non-zero radius
oriol: so not continuous
oriol: firefox applies the rounded clip to the bounding rectangle of
the overflowing content
oriol: In this particular case it looks kind of nice but it can be
strange
oriol: I think I'm leaning towards dbaron's proposal
<fantasai> +1 to dbaron's proposal
<flackr> +1 to dbaron's proposal, it makes sense that allowing visible
overflow in the off-axis means there's no rounding
smfr: I think I agree. The WebKit bug was fixed and now we behave like
Chromium but I think that's just bugs, I'm ok with dbaron's
proposal
proposed resolution is that when clip and visible are specified,
border radius doesn't cause rounded clipping of the contents
emilio: what if some corners have no radius and others do?
dbaron: we're not talking about whether border-radius has an effect,
but whether it clips the contents
dbaron: border-radius with overflow: visible has an effect but doesn't
clip
dbaron: my argument is that if you're not clipping in one axis you
shouldn't clip to the border radius
smfr: so basically everything should render as the first Firefox
screenshot right?
smfr: is that right if there's no content to clip?
smfr: I'd like to see a test-case with something that overflows only
on one side but doesn't fill the content box
dbaron: I don't think any engine does what the spec says to me
dbaron: oh wait, FF does it
dbaron: I'll paste a modified test-case in the issue
dbaron: https://github.com/w3c/csswg-drafts/issues/7434#issuecomment-1431669370
dbaron: I think it should match up with what FF is doing on the later
one
dbaron: because the inset rules for the clipping cause that to not
have any rounding
emilio: I think I'm fine with dbaron's proposal
emilio: could do something more complicated, but unclear it would be
useful
<TabAtkins> ok lol i finally looked at firefox's behavior with
dbaron's increased overflow, that's silly
<TabAtkins> i see why that would happen but still
Proposed resolution: border radius doesn't round the clipping region
when mixing overflow: visible and clip
dbaron: I should probably clarify that this is just a bugfix in the
spec because nobody thought about it
dbaron: but I don't think there's any other sensible behavior here
* fantasai is not sure what's happening in the testcases, but agrees
with the proposal
smfr: if you look in Firefox at the penultimate box on the last
test-case I just posted (where I just shift the box) is that
what you're proposing?
astearns: so with this resolution we'd still round the border but the
overflowing element isn't clipped
fantasai: afaict, all we're proposing here is that the
border/background/etc are still rounded as normal, we just
don't clip the content to the radius when there's overflow
in one axis (or both axes)
fantasai: this seems fine, what's the confusion?
smfr: I just want to confirm that in my latest test-case FF is
correct, except for the rounding on the left side
dbaron: right
smfr: sounds good
<emilio +1 as well
RESOLVED: border radius doesn't round the clipping region when mixing
overflow: visible and clip
overflow-clip-margin longhands
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8381
fantasai: question is how does the shorthand looks like
fantasai: one is to use different delimiter as grid
fantasai: another is to have box then up to four lengths
fantasai: then /missed/
fantasai: oriol proposed 1-to-4 lengths-and-box
fantasai: I prefer oriol proposal, then (2)
<TabAtkins> I support option 2 (single box keyword, 1-4 lengths)
TabAtkins: seems to be the one that matches up most cleanly what
people want to do
TabAtkins: single keyword and multiple length addresses most cases
fantasai: (4) allows you to do one keyword but also multiple
fantasai: full expansion might be unusual but you don't have to use it
fantasai: and it allows all of them
astearns: all combinations are allowed in the longhands
astearns: oriol, are you ok with (2) or wanna argue for (4)
oriol: no strong opinion, would be fine with (2) or even just
restricting to 1 keyword + length
proposal is to start with one keyword, we can always expand if needed
RESOLVED: Go with (2) for now (single box keyword, 1-4 lengths)
Received on Tuesday, 23 May 2023 05:34:35 UTC