- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 May 2023 20:20:00 -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 Grid
--------
- There were three options outlined to resolve issue #7661
(Application of grid-positioning properties to static position
of grid children is inconsistent). Additional clarifications for
the options will be added to github and then this will come back
to the agenda in two weeks for a resolution.
Scroll Animations
-----------------
- RESOLVED: Switch timeline names to <dashed-ident> (Issue #8746:
Require <dashed-ident> for timeline names)
- RESOLVED: Remove scroll/view-timeline-attachment, add
timeline-scope, which accepts a list of timeline names
and raises their scope (Issue #7759: Broader scope of
scroll timelines)
- RESOLVED: Accept "auto" as an animation-duration in the animation
shorthand (Issue #8656: Explicit `auto` for
`animation-duration` in the `animation` shorthand)
- RESOLVED: Allow timeline ranges outside of 0-100% range, and use
them as-is for existing animation start-time and
duration calculations (Issue #8578: Out-of-range range
offsets)
CSS Logical & Images
--------------------
- On the call it was suggested to address issue #1724 (flow-relative
gradients) by using the <position> in Backgrounds 4 as a
foundation. Discussion will return to github so folks can read
up on the Backgrounds spec.
CSS Overflow
------------
- The group was moving toward a new property rather than reusing
overflow-clip-margin for issue #7246 (How does
overflow-clip-margin: border-box behave on a scroll container?).
Use cases will be gathered on github to validate this approach.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0013.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Brad Kemper
Jonathan Kew
David Leininger
Peter Linss
Alison Maher
Eric Meyer
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Chris Lilley
Florian Rivoal
Sebastian Zartner
Chair: miriam
Scribe: TabAtkins
Scribe's scribe: fantasai
Upcoming F2F
============
miriam: Any extra agenda items?
Rossen: Reminder about f2f in July
Rossen: The dates have firmed up, there's an update posted to the
wiki
<dbaron> https://wiki.csswg.org/planning/cupertino-2023
Rossen: Those of you traveling, this should give you the info of
what to expect in terms of venue, rooms, food, where, how,
when
Rossen: If you'll join us, have a read and make travel arrangement
Rossen: And huge thanks to Elika, Tess, and Myles for organizing
CSS Grid
========
Application of grid-positioning properties to static position of grid
children is inconsistent
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7661
iank: Want to get this on radars
iank: We need to resolve it for subgrid
iank: Today in the spec we will change the static position depending
on if the grid is also the abspos CB
iank: So if the grid is an abspos CB, its abspos child will "place
itself in the grid" and use that area for its cb
iank: If the grid isn't an abspos CB the abspos will use the content
box
iank: Blink had a bug where we started placing OOF items twice
iank: Regardless of whether grid was a CB, we'd figure the staticpos
from the grid area, and then it would get positioned again if
it was a CB
iank: Three options
iank: One is align impls along the spec as-is. That would undo the
previous resolution, that the staticpos doesn't depend on the
abspos CB.
iank: Two is to get rid of the staticpos placement, and always use
the content box.
iank: Three is to place the abspos twice. Once in the grid for the
staticpos, once in the actual CB.
iank: This gets complicated for subgrid, it'll get placed in the
subgrid for one and the grid for the other.
iank: This'll also undo the previous resolution
fantasai: I'm not sure what you mean by "place an item twice"
iank: Imagine a grid container that is the abspos parent but not
its CB
iank: You'd place the abspos in that grid to pick up its staticpos,
and then in its CB it'll get actually placed.
fantasai: What I'm confused about - in a given axis, you're either
placing it with regards to staticpos or with regards to
the abspos CB. What do you mean by doing both?
iank: So if you have an abspos it'll pick up its staticpos rect from
the parent, say top and bottom aren't set so it uses that
rect. Then if left and right are set, it's positioned with
regards to the actual CB.
TabAtkins: I'm confused, isn't that how abspos works in every case?
iank: Say you have 'column: 2' on the abspos. It'll get placed in
the subgrid for static pos and in the outer grid for CB.
TabAtkins: Ahhhhh, you meant it invokes GRID PLACEMENT twice, in
different grids.
iank: Yes, sorry, that's what I meant by placement.
miriam: So plan is to continue discussion in the issue and bring it
up in two weeks for resolution.
iank: Yes. My preferred is to not do grid-placement for the static
pos, always use the content box.
iank: If people have strong opinions otherwise, make yourself known.
fantasai: Could you clarify the writing modes detail?
iank: Yeah it's not a big issue, I'll clarify in the issue.
Scroll Animations
=================
Require <dashed-ident> for timeline names
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8746
flackr: In the current spec we use <custom-ident> for timeline names
flackr: But in previous specs this has resulted in compat risk as we
add new identifiers, as they might clash with
author-provided custom idents.
flackr: So I propose we use <dashed-ident> for timeline names. We do
this already in a few other properties.
<TabAtkins> +1
<ydaniv> +1
<bramus> +1
<fantasai> I don't like it but I won't object :)
proposed resolution: Switch timeline names to <dashed-ident>
miriam: Objections?
RESOLVED: Switch timeline names to <dashed-ident>
Broader scope of scroll timelines
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7759
flackr: We previously resolved we wanted the scroll-animations spec
to define a timeline that is provided by a scroller that
wasn't discovered yet
flackr: This issue is about the specific syntax
flackr: Had discussions with a bunch of people and we have a
proposed consensus
flackr: New property, timeline-root
flackr: Not directly related to the view-timeline or scroll-timeline
property
flackr: timeline-root defines a new "deferred timeline" object,
which will find a nested timeline to attach to.
flackr: Sorry, timeline-scope as the name.
fantasai: The way I'd describe is you create a timeline by naming an
axis or whatever.
fantasai: timeline-scope lets you increase the scope; you put it on
an ancestor and it "hoists" the timeline higher to make it
visible to more elements
flackr: Conceptually this is true, but technically it does create
its own timeline, for animation discovery purposes.
flackr: But it's fine to think of it that way, and the timeline you
observe from JS will be the real timeline generated by the
scroller or whatever.
miriam: What's the value of the property?
flackr: A dashed-ident
<flackr> probably a list of dashed-idents
TabAtkins: It will search for a timeline with the same name (of any
kind of timeline) among its descendants
TabAtkins: if it finds one (not zero, not many) it attaches that
timeline to the name for its entire scope
proposed resolution: remove scroll/view-timeline-attachment, add
timeline-scope, which accepts a list of timeline names and
raises their scope
miriam: Objections?
<bramus> +1
<fantasai> +1
<ydaniv> +1
RESOLVED: remove scroll/view-timeline-attachment, add
timeline-scope, which accepts a list of timeline names and
raises their scope
<bramus> yay!
Explicit `auto` for `animation-duration` in the `animation` shorthand
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8656
flackr: scroll-driven animations, we want them to implicitly/
automatically use auto duration, which matches their
animation range
flackr: So this raises whether "auto" can be used in the animation
shorthand.
flackr: Tab suggested this is implied by omission, but this makes it
impossible to represent a non-zero delay (since duration has
to exist before a delay).
flackr: So I suggest we do allow "auto" explicitly.
flackr: This is similar to other properties like background
dbaron: Are there any other things in the animation shorthand that
take "auto"?
flackr: No, besides animation-name of course
fantasai: I think we discussed having delay potentially be auto
flackr: Right, no conflict because delay is already positionally
unambiguous with duration
flackr: Only concern is if a non-time property takes auto
<TabAtkins> +1
proposed resolution: accept "auto" as an animation-duration in the
animation shorthand
miriam: Objections?
RESOLVED: accept "auto" as an animation-duration in the animation
shorthand
Out-of-range range offsets
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/8578
flackr: This is about whether we allow animation-range offsets
outside the 0-100% range, and if so what we do with them
flackr: I propose we do allow them, and we have the animation-range
account for that range (so the animation conceptually begins
before the timeline start). This is already well-defined.
flackr: Also fairly consistent with the way we allow keyframe
offsets outside the animation active interval.
flackr: I think it's also useful to have negative values so you can
define an animation portion as starting before some other
range.
<TabAtkins> +1
ydaniv: Is there weirdness with non-named ranges, having values
outside the range?
flackr: Why is that weird
ydaniv: With named ranges you may still have more scroll range
ydaniv: when you use the entire scroll range there's nothing outside
of 0-100
flackr: That's not true with view timelines, because their complete
range is "cover" but they do produce values outside of 0-100
flackr: But even so, having implicit clipping at the scroll limit is
already part of the API in terms of how keyframes work, and
how named ranges work if you can't scroll to that full
range. So I think it's consistent.
miriam: So if the value is outside 0-100 and there's no way to get
to there, it's clipped?
flackr: It's implicitly clipped - if you have an animation start at
-20%, when the animation actually starts it'll actually have
already gone thru 20% of the animation.
flackr: Proposed resolution is allow timeline ranges outside of
0-100% range, and use them as-is for existing animation
start-time and duration calculations.
miriam: Objections?
RESOLVED: allow timeline ranges outside of 0-100% range, and use
them as-is for existing animation start-time and duration
calculations.
CSS Logical & Images
====================
flow-relative gradients
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/1724
oriol: Currently, in linear-gradient() you can specify an angle with
physical keywords (to right)
oriol: Proposal was to also allow a logical side keywords
oriol: block-start/etc for sides
oriol: For corners, use same as border-radius, start-start,
start-end, etc. First refers to block axis, second to inline.
oriol: Second part of the proposal was about logical angles.
fantasai: I don't think this is quite the right way. Gradient uses
`to <position>`, should continue, just with the extended
<position> we put into BG 4
fantasai: this is different than what Oriol is saying. It allows for
logical/physical combos.
fantasai: You can do purely physical (top left, etc). Axis is
physical, direction in that axis is physical. You can also
do purely logical.
fantasai: But extended position also allows mixed - axis is
physical, but direction in that axis is logical.
fantasai: Oriol's suggested syntax doesn't allow for that and is
inconsistent with the <position> syntax in general.
fantasai: So we should use extended <position>
<fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
oriol: I'm not as familiar with this extended <position>. Not sure
how it works when you combine physical and logical.
oriol: Seems hard to reason about.
fantasai: Syntax is straightforward, it's documented there. If we
don't like it, we should change it here, for everything.
Shouldn't do different things for gradients and
backgrounds.
fantasai: But I do think this is the way we want to go.
<TabAtkins> +1 to fantasai, at bare minimum we should be
consistently using <position>, even if we end up wanting
to change how we do logical <position>.
oriol: I'd like to review the BG 4 syntax since I'm not familiar
with it
TabAtkins: I think it's fine to delay a bit more for review
TabAtkins: not a high priority
miriam: Ok, take back to the issue.
CSS Overflow
============
How does overflow-clip-margin: border-box behave on a scroll container?
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7246
miriam: emilio raised this, fantasai agenda+'d it
<iank> +1
emilio: I'm fine with "it doesn't apply to scrollable boxes"
emilio: So when I filed this, I was wondering...
emilio: There are some elements that need to clip, even though
they're scrollable they clip to another box that isn't the
padding box
fantasai: Issue is about whether overflow-clip-margin should apply
to scroll containers
fantasai: Applying it brings up a lot of interesting questions
fantasai: Where does the scrollbar go. If you scroll to the top/
bottom is the content in the padding area clipped, or is
the scroll area reduced so it's viewable. Etc.
fantasai: There's a comment from Matthew Perry where he outlines the
desire for this feature, and outlines a set of behaviors
that seem to make sense to them.
fantasai: Scrollable area and viewport are both... Never mind,
follow the examples.
fantasai: He wants things scrollable to be viewable until it's
outside the scrollable margin.
fantasai: I think if it's within the box it has a layout impact...?
It's not clear to me exactly.
flackr: I don't think it has to.
fantasai: If it doesn't have a layout impact, you can't see all the
content unless you know to put enough padding in the
content.
flackr: Right.
fantasai: So I think it probably makes more sense to effectively
increase the size of the box to the content area.
fantasai: So I think the question is - do we want to figure out how
to make this work? Or just define it to not work?
flackr: I think there are a lot of UIs that would benefit from this,
and we should try to make it work.
iank: Can you give an example?
flackr: This is a good way to handle cases where you want some
visuals that show up above your scrolled content, but your
scrollbar doesn't, so the image in Matthew's comment shows
an example there with a chat widget where the text scrolls
under the header (and is blurred by a backdrop filter) but
the scrollbar doesn't.
iank: That could also be solved with a z-index fix to the scrollbar,
maybe? Is this the primary driver?
flackr: Not the z-index, it's the physical size of the scrollbar
should be smaller than the visible side of the scrolled
content
flackr: In the chat support widget example, the scrollbar starts
below the header. The header is outside the scroller.
<bramus> +1 to this example/use-case. I needed something like this
just recently.
flackr: I see a lot of sites that have this issue where scrollbars
don't line up with their visual affordances, and I think
this API provides a path to fix that.
iank: My problem is overflow-clip-margin can go negative, and that
brings up additional questions
flackr: there may be other ways to do this
iank: This doesn't feel like overflow-clip-margin to me but I could
be wrong
flackr: The chat widget would have an overflow-clip-margin of
-(header size).
flackr: Or, positive. whatever makes stuff outside the scroller
visible
emilio: We do have a property already to specify the scroll distance
to bring elements into view
emilio: The use-case for the header seems like we should use that?
emilio: scroll-padding
emilio: So it seems there's a use-case to maybe put the scrollbar
only in the scroll-padding area
emilio: May be another way of solving this
emilio: Haven't made up my mind about making the scroller smaller
and content overflowing it, which is kinda weird, or tweak
the positioning of the scrollbar via scroll-padding
<iank> a control to shift the scrollbar seems slightly better
bramus: Maybe another approach is instead of specifying distances is
to specify "overflow on x-axis" is simple visible and a
wrapper around it would clip it?
<flackr> +1 I was thinking a common pattern would be an ancestor
applies a clip so that it doesn't infinitely overflow
bramus: In the chat support widget, there's a wrapper around the
whole thing that's preventing the chat content from being
visible
bramus: That avoids the concern about numbers.
fantasai: Using specific overflow-clip-margin is problematic, you
shouldn't be trying to predict fixed pixel values
fantasai: Makes it incompatible with allowing wrapping, etc.
fantasai: So I don't know this is a good fit for the use-case, but I
don't know what the right solution is either.
miriam: I also don't necessarily think scroll-padding is right here,
it defaults where to scroll to. Here you still want to
scroll to the top, just want things to be able to scroll
past that position.
fantasai: Maybe now we need scroll-scope that hoists the layout
scope of a descendant scroll container?
flackr: My expectation is the way devs will use this is they have an
ancestor that still clips the content, and having pixel
values is not desirable
flackr: Maybe you make scrollable overflow visible and it's clipped
by an ancestor instead.
<bramus> `overflow: scroll-visible` 🤨
miriam: So it sounds we're moving in the direction of a new
property, rather than re-using overflow-clip-margin?
miriam: Do we want to resolve on the overflow-clip-margin behavior,
and open a new issue for the remaining cases we still want
to handle?
emilio: I think overflow-clip-margin isn't necessarily the right
property for this use-case, so acknowledging we want to
solve them and open a separate issue probably makes more
sense.
fantasai: Two side suggestions
fantasai: from bramus, `overflow: scroll-visible;`
fantasai: from someone else, a keyword to overflow-clip-margin
(`infinite`?)
<flackr> overflow-clip-margin: infinite was me :-)
PaulG: If something is beneath the margin, and overflow-clip-margin
is set, and there's something interactive in that text (a
link), is is possible for that to come into focus when
tabbed? Or will it only scroll to its normal limit and not
come further in due to the clip?
flackr: Not 100% sure I followed, but assuming it's just a visual
clip change, then you wouldn't be able to scroll to the new
area.
PaulG: Sounds unhelpful, yeah.
flackr: Right, the other solutions expand the clip instead.
argyle: Another use-case. I have shadows on boxes inside of
scrollers, I'd like them to leak out. Right now they're
clipped.
argyle: So similar case, I want the scrollport to contain and create
a scrollable area, but not clip paint.
miriam: And we're at time, we'll take back to the issue
Received on Thursday, 18 May 2023 00:20:33 UTC