- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 19 Dec 2024 19:34:38 -0500
- 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 UI
------
- There were multiple clarifying questions about the proposal in
issue #11185 (select:hover and select:active styles).
- There is an exception for top layer in the proposal, but it wasn't
clear if that exception was enough to prevent breakage in menus.
The carousel scroll-marker/group is not in the top layer and
would still need some exception as well.
- Creating a CSS property was discussed as an alternative, though it
could create loops so needed to be approached mindfully.
- Discussion will continue on the github issue.
CSS Values
----------
- RESOLVED: Adopt ident() function into css-values-5 (Issue #9141: A
way to dynamically construct custom-ident and
dashed-ident values)
Administrivia
-------------
- Group members were requested to register for the next F2F if
they're planning on going https://wiki.csswg.org/planning/cupertino-2025
View Transitions
----------------
- RESOLVED: Use the `match-element` keyword for this and disallow it
as a value in view-transitions-1 spec (Issue #10995:
Allow an auto-generated `view-transition-name` that
doesn't default to ID)
CSS Inline
----------
- The proposal for issue #10834 (inline boxes and line-fit-edge vs
text-box-trim/edge) was introduced for more discussion in the
next meeting.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Dec/0008.html
Present:
Rachel Andrew
Jake Archibald
Adam Argyle
Rossen Atanassov
David Baron
Oriolr Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Stephanie Eckles
Elika Etemad
Mason Freed
Chris Harrelson
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Vladimir Levin
Chris Lilley
Eric Meyer
Noam Rosenthal
Jen Simmons
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Regrets:
Tab Atkins-Bittner
Kevin Babbitt
Robert Flack
Lea Verou
Scribe: noamr
Scribe's scribe: bramus
CSS UI
======
select:hover and select:active styles
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11185
dbaron: The issue came up from customizable select
dbaron: look at the screen capture in the issue
dbaron: I believe the issue is showing with the default UA styles for
customizable select
dbaron: whether or not it should be part of the UA styles is separate
dbaron: Regardless of the default UA styles, these would be custom
styles people would want to write for customizable select and
others
dbaron: The problem is that :hover and :active are hierarchical
dbaron: Where this shows with customizable select, is that if you
hover an option in the popup of the select, it makes the
customizable select "hover"
dbaron: CSS can't distinguish between "the select is being hovered"
and "something in the select is being hovered, e.g. a popup"
dbaron: masonf suggested that we break the hierarchical nature of
:hover/:active for the top layer
dbaron: Putting something in the top layer is a strong indication
that you probably don't want the hierarchical hover/select
behavior
dbaron: Welcome to chime in on how to word it, but less important for
the call
dbaron: I want to get consensus that this is a reasonable direction
<JakeA> Seems reasonable
<ydaniv> +1
<joshtumath> +1 to making an exception for top-layer
astearns: Just hover and active? Or other hierarchical pseudos?
<JakeA> focus?
dbaron: I think it's just :hover and :active? Not sure about
:focus-within
dbaron: Haven't thought deeply about :focus-within, maybe not.
masonf: Makes more sense to keep current behavior for :focus-within
fantasai: :focus-within is sometimes used specifically for this, e.g.
that the focus is within the popup, so would not change it
astearns: If we make this change, can we somehow enable the current
hierarchical behavior?
dbaron: You could do it with :has
dbaron: Doable, but the vast majority case here is what we propose
<miriam>:hover:not(:has(:hover))
masonf: +1, it's the most common case
JakeA: Would the same happen for JS events related to hover?
dbaron: I don't think we will currently be proposing this
dbaron: not proposing DOM event changes
masonf: +1, in CSS this is confusing, but in JS changing bubbling in
this way would be confusing
dholbert: One use of :hover is to show which a element would be
activated
dholbert: Would that change that behavior?
dbaron: Probably true. It's probably a bad idea to put interactive
content inside an A element.
noamr: Recursive interactive elements are against ARIA guidelines
ydaniv: This is the default behavior for menus, working as we
expected. So this would be breaking menus
dbaron: There is a question of whether menus are in the top layer?
masonf: It depends on how you construct the DOM tree to build the menu
masonf: The prev example does do exactly that - you can currently
activate a link from within the top layer
ydaniv: I think people rely on the current hover behavior
masonf: It's still possible to do that
masonf: Are you saying there might be a compat issue?
ydaniv: Yes
masonf: Need to explore compat
vmpstr: In carousel scroll-marker/group have the same problem, as
when items are hovered the element is hovered. There is no
top layer there. Perhaps the solution is not about top-layer
JakeA: Perhaps a CSS property that creates a boundary for active/
hover etc?
JakeA: That can be in the UA stylesheet
vmpstr: That would work for my use case
kizu: I think a CSS property might be dangerous, we try not to create
loops
kizu: Maybe an HTML attribute?
kizu: Like enabling it by default for select and not other elements?
<JakeA> good point about the loop. It's always the loop
noamr: Perhaps we can use overflow for this?
noamr: If an el is hovered and has an area outside of its normal
overflow and that is hovered, then the element itself is
probably not hovered
noamr: Not going to help people relying on it today, but better than
relying on top layer
noamr: Not sure
dbaron: That might get too many other cases where we want the
hierarchical behavior
masonf: I really like the idea of a CSS property
masonf: An attribute can be a lot cleaner
vmpstr: Should be CSS, because it's pseudo-elements
dbaron: I think we already have solutions for loops for hover/active
dbaron: We already break loops for hover/active
dbaron: As long as we don't also touch other things like focus within
masonf: How does it break the loop?
dbaron: We don't have spec definitions/interop, but we break loops. I
think we update it only once for refresh cycles
kizu: In Safari/firefox it doesn't exactly work
dbaron: Hover/active already fully have this problem
bramus: Would this also apply to regular select, or only customizable
select?
masonf: The old style select doesn't set hover
<bramus> https://codepen.io/bramus/pen/GgKWmVg/6a7fa40ecea75e5f07e423d32cc07a7f
bramus: It does, see demo ^^^
bramus: They apply in chrome/safari, not firefox
dbaron: I wouldn't be surprised if it's OS specific as well
masonf: One key difference is that you can do interesting things with
the options, but not here
astearns: A bit concerned making special case for top-layer when it
catches thing that we might not want to catch, and might
not work for non-top-layer things
astearns: Maybe go back to the issue?
noamr: Maybe can be another contain? As in “your hover is contained”.
perhaps can do something like that. Need to think about it
further.
ydaniv: Contain might put us in a loop? Perhaps a new hover-*/
active-* sort of things that don't bubble?
<kizu> https://codepen.io/kizu/pen/GgKWEZp — CSS hover loop example,
behaves differently in Chrome, Safari, and Firefox (but, well,
works)
astearns: Taking back to the issue
CSS Values
==========
A way to dynamically construct custom-ident and dashed-ident values
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9141
bramus: This is about dynamically constructing dynamic idents/
dashed-idents. For when authors need to come up for idents in
multiple elements in one go
<bramus> https://github.com/w3c/csswg-drafts/issues/9141#issuecomment-2536648501
bramus: e.g. view-timeline-name. The ident() function together with
attr(), can have those created in one go
bramus: see examples
bramus: e.g. combining the data-* attribute with other strings
bramus: Another example where view-transition-name is dynamically
constructed from the enclosing element
bramus: Proposing an ident() function with space-separated items, can
be string/integer/ident
bramus: Can you just use attr?
bramus: Sometimes you need to glue pieces together, some of which are
attr and some not, e.g. strings
bramus: Sometimes you need to refer to that name, you can't always
put it as an attribute-specific value like
"view-transition-name: auto"
<kizu> +1, wanted this in 2016
astearns: A bit concerned that stitching together ident() really
depends on the context in which the function is being used
astearns: I can see myself being confused about why my ident() is not
matching because of not thinking of the context
bramus: Dev tools can definitely help with that, to find the
generated values
bramus: Like see a mapping of references to names in view-timeline etc
miriam: To clarify, when creating idents like this in CSS, it
generally means we have to refer to them somewhere else
miriam: In most of these pieces it makes sense that you've created
the name, and then you need to reference them
bramus: In view-timeline, set on non-parent elements, each photo
might have its view-timeline, but the dots might not be
descendants and still refer to the images by name
bramus: so e.g. the sibling-index() can be used with ident() to
rebuild the ident()
noamr: One issue of this is css custom props where you put on an an
ancestor and then refer to that var
noamr: Sometimes the attr you want is somewhere above and the
participating element is somewhere down below
bramus: Similar to how the attr() behaves when used in a custom prop,
they resolve before inherited
bramus: One of the examples is where the cart stores an attribute
into --id custom property, and down the line an ident()
function uses that value
PROPOSED RESOLUTION that we resolve the feature
fantasai: proposal should be to adopt to the css-values-5
PROPOSED RESOLUTION: work on this issue in css-values-5 draft
<fantasai> PROPOSED: Adopt ident() function into css-values-5
astearns: Objections?
RESOLVED: Adopt ident() function into css-values-5
Administrivia
=============
<astearns> https://wiki.csswg.org/planning/cupertino-2025
<fantasai> Register for the F2F! ^^^
astearns: Please update the wiki with your availability
astearns: Dates have been confirmed
astearns: (for the f2F)
CSS View Transitions
====================
scribe: bramus
Allow an auto-generated `view-transition-name` that doesn't default
to ID
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10995
noamr: We have a way to generate view-transition-names with the
keyword `auto`.
noamr: auto generates name based on the id attribute or element
identity when two elements on both end of the VT are the same.
noamr: the id approach also works cross-document
noamr: we are proposing other value where it does not try to do the
`[id]` check first. only uses element identity, only working
in same-doc VTs
noamr: in the breakout for VTs a few weeks ago Elika proposed
match-element which we like
noamr: we are proposing to put that as a function for the purpose of
feature detection
noamr: because right now `view-transition-name: match-element` parses
as supported
noamr: important to ship both things together. bigger groups of
people who ship sites need a better layering.
noamr: auto has a better default behavior, but want to allow people
to use a clean re-separation if they so choose
fantasai: so the view-transition-name accepts none and custom ident,
which start with double dash
fantasai: browsers should be rejecting any value that does not start
with --
fantasai: don't think we should introduce `()`
bramus: dashed idents are subset of custom idents
<vmpstr> +1
fantasai: oh, right. still don't like the parenthesis
fantasai: implies there's argument, but definitely there's none
JakeA: I think we should unship/unspec `auto` as it exists now
JakeA: aim of VTs was to have same behavior for same-doc and cross-doc
JakeA: `match-element` is a useful departure from that but need to
make it clear that the behavior only works in one of the two
JakeA: `auto` muddies the water as it has `match-element` but also
`[id]` and creates this half-working feature but definitely
different between MPA and SAP
JakeA: I don't think that `auto` as “will do it all for you” here
JakeA: might come up with other triggers like hover - should make
sure definition of a transition is the same
emilio: strong agree with fantasai. no need for (). lot of other
props with similar syntax restrict which idents they can parse
emilio: am sure we can come up with an ident that is not a compat
concern
fantasai: like to focus on noam’s ask of whether we add match element.
fantasai: let's discuss meaning of auto later
JakeA: I want to make sure that `match-element` is not as useful as
people think it is
JakeA: similar in codepen/tech demos
JakeA: but if you are doing a page transition, its common for simple
case to replace large parts of the DOM using innerHTML, which
are different elements
JakeA: element equality is not guaranteed
<JakeA> That's an argument for not adding this behaviour into
something like `auto`
<JakeA> …because it's a complex behaviour and you need to know what
you're opting into
noamr: regarding compat: we could go back to CSS vt-1 and make it an
illegal keyword
noamr: think about compat is not about whether sites use it, its
whether sites would catch it
noamr: to go back to vt-1 then say that its illegal, then new
implementations can do that
noamr: instead of try and parsing it as a name
noamr: but right now in current implementations it does parse
<dbaron> For what it's worth, I think I have different opinions about
element equality: https://dbaron.org/log/20200221-dom-identity
fantasai: there is a wide grey area in types of ?? and web apps
between a demo page and something that is using a
particular framework style
fantasai: we should be designing CSS to be usable and comfortable
to it
fantasai: I reject his argument that element identity is not useful
at all on real websites
JakeA: didn't say it wasn't useful at all, but that it is less useful
JakeA: I covered other ground of simple page changes that fetch data
and innerHTML it
JakeA: in all simple demos I created they use innerHTML
JakeA: widely used pattern, outside of frameworks
<noamr> agree that match-element is useful for a lot of the spectrum,
but attr() and ident() can cover a lot of the more complex/
frameworky cases
JakeA: I am worried about kicking the auto discussion down the road
JakeA: concerns were raised in October and safari shipped in December
JakeA: not covering now could leave us stuck with it
fantasai: given that chrome is not even shipping can indicate that
its a really useful feature
fantasai: if we both shipped it and it was harmful then it would be
urgent to remove
fantasai: fine to discuss, but don't think we need to resolve today
necessarily
<astearns> -1 to the practice of allowing browsers to ship things and
then see if compat issues come up
JakeA: agree with it just being safari then there is less of a risk
JakeA: but don't like that being used as an excuse
JakeA: more worried about that if it does get used, it's sold as a
“we'll do things for you” but it has footguns detailed in the
thread
JakeA: could block us from doing useful things in the future
bramus: re match-element being a function, it solves a short term,
while in the long term a keyword would be best
bramus: fine with match-element as a keyword, even without it being
feature-detectable
<fantasai> +1 let's design for the long term
astearns: at the very least I would appreciate it if the Safari would
stop talking about the `auto` value until we figure out
whether we can support it long term or want it to go away
astearns: the less it gets evangelized the more options we have in
the future
Rossen: ok, let's see if we can wrap this up
noamr: proposed resolution would be then to have match-element as
keyword and thus to disallow it as a name in v-t-1
<JakeA> +1 to `match-element`
Rossen: Any additional feedback or objections?
fantasai: overall sounds good
fantasai: did we call the other names? `self` and `match-element`
fantasai: tab commented we should have a keyword that also works
equally well in `random()`
Rossen: which one of the two is currently being used in the issue
or spec?
fantasai: mostly `match-element` is used
Rossen: can we stick to that for now and bikeshed later?
<vmpstr> +1 to `match-element`
noamr: this is already result of a lot of bikshedding in the issue
and a breakout before
noamr: I suggested `self` but like `match-element` today
Rossen: OK
<JakeA> (I'm not tied to the name `match-element`, as long as it's a
name that suggests the behaviour as much as possible)
RESOLVED: use the `match-element` keyword for this and disallow it as
a value in vt1 spec
CSS Inline
==========
inline boxes and line-fit-edge vs text-box-trim/edge
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10834#issuecomment-2540644321
fantasai: Was making the edits for this and noticed we have an issue
around
fantasai: resolution wasn't 100% clear.
fantasai: Have two different line height sizing modes
fantasai: depending on line fit
fantasai: We resolved to make text-box-trim affect inline boxes
fantasai: and it definitely affects where the content edge is drawn
fantasai: We have a transparency principle
fantasai: An unstyled span around some text should not affect layout
<fantasai> So, for example, <em>Some text</em> and <em><span>Some
text</span></em> must have identical rendering, no matter
what styles are applied to <em>.
<fantasai> Proposal Part A: When line-fit-edge is normal, we ignore
the margin/border/padding and just use the line-height for
sizing. In this case, text-box-trim changes the content
edge (affecting backgrounds and borders), but does not
change the height contribution of the inline (which
continues to be based on line-height).
Received on Friday, 20 December 2024 00:35:10 UTC