- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2022 18:28:12 -0400
- To: 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 Overscroll
--------------
- RESOLVED: fixed-position elements whose scroller is not their
containing block do not participate in overscroll (Issue
#6299: Whether to move position:fixed elements during
overscrolling)
- RESOLVED: The former statement also applies to sticky element when
stuck (Issue #6299)
CSS Grid
--------
- RESOLVED: Accept the current edits for fit-content growth limits
(Issue #4549: Unclear how to limit track growth by
fit-content() argument)
CSS Pseudo
----------
- RESOLVED: Closing this issue as deferred (Issue #1703:
Pseudo-element for dragged element)
CSS Scoping
-----------
- There were no reservations about having the two options listed in
Issue #6577 (Inclusive vs exclusive lower boundary). There is a
desire to try for a unified syntax so discussion will continue on
github to try and refine that syntax.
CSS Overflow & Text Decor
-------------------------
- The group ran out of time for issue #6531, but during the initial
discussion there were some concerns about changing both due to
the current compatibility and due to a lack of author demand.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Mar/0008.html
Present:
Rachel Andrew
Tab Atkins Bittner
David Baron
Oriol Brufau
Tantek Çelik
Daniel Clark
Emilio Cobos Álvarez
Peter Constable
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Daniel Libby
Alison Maher
Ben Mathwig
Eric Meyer
François Remy
Florian Rivoal
Alan Stearns
Miriam Suzanne
Regrets:
Daniel Holbert
Chris Lilley
Lea Verou
Zheng Xu
Scribe: emeyer
CSS Overscroll
==============
Whether to move position:fixed elements during overscrolling
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6299
bmathwig: A lot of browsers had fixed element not participating in
overscroll, but two browsers have the participate and
WebKit still has a bug open.
bmathwig: There are use cases to do both. Can we formalize this and
get it in the spec?
astearns: Do we have any spec text asserting one way or the other?
bmathwig: I didn't find any.
TabAtkins: I don't have a strong opinion here, both options seem
potentially reasonable. Does anyone have overscroll on
non-root situations?
bmathwig: Edge and Chrome don't have overscroll on subscrollers.
<smfr> Apple platforms have overscroll on subscrollers
TabAtkins: It would be nice if non-root scroller behavior was similar
to fixed-position and the root scrollers.
smfr: Apple platforms have overscroll on subscrollers, have shipped
that for many years.
TabAtkins: What's the abspos behavior?
smfr: If a scroll isn't a container block, then the abspos will
follow, meaning overscroll will apply.
smfr: I think the rest here is that on the root, abspos will
dissociate from the scrolling context.
smfr: Potentially you can get negative offsets, depending on the
implementation of scrolling.
flackr: There's no specification of what should be done for
overscroll, and it can be quite different platform to
platform. Maybe we should have guidelines.
flackr: It would be awkward to reflect Android behavior. I realize
this would result in developer-positioned things being out of
alignment from positioned content.
flackr: Anything you're trying to keep in alignment will often get
out of sync during normal scrolling.
<TabAtkins> Agree with flackr - overscroll shouldn't be reflected
into APIs (or at least, not the normal ones; maybe we
could produce specialized query APIs that reflect this).
It's a transitory effect and UA-specific.
smfr: I agree with a lot of what was just said. We consider
overscroll as an unstable state. We're willing to let things be
not entirely correct.
astearns: flackr was saying overscroll is a stretch, not a
translation.
flackr: On Android, content that's at the top is still at the top,
but it's stretched by some amount.
smfr: So it's like a rubber sheet that stretches more at the edge?
flackr: Yep.
chrishtr: I agree we shouldn't expose thing to developers during
scroll. For overscroll on non-root scrollers, I would
expect the right behavior to be that overscroll only
applies to content that's scrolled.
chrishtr: Abspos is different than fixedpos because they have
different containing blocks.
<flackr> +1
<TabAtkins> On reflection, yeah, fixposes aren't fixed wrt the root
scroller, but to the viewport, which is "outside" the
root scroller; this is indeed consistent with the abspos
behavior for subscrollers.
flackr: Under certain circumstances, stickypos feels very similar to
fixedpos. This is the sort of case where we might want to
exclude stickypos.
smfr: I agree sticky should have the same treatment as fixed when it
responds to the viewport.
smfr: Do we want authors to be able to pick how overscrolls happen?
chrishtr: Fixed will not respect overscroll, is the proposal. We
could add a way to opt out of that in the future.
chrishtr: Not reflected in getBound and clientRect.
<TabAtkins> Agreed when stickypos is sticky to the viewport that it
should *remain* sticky to the viewport when the content
is overscrolling, same logic as fixpos.
<iank> I wonder if that'd break existing apps that use fixed-pos as a
sidebar.
smfr: On Apple platforms, overscroll affects scroll position. My
concern is that things could get more complicated.
flackr: On Chrome, we don't have negative scroll position.
smfr: Intersection observer might also be affected.
<TabAtkins> Letting overscroll be *detectable* makes sense; don't
think it needs to be detectable *by the scrollOffset*
<TabAtkins> because it'll be UA-specific to do so
<flackr> +1
<TabAtkins> fixpos *and* stickpos that stick to the viewport
<iank> how difficult is it to add a switch for this?
astearns: Do you want to look through those things before we resolve?
smfr: I'm okay saying UAs can choose what to do.
astearns: Sounds like you are suggesting merely a note about this
interaction. I was hoping we could get something like
overscroll is not defined, we do resolve that fixedpos do
not participate in that behavior.
smfr: I think we also have to specify the client coordinate APIs.
flackr: We have to allow platforms to diverge on how they represent
overscroll.
<chrishtr> The proposed note will be compatible with sidebars, since
it seems best for them not to overscroll
iank: How difficult would it be to add a switch to control this
behavior?
iank: with regards to the fixedpos.
smfr: I don't think it would be hard but we'd have to figure out what
it applies to.
iank: A global flag would be easier than per-element for you?
smfr: Yes.
iank: People use fixedpos for different things. There's clear use
cases for if you want them to move or not. I worry we'll make
some subset of people unhappy either way.
smfr: Fixedpos layout should be defined is that it's relative to the
viewport. If you add alternate behaviors, you have to define a
lot more.
iank: We already have this complexity with abs and fixed pos. They
resolve against two different rectangles.
smfr: We certainly have code that only applies to sticky or fixed.
smfr: It's complicated and I'd prefer not to make it more complicated.
iank: I can see circumstances where you want fixed pos to move with
overscroll, and others where you don't.
flackr: My high-level view is that things that move with scroll
should be affected by overscroll.
astearns: We have WebKit considering it a bug that these things do
move, do we have bugs on Firefox complaining that they
don't?
emilio: We used to have them moved, and we changed so they didn't.
astearns: It sound like the only thing we can come to consensus on
today is a non-normative note that browsers _may_ do what
they like. I'm reluctant to do something that weak.
TabAtkins: I don't think we have to be that weak. Simon's asking for
us to specify the non-moving behavior. Are there strong
objections to us doing that, Simon?
smfr: Seems like it's adding a non-consistency to the specs.
TabAtkins: We certainly wouldn't be getting worse, since there's no
spec text right now.
astearns: I'd be reluctant to resolve without having gone through all
the JS APIs. We don't want to make things incoherent.
chrishtr: Non-normative note that says SHOULD as opposed to MAY?
emilio: QA filed a bug mentioning things didn't match between
browsers.
emilio: We certainly haven't received complaints about the Chrome
behavior.
astearns: Could do a non-normative SHOULD note.
fantasai: Not sure of the point of making it non-normative if it says
SHOULD.
<bmathwig> +1 to that
scribe: fremy
chrishtr: when we make it non-normative, the practical result is that
chromium considers changing the behavior
astearns: the proposal is thus to add a normative should for this
astearns: would anyone object to this?
RESOLVED: fixed-position elements whose scroller is not their
containing block do not participate in overscroll
TabAtkins: also sticky
astearns: any objection to adding sticky?
<flackr> +1 support for sticky
RESOLVED: The former statement also applies to sticky element when
stuck
CSS Grid
========
Unclear how to limit track growth by fit-content() argument
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4549
fantasai: oriol opened an issue because the way we described
fit-content for tracks that span multiple columns
fantasai: ... was not sufficiently specified
fantasai: ... the fit-content now cap the growth limit, and we also
apply this when considering the base size, which we didn't
do previously
fantasai: so we will now distribute up to the limit defined now
fantasai: oriol is happy about the edits we brought in
fantasai: but we need a resolution (and a review)
iank: Are there any test about these cases?
fantasai: Not yet
fantasai: The test should be to add an item in a fit-content track
next to an auto track
fantasai: and an item spanned across two fit-content tracks with
various limits set on them
iank: Can we add tests to wpt?
fantasai: Yes, this is on my todo list
astearns: Anybody want to do their own review before a resolution
proposed resolution is to accepted the edits
RESOLVED: Accept the current edits for fit-content growth limits
fantasai: I verified that this is in my todo list
iank: When you do the pull request on wpt, can you mention the issue?
iank: This will help us link the tests in our system to make the
changes
fantasai: TabAtkins and myself are clearing our way to the grid issues
fantasai: It might be a while before we get to all of it
CSS Pseudo
==========
Pseudo-element for dragged element
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1703
fantasai: Are we interested in styling elements while they are being
dragged?
fantasai: Or is this something we don't want to control further
emilio: I don't think a pseudo-element isn't that great
emilio: because we can only set an image
emilio: We could reuse `content`
emilio: with only an image allowed but that isn't great
iank: We should also consider the threat model
fantasai: Based on this feedback, should we close this as won't fix
astearns: Any objection to close a deferred?
RESOLVED: Closing this issue as deferred
astearns: It's better to give honest feedback
CSS Scoping
===========
Inclusive vs exclusive lower boundary
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6577
miriam: The scoping proposal takes two selector lists (the second one
is optional)
miriam: The first one species when the scope starts
miriam: The second one specifies from which nested elements the scope
stops
miriam: Scoping views include lower boundaries in the scope
miriam: but sometimes the boundaries are excluded of the scope
miriam: There are two options, and feedback is that both might be
useful
miriam: There is a proposal for a syntax
miriam: but me and fantasai were willing for the two syntaxes to look
similar
miriam: It's not clear yet if both options are needed
miriam: A few comments from the bottom, there are a few proposals
miriam: depending if they are in the same parenthesis or not, we can
use a slash or not
miriam: One question is that, should we add a keyword for the
exclusivity
miriam: or a special separator
TabAtkins: I am weakly in favor of allowing both
TabAtkins: Our current default sounds reasonable though
TabAtkins: I don't like slash vs double-slash
TabAtkins: because it's not understandable at a glance
TabAtkins: I would rather add a modifier for the other behavior
fantasai: The issue with keywords, is that they could be part of the
selector
TabAtkins: Then we should put a function around the lower bound maybe?
fantasai: I think we should explore this further
astearns: Are there reservations about adding this choice at all?
astearns: Sounds like not
astearns: Let's take it back to the issue for future iterations
miriam: Another thing, do we want to merge the two syntaxes into one
that works in both places
TabAtkins: I haven't looked into this much, but that sounds like a
good goal to have
astearns: Seems like it would be nice need if it's possible, indeed
astearns: Slight differences are a possible trade-offs though
miriam: Sounds good, thanks for the feedback, we will take it back in
the thread
CSS Overflow & Text Decor
=========================
Should text-decoration include ellipsis?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6531
fantasai: I have no strong opinion on this issue
TabAtkins: The question is whether the text decoration should apply
to the ellipsis dots
TabAtkins: Currently all implementations don't do it
TabAtkins: but the dots use the font, color, etc of the text it
replaces
TabAtkins: So this seems like a bug to me
TabAtkins: but are there implementations where this would be
difficult to do?
<tantek> interesting that every implementation "missed it"
<tantek> I'm curious if there's author consensus on this rather than
reasoning from a spec/purity perspective
<tantek> I'm not seeing any author input on the issue
florian: My intuition is similar
florian: An issue is that the ellipsis is not supposed to be
scrollable
florian: so that makes it different from the rest of the text
florian: because the text is located elsewhere
florian: so it's a different line, not the same line
TabAtkins: Ah yes, if you have a wavy underline, the junction would
be very undefined
TabAtkins: so, this looks more like an abspos, which don't have text
decoration inherit
PeterC: From an implementation perspective, if the text is using a
color font and the following characters might or might have
had color characters
PeterC: it's not clear what the implementation should do with the
ellipsis
PeterC: but indeed that doesn't sound like easy case all the time
iank: I think the scrolling of ellipsis is not a requirement, it's a
may
iank: We would likely object to a change to make normative
iank: because we want to keep shaping
iank: so we would not want to make it an abspos
iank: webkit does the same
iank: but not firefox, which does the abspos
tantek: I haven't seen much request for it
tantek: and we have interop now
tantek: so maybe not changing is an option too
Received on Wednesday, 23 March 2022 22:29:52 UTC