- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 29 Mar 2023 19:51:19 -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 Cascade
-----------
- RESOLVED: Accept the CSSScopeRule design, with the three changes
noted in the thread (Issue #8626: What is the desired
shape of CSSScopeRule?)
CSS Text
--------
- RESOLVED: Add break-spaces to white-space-collapse (Issue #3794:
white-space:break-spaces is in level 3 but not level 4)
- RESOLVED: Accept the proposed addition to the 'white-space'
grammar [addition is <'white-space-collapse'> ||
<'text-wrap'> || <'white-space-trim'> as values for
white-space shorthand] (Issue #5382: Multi‑value
`white‑space` syntax proposal)
View Transitions
----------------
- RESOLVED: Snapshot raster is theoretically infinite. Snapshot has
a "natural view box" of the snapshot element's border
box (giving the natural size). Object-view-box can
change this view box (Issue #8597: Exposing ink overflow
rect bounds to script)
- RESOLVED: Closed invalid, fixed by the #8597 resolution (Issue
#8606: Clarify the size of snapshot when there are
nested transitioning elements)
CSS Selectors
-------------
- RESOLVED: Add :popover-open pseudoclass, undefined popoverness
from :open (Issue #8637: Introduce `:popover` pseudo
class)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Mar/0013.html
Present:
Rachel Andrew
Adam Argyle
Rossen Atanassov
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Jonathan Kew
Peter Linss
Alison Maher
Myles Maxfield
Eric Meyer
François Remy
Jen Simmons
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: TabAtkins
Scribe's scribe: fantasai
Administrivia
=============
Rossen: Planning a separate Nesting breakout next week
Rossen: so pushing out the Nesting issues
Rossen: Any other changes to the agenda?
chrishtr: Can we take issue 8637?
<chrishtr> https://github.com/w3c/csswg-drafts/issues/8637
<fantasai> Drop item 8?
CSS Cascade
===========
What is the desired shape of CSSScopeRule?
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8626
miriam: Anders pushed a definition for the CSSSCopeRule, in the ED
miriam: We didn't have a resolution on the details though, so wanted
to clarify it's defined properly
miriam: Main questions in the thread are terms used for the start
and end of the scope (sometimes called "root" and "lower
boundary"/"scoping limit")
miriam: In thread we decided start/end were clearest terms,
especially if we do sibling scopes - they keep making sense,
while upper/lower don't
miriam: Another question is what to return if one of the values
isn't specified, we suggest null
miriam: Final question, should the value contain the parens around
the selectors? Propose no.
miriam: So proposal is accept the CSSScopeRule, with the three
conclusions outlined above.
<fantasai> +1
<bramus> +1
Rossen: Looks like agreement in the thread, anyone have objections?
RESOLVED: Accept the CSSScopeRule design, with the three changes
noted in the thread.
CSS Text
========
white-space:break-spaces is in level 3 but not level 4
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3794
fantasai: Part of merging level 3 into 4 is making sure we
integrated all the level 3 changes
fantasai: level 4 split white-space into two longhands
fantasai: We didn't have a place to host the break-spaces value
fantasai: So currently we put it as a value on white-space-collapse
<fantasai> https://drafts.csswg.org/css-text-4/#white-space-collapsing
florian: Two positives, one negative
florian: In terms of behavior I think this is the right longhand.
florian: In naming, having same keyword in shorthand and longhand is
nice
florian: But in the context of this longhand, the name isn't
intuitive.
florian: We could rename, but then it would be different keyword
between shorthand and longhand
florian: So I think the current spec is the right compromise, but it
is a compromise
<fantasai> white-space-collapse: collapse | preserve |
preserve-breaks | preserve-spaces | break-spaces
fantasai: Agree it's a little awkward in naming, since we only break
spaces if we *are* wrapping, which is controlled by
another property. It's more like
"preserve-breakable-spaces", but that gets longer.
Rossen: Is there anything preventing us from resolving?
Rossen: Objections?
fantasai: Proposed resolution is to add break-spaces to
white-space-collapse
RESOLVED: Add break-spaces to white-space-collapse
Multi‑value `white‑space` syntax proposal
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5382
<fantasai> https://drafts.csswg.org/css-text-4/#white-space-property
fantasai: As part of making white-space a shorthand, usually we
allow shorthand to express all the longhands
fantasai: Currently shorthand for three props
fantasai: This proposal lets us use all the values of any of those
props. Old stuff still allowed, just an extension. Luckily
no keywords conflict.
fantasai: It's more or less what's in the table in the issue, except
break-spaces maps to a break-spaces value for
white-space-collapse.
fantasai: So is it okay to do this inlining?
fantasai: Second question, for the longhands, are these the keywords
we want? They're a little different from the keywords we
had in white-space before, but they're clearer in what
they mean.
florian: As part of this rename there was the suggestion that nowrap
doesn't have a hyphen, suggestion to fix that by having the
longhand use 'no-wrap'.
florian: I'd advise not to do it - having nowrap in the shorthand
but no-wrap in the longhand would be confusing
<lea> +1 to florian, benefits here too marginal to be worth the
confusion
TabAtkins: I still think it would be worthwhile to have 'no-wrap' as
an alias across all properties
TabAtkins: but also fine not to do that
Rossen: We can start conservative, this would be an added behavior.
<fantasai> PROPOSAL: Adopt <'white-space-collapse'> || <'text-wrap'>
|| <'white-space-trim'> as values for white-space
shorthand
Rossen: Any objections to this white-space shorthand?
RESOLVED: Accept the proposed addition to the 'white-space' grammar.
View Transitions
================
Exposing ink overflow rect bounds to script
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8597
khush: We touched on defining the bounds of the element you capture
at the f2f
khush: One aspect is the natural size of the image is the ink
overflow rectangle.
khush: This can be larger than the border box, so you use
object-view-box to size it
khush: This means the ink overflow rectangle is exposed to authors
khush: But this is currently undefined, what to do?
khush: Two options. One questions whether we expose this at all.
khush: We can censor it in getComputedStyle() and make it !important
in UA styles here.
khush: This can be bad if authors want to customize the size
khush: I haven't seen good use-cases for customizing it tho.
khush: Suggestion from fantasai is to use the scrollable overflow
rect instead
khush: So the natural size authors see is scrollable overflow, but
the browser can actually draw a larger ink overflow
khush: I'm fine with either option from impl.
khush: If scrollable overflow makes more sense as an author-exposed
concept, that's fine
khush: But if ink overflow would be useful we shouldn't shy away
from using it
fantasai: One, I don't think authors want to control layout of stuff
using ink overflow rect. Kinda unpredictable.
fantasai: And not what they're actually measuring. It's excess
stuff, you don't really notice it's there. Serifs on font,
blur on box-shadow, etc
fantasai: So I don't think this is something authors will want to
use.
fantasai: I think we either want the scrollable overflow or the box
fragments, and allow image to overflow the rect in some way
fantasai: Even if we expose ink overflow in IntersectionObserve for
security reasons, I don't think it's something people want
to measure against
<TabAtkins> +1 to fantasai's points
florian: Might be confused, but thought in the general case the ink
overflow was not only under-specified, it wasn't
necessarily finite.
florian: With blurs it can technically be infinite.
fantasai: You're right, though there was a proposal to define the
bounds that it clips. Technically what impls do today
anyway.
flackr: I think hiding the ink overflow rect is one of my proposals
flackr: But my proposal was more that if authors set an ink
overflow, we'd combine it with intrinsic ink overflow from
the image, and they'd always work wrt the border box of the
item.
fantasai: Not sure I'm following, more concrete example?
flackr: Say you have 100x100 box, there's 50px of shadow around it
flackr: The thing presented to the dev is no ink overflow.
flackr: But when we calculate the ink overflow, we'd add the 50px to
whatever we got from the author's ink overflow rect
Rossen: What do you mean by "presented to the dev"
flackr: The value of object-overflow won't expose that shadow size.
khush: I'm also having trouble understanding this - is this similar
to what fantasai is suggesting, where you see the scrollable
overflow as the exposed size?
flackr: Basically the same, probably just an impl detail about how
it works.
fantasai: I wasn't sure if the box we should use is scrollable
overflow or the border box, just pretty sure it shouldn't
be the ink overflow rect
fantasai: If we have the property controlling the clipping, we could
have an "auto" value that computes to itself and works
from the ink overflow
chrishtr: I think what fantasai and flackr are saying makes sense
chrishtr: But khushal, is there any case you've seen where authors
need to know the ink overflow to position correctly?
khush: No, it is handled automatically.
khush: But if authors can set the object-view-box, they get
information about the natural size.
khush: Like if you say "none", then measure the box, you'll get the
size out.
khush: So I'm fine with saying the natural size is the border box or
scrollable overflow, and what authors see is based on that
size.
khush: From what I've heard so far, I think I like the proposal of
scrollable overflow. If we decide not to expose it and
there's a use-case later, it'll be hard to change.
khush: So inclined to exposing it, using the scrollable overflow.
<TabAtkins> +1
fantasai: So we have a replaced element. It contains an image which
is snapshot.
fantasai: The size of that replaced element is the size of the
snapshot element's border box.
fantasai: But like an SVG image, that extends past its viewbox.
fantasai: and we're setting a property that cause the stuff outside
its nominal size to actually paint
khush: Yes, using object-view-box to make the sizing align, and then
anything outside paints as ink overflow, is clipped based on
'overflow'.
fantasai: So on an SVG currently, say I draw a bunch of circles then
set viewbox to 50x50
fantasai: I'll get a 50x50 image, stuff can get drawn outside of
that. If I put this in an <img> they'll get clipped by
default.
fantasai: But they're still there - if I use object-position we're
moving that 50x50 square.
fantasai: object-view-box refers to that viewbox declaration - I
could change it and it would change what portion of the
SVG is "the displayed image"
fantasai: So we're creating a snapshot whose viewbox is the border
box of the snapshot element
fantasai: I think we can conceptually say the top left corner of the
border box is the 0 coord for the image, for the purpose
of object-view-box?
fantasai: Then I think we have an analogous situation
<flackr> +1 that is how I was thinking object-view-box modifications
should work
fantasai: I think this gets us a mental model and an API consistent
with SVG
khush: So you're right about the viewbox descriptions.
khush: But the origin is based on the natural size
khush: object-view-box says to inset from those natural bounds
khush: We have an option to say what amount of overflow is exposed
to authors
flackr: I agree with fantasai's thinking about how this should work,
that matches what I'm imagining
flackr: the ink overflow isn't dev-exposed, just part of the object
we've captured
flackr: so 0,0 is at the border box corner
flackr: Do we capture scrollable overflow even if the source element
clipped it?
flackr: Is it only for overflow:visible we capture?
fantasai: No, we capture what you actually see.
fantasai: I want to change what I'm proposing from what was in the
issue
fantasai: The natural image should be the full size of stuff we see.
fantasai: But the origin of the image should be the border box
corner.
fantasai: Similar to SVG with its viewport
fantasai: In SVG you can draw into negative coords
fantasai: So I'm proposing the origin of the image is the border box
corner. Anything that overflows that is captured for the
snapshot still gets captured.
<flackr> +1
fantasai: So we create a raster image whose origin is not the
top-left corner of the image
fantasai: So that lets us say the natural size is the border box. If
they want to change that, they can do that (so long as
it's captured)
fantasai: and if they extend past what's captured they get
transparent pixels
fantasai: so we don't need to define the boundary of the raster,
just that it captures at least the visible scrollable
overflow
fantasai: everything outside is on an infinite transparent canvas
fantasai: I think that gets us a model where author can do whatever
they want to do
khush: +1 fantasai's suggestion
khush: It's funny we added object-viewbox because what is proposed
now is what we thought about implementing internally, so we
thought a CSS property is a better way to do it
khush: So it sounds now we conceptually do what object-view-box is
doing but expose it to the author
khush: So +1
TabAtkins: Basically what khush said
TabAtkins: Original purpose of object-viewbox was to have natural
size image and cutout the border box part
TabAtkins: but if we're dealing with ink ...
TabAtkins: So default case doesn't need 'object-view-box' at all,
its natural viewbox matches border-box, sounds find to me
TabAtkins: Requires minor spec edits, but good change overall
TabAtkins: and if you want the image to look larger, then you would
use negative coords
TabAtkins: rather than smaller positive coords
TabAtkins: So sounds fine, good overall
Rossen: Can you summarize resolution?
fantasai: proposed resolution is snapshot rasterization is
theoretically infinite. Origin corresponds to top-left of
border box of snapshotted element, natural size is
width+height of border box. Author can use object-view-box
to shift this "natural view box"
<flackr> +1
<ydaniv> +1
Rossen: Comments or objections?
RESOLVED: Snapshot raster is theoretically infinite. Snapshot has a
"natural view box" of the snapshot element's border box
(giving the natural size). Object-view-box can change this
view box.
CSS Selectors
=============
Introduce `:popover` pseudo class
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8637
chrishtr: We previous resolved to add :open/:closed to apply when
popover is opened or closed.
chrishtr: <details> has an open/closed concept independent of in the
top layer, but it can also be a popover.
chrishtr: So we need two axises...
chrishtr: Proposal is we scope :open/:closed to an element's own
notion of being open or closed. New pseudo :popover that's
whether it's in the top layer or not.
plinss: Nit: whether it's "popped over", not necessarily "in the top
layer"
chrishtr: aAgreed
lea: What does the popover pseudo match, exactly?
???: Matches popovers in the open state
lea: So what would :popover:closed ever match?
chrishtr: A closed <details> element that's popover
dbaron: Idea is that it matches popovers who are currently "popover
open"
dbaron: Open and close are reserved for elements that have their own
state.
<fantasai> :pop-open / :pop-closed ?
lea: I think open/closed is fine, but :popover sounds like it
matches any popover element, aka with a popover attribute
regardless of whether it's popping or not
Rossen: So :popover-open sounds like a refinement?
chrishtr: Yes, I think :popover-open is descriptive, a little longer
but useful
lea: I think we had some issues about defining top layer with CSS,
want to make sure this doesn't become an obstacle for that
plinss: Yes, this just reflects the popover state, not what layer
it's in.
<flackr> +1
<chrishtr> +1
Rossen: Seeing +1s in the chat. Can we resolve to add, with the
changed name :popover-open?
plinss: Slight hesitancy due to name getting kinda long.
plinss: Maybe worth bikeshedding the whole feature name? "popover"
is a little weird.
fantasai: Suggestion :pop-open
dbaron: popover is a weird name because calling it popup turned out
to not be web-compatible
Rossen: So :popover-open is proposed resolution
RESOLVED: Add :popover-open pseudoclass, undefined popoverness from
:open
View Transitions Continued
==========================
Clarify the size of snapshot when there are nested transitioning
elements
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8606
khush: Previous resolution makes this much easier
khush: Currently saying snapshot is ink overflow makes nested
transitions hard
khush: What if the nested element is animating itself, you don't
want it in the snapshot.
khush: Given previous reoslution, I think this issue is solved.
<flackr> +1
<TabAtkins> +1
Rossen: Other opinions or objections to calling this fixed by 8597?
RESOLVED: Closed invalid, fixed by the #8597 resolution.
Scheduling
==========
Rossen: Gonna end the call a few minutes early, nothing in the list
can be addressed in this remaining minutes
Rossen: We want to have a summer f2f
Rossen: Expect a poll coming up today
Rossen: Want to know who can attend physically and/or virtually and
figure out if it's reasonable
Rossen: Have some concrete proposals that seem doable, but need to
know schedule and intent to attend first.
Received on Wednesday, 29 March 2023 23:52:04 UTC