- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 15 May 2024 19:37:39 -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.
=========================================
Anchor Positioning
------------------
- RESOLVED: Make position a shorthand of position-anchor and a new
position-type property. The shorthand resets both (Issue
#10321: `position-anchor` should be defined as a longhand
of `position`)
- RESOLVED: Fix definition of revert-layer's behavior to match the
general behavior elsewhere (Issue #10319: revert-layer
should only revert the Position Fallback Origin)
- RESOLVED: Rename implicit to auto in position-anchor (Issue #10312:
Initial value of `position-anchor` should be `auto` not
`implicit`)
- RESOLVED: Drop the keyword from the anchor() function (Issue #10312)
- RESOLVED: If inset-area spans two tracks we'll align toward the
missing track instead of centering (Issue #10313: Default
alignments for inset areas are wrong)
CSS Contain
-----------
- RESOLVED: Container queries and units use the flat tree (Issue
#5984: CQ vs shadow boundaries)
View Transitions
----------------
- There was general agreement on having an 'auto'-like solution and
an 'attr()'-like solution for issue #8320 (view-transition-name
determined by element) but not yet agreement on the details for
the approach. Discussion will return to github to draft up a more
concrete proposal.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0008.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Daniel Holbert
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Vladimir Levin
Peter Linss
Florian Rivoal
Khushal Sagar
Alan Stearns
Miriam Suzanne
Regrets:
Chris Lilley
Bramus Van Damme
Lea Verou
Chair: astearns
Scribe: flackr
Administrative
==============
astearns: TabAtkins is coeditor of css-ui-4
astearns: We're likely to have another OpenUI-WHATWG/HTML-CSSWG task
force meeting next Thursday morning, will post details later
astearns: With CSS day and other responsibilities, neither Rossen nor
I will be able to chair first week of June, may have to skip
<fantasai> +1 I think a lot of us will be busy between CSS Day and
the Igalia hackfest
Anchor Positioning
==================
`position-anchor` should be defined as a longhand of `position`
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10321
fantasai: In earlier issue we renamed anchor-default to
position-anchor, motivation was to allow position to be
shorthand of this and possibly other stuff later. We didn't
resolve on short-handing relationship. Designing a syntax
that accommodates everything can be deferred but we need to
decide whether position reset it now
<florian> +1
<kizu> +1
<masonf> +1
TabAtkins: Sounds good, we don't have a strong opinion either way
astearns: Do we need a resolution for both the shorthand and that it
reset?
fantasai: Yes
emilio: It feels weird that if you had an anchored thing that is abs
pos, and you want to make it fixed pos you now need to fight
with the reset on position-anchor. Authors may find that
confusing
fantasai: The current values of static | absolute | fixed | etc
should probably be their own longhand as well so you don't
have to have that fight
fantasai: i.e. we'll have a longhand for those position values
<iank> Modulo any compat constraints, shorthanding properties which
have existing since the beginning of time a higher risk than
others.
emilio: I think people will do position: fixed or position: absolute
anyways without thinking that it reset but this is fine as a
proper solution
fantasai: Our proposal for the longhand is position-type
TabAtkins: It would be nice to have the additional longhands, I don't
think this blocks anything. It's slightly awkward but I
think okay that you need to reset the anchor
emilio: But you need to define the longhands?
TabAtkins: Not necessarily. Since it's reset only the other longhands
don't need to exist
fantasai: They do need to exist
TabAtkins: Right, internal property
emilio: I don't think this works even if it is an internal property
because shorthands aren't typically included in enumerations
astearns: There might be a web compat risk?
emilio: Definitely
TabAtkins: Is that a general issue we would have with any properties
becoming shorthands?
emilio: We have the issue when it becomes a shorthand it stops
getting enumerated and the longhands become enumerated. We
don't have the issue that the longhand is hidden so the
property isn't enumerated
TabAtkins: Then I propose position-type
fantasai: Or position-style like text-wrap-style or list-style
<kizu> +1 to `position-type`
florian: I like type better
astearns: Me too
astearns: At this point, can we resolve on making position a
shorthand of position-anchor and position-type?
astearns: And then worry about the enumeration issues later
emilio: I think this is fine. The big risk is someone enumerating
styles and copying them over. If we have both longhands then
it's not as much of a worry
iank: It's more of a risk for people manipulating styles directly.
When the enumeration disappears they may be relying on position
always being in the enumeration
iank: We've seen this before, most recently white-space, where people
assume the property will read back the same as the property
they set
astearns: Is this something where you would like to wait on the
decision until we have a compat assessment? Would you
object to a resolution?
iank: Taking a resolution is fine, but we might get regressions and
have to revert and take another resolution
iank: shorthanding properties that have been around since time
immemorial carries risk
fantasai: Can we update the way we handle this to include shorthands
in enumeration for these cases to avoid the problem?
iank: I think this may break things even more
astearns: This might be worth opening another issues to discover
whether the pitfalls are better or worse
emilio: If you do this you get redundant properties. We could special
case some legacy ones, but this is iffy. The order is
lexicographical if you have cases where a shorthand shows up
between longhands
astearns: Okay, let's have a separate issue for enumerating
shorthands, for this issue the proposed resolution is we
make position a shorthand of position-anchor and a new
position-type. The shorthand resets both
fantasai: And we should add a shorthand syntax that's not resetting
florian: But that's not urgent
RESOLVED: Make position a shorthand of position-anchor and a new
position-type property. The shorthand resets both.
CSS Contain
===========
CQ vs shadow boundaries
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-1969538606
emilio: The current behavior of cq and cq units is weird for authors,
especially the units. For stuff like style queries, current
behavior is using the regular dom which kind of makes sense.
But for style queries you really want the flat tree
emilio: We opened this as a result of another issue filed on the
units which are right now defined to behave like the queries.
The original resolution isn't the best for authors, I think
it's a bit weird. miriam thinks so as well and maybe this is
worth reverting.
emilio: Firefox implements what I'm proposing and we haven't run into
any issues so I think the compat risk is small
miriam: I've felt strongly from the start that we went the wrong way.
CQ are very much akin to inheritance in a lot of ways and
should be treated in that way rather than as selectors in
terms of relation to shadow dom. They're all about context
and shadow elements and slotting creates context which should
be able to be accessed
TabAtkins: Ultimately I agree [missed]
kizu: May be worth mentioning named CQ where we cannot assess a named
entity from outside of the shadow dom
astearns: Any other comments / concerns?
emilio: Would be interested in hearing rune's thoughts, can weigh in
on issue
Proposed resolution: Container queries and units use the flat tree
RESOLVED: Container queries and units use the flat tree
Anchor Positioning (Con't)
==========================
scribe: emilio
revert-layer should only revert the Position Fallback Origin
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10319
fantasai: This one is I think an oversight in the spec
fantasai: revert-layer is defined to revert to author origin but
that's not how it works
TabAtkins: Yeah I don't think I had paid enough attention to
revert-layer, will fix in the spec
RESOLVED: Fix definition of revert-layer's behavior to match the
general behavior elsewhere
Initial value of `position-anchor` should be `auto` not `implicit`
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10312
fantasai: The initial value of `position-anchor` is `implicit`
fantasai: advanced vocabulary, but we probably don't want to expose
this to authors
fantasai: Propose to rename `implicit` to `auto`
fantasai: and then this keyword also shows up in `anchor()` where we
can rename it to `auto` too or just drop it because I don't
think it's necessary
TabAtkins: We should just drop it, if you omit it you get that
behavior
TabAtkins: I generally want to make sure that implicit behavior is
specifiable, but not necessary
florian: Seems more consistent to how we name things
RESOLVED: Rename implicit to auto in position-anchor
RESOLVED: Drop the keyword from the anchor() function
Default alignments for inset areas are wrong
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10313
fantasai: Initial value for align/justify-self is normal
fantasai: generally depends on context to an appropriate behavior
fantasai: For inset-area we try to make the default alignment for the
area useful
fantasai: so if you're in the center track we center
fantasai: If you're on the edge we align toward the area
fantasai: If you're spanning into two tracks
fantasai: and there the default is anchor-center, but that's
generally not what you want
fantasai: The usual thing is to align towards the track you're
excluding
fantasai: it's easy to center if needed
kizu: Tested right now, I think it works well when the anchor is
smaller than the positioned element
kizu: When the anchor is bigger it looks better with anchor-center
fantasai: Typically in that case you keep aligned to one edge and
overflow
kizu: Can we define anchor-center to try not to shrink to the center
area
kizu: Only if it's not fitting shifted it'd work better
TabAtkins: Tracked on a different issue
TabAtkins: not on the agenda this week
kizu: No objection then
TabAtkins: No objection from us either
TabAtkins: What kizu described was the originally what I wanted
TabAtkins: but I deferred the shifting
TabAtkins: because I wanted to fix it more generally
TabAtkins: So tl;dr agree with the change
TabAtkins: Also our impl actually matches that resolution because
engineers misread the conditions
PROPOSED: If inset-area spans both of the tracks we'll align toward
the missing track instead of centering
RESOLVED: If inset-area spans two tracks we'll align toward the
missing track instead of centering
View Transitions
================
view-transition-name determined by element
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8320
vmpstr: Unique names for transitions is cumbersome because authors
need to come up with a bunch of unique names
vmpstr: Various proposals
vmpstr: One is to have view-transition-name: auto / from-element
which matches with element identity
vmpstr: so as long as it doesn't change it works nicely
vmpstr: but it doesn't work with cross-document transitions
vmpstr: and also for frameworks that might replace the dom nodes
vmpstr: Another proposal is `element-uuid()` but it's effectively the
same as above, just more explicit
vmpstr: Another one is `attr()`, which would work for cross-document
view-transition and frameworks
vmpstr: My proposal would be to do both
vmpstr: leaving attr for more advanced use cases
fantasai: I think doing both (`auto` / `from-element` and `attr()`)
makes sense
fantasai: there was another idea in the thread which needs more
thought
fantasai: right now we restrict view-transition-name to be unique
fantasai: if it's not it gets ignored or something, it's an error
condition
fantasai: in a bunch of cases, let's say you're shifting items after
inserting into a list or so you don't necessarily want to
number them all
fantasai: if we could have multiple names and we could number them
somehow automatically that might help
fantasai: but that might be doable in addition to these things
emilio: My main concern is how likely is it for someone to use from
element and not realize it doesn't work for cross document?
emilio: From where I stand it seems obvious it doesn't work, but
requires some internals knowledge
emilio: Just a mild concern, not blocking.
fantasai: View transitions has been focused on the fact that you have
"pages", and you're changing pages from one page in a web
app to another one
fantasai: but lots of transitions authors can do are single-page
fantasai: and sometimes view-transitions is the best tool
fantasai: For those cases this element identity stuff it's not an
issue
<ydaniv> +1
emilio: For those use cases this is fine, it just feels like it might
be confused
emilio: or worse the browser could accidentally have a same pointer
emilio: I guess that's just a bug
flackr: My comment is somewhat related
flackr: While I agree that attr() should be supported
flackr: if the common case is an identity
flackr: maybe we can roll it into `auto` in-some cases
flackr: So if element has an `id` attribute then `auto` would take
that
flackr: or an ancestor one or something
<fantasai> interesting
vmpstr: We still need to define for the `auto` cases
vmpstr: We still need some identifier that an author can see
vmpstr: I think the element's uuid is a good choice there
vmpstr: but we haven't thought too much about it
<fantasai> -1 to uuid
<fantasai> if the author wants to reference it they should give it
a name
<fantasai> using the id attribute
<vmpstr> it's about the param in ::view-transition-group(param) etc,
not sure what to put there, or leave it as "auto"?
astearns: I think the automatic number is interesting but has a
different set of failure modes that it probably could be a
separate issue
astearns: I wanted to push back a bit, it seems a bit of a smell that
people don't want to put unique names in css so we make
them put it on the markup?
fantasai: A lot of times you have these unique ids already
fantasai: so you might as well just reuse them
<fantasai> I like flackr's idea of having `auto` take the ID if it
has one, and fall back to element identity matching
otherwise
emilio: Just want to confirm, allowing attr would make this id
mutable in some interesting ways. I guess we have a well
defined point where we collect them so it doesn't add much
complexity, right?
khush: I imagine it's similar to attribute changes requiring
recomputing style
emilio: My point is, if the mutation happens after we start the
transition, then presumably it shouldn't count? This detail
probably needs to be mentioned
khush: This is called out already for view-transition-name as it's an
issue already for name changes
emilio: Sounds good
emilio: The auto thing seems like it could use a bit more work since
as vmpstr mentioned the name is exposed in the css. My slight
preference is to resolve attr and figure out auto later
emilio: Happy to also resolve on auto and resolve the details later
khush: +1 to fantasai, attr() is useful where you already have unique
names for your items without having to use JS
khush: The other thing is, I think we'll have an easier time
resolving on attr()
<flackr> +1 as well, css is often in a separate file and not unique
per element
khush: For auto / from-element vs element-uuid
khush: there was an example where element-uuid could be used to name
an ancestor or child of an element rather than auto
khush: auto would only allow to set the id on that element itself
khush: One other point was that anything that ties with element
identity it doesn't work for MPA
khush: We might want to just ignore the name altogether for MPA
transitions
khush: so it's harder to miss
khush: but I think we should probably resolve on attr() and work on
the other details on transitions
astearns: I wanted to ask whether it'd make sense to make
from-element only work on SPA and reserve auto for
something that can work eventually on MPA
astearns: So resolve on from-element for now, and opening an issue on
an additional auto which does something along the lines
that flackr was suggesting
vmpstr: I don't mind the idea but I'd like a different name that
from-element
vmpstr: I'd prefer a different id
vmpstr: because from-element seems you're reading something from the
element rather than using the element itself
TabAtkins: Can we take it back to the issue? random() has similar use
cases and we should make sure they're in sync
flackr: For auto / from-element it was mentioned that this is exposed
flackr: Is that necessary?
flackr: Are there other ways we could do it?
vmpstr: We can hide it by using auto
vmpstr: We don't currently have the same parameter in the view
transition pseudos I don't think it's a problem
vmpstr: The reason we added view-transition-container is similar
vmpstr: so I think we can hide it
flackr: I think you can expose the initial style without a name
khush: Web animations might be weird because you get a list of
pseudos and can't differentiate it
khush: Any place the name would have appeared then it'd be replaced
with auto
flackr: That's one possibility
flackr: maybe there are others
flackr: worth exploring
khush: We use ua css to put styles, we need to figure out how the UA
css would work
flackr: Right, but that can be an implementation detail
fantasai: I like flackr's suggestion of auto pulling the id if it has
an ID and otherwise uses other way of identity
fantasai: I agree we don't want to expose randomly generated IDs into
author CSS
fantasai: They can given it a name if they need to target something
khush: attr() didn't ship for reasons
fantasai: Let's draft some more concrete proposal
fantasai: and come back
vmpstr: Vague resolution is fine and we can come back with details
Received on Wednesday, 15 May 2024 23:38:11 UTC