16:58:34 <RRSAgent> RRSAgent has joined #css
16:58:38 <RRSAgent> logging to https://www.w3.org/2024/12/18-css-irc
16:58:38 <Zakim> RRSAgent, make logs Public
16:58:39 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:59:33 <dbaron> Present+
16:59:44 <JakeA> Present+
16:59:49 <bramus> present+
17:00:22 <noamr> noamr has joined #css
17:00:42 <kizu> kizu has joined #css
17:00:45 <rachelandrew> present+
17:00:47 <kizu> present+
17:00:56 <rachelandrew> irc only for the first 30.
17:01:09 <joshtumath> present+
17:01:22 <jensimmons> jensimmons has joined #css
17:01:23 <ydaniv> ydaniv has joined #css
17:01:42 <noamr> present+
17:01:43 <jensimmons> present+
17:01:53 <ydaniv> present+
17:02:01 <dholbert> dholbert has joined #css
17:02:39 <Rossen8> Rossen8 has joined #css
17:03:00 <masonf> masonf has joined #css
17:03:17 <masonf> present+
17:03:28 <Rossen8> present+
17:03:39 <jfkthame> jfkthame has joined #css
17:03:52 <stepheckles> stepheckles has joined #css
17:03:53 <noamr> ScribeNick noamr
17:03:59 <stepheckles> present+
17:04:16 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11185
17:04:16 <github-bot> Topic: [css-ui] select:hover and select:active styles
17:04:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11185.
17:04:18 <jfkthame> present+
17:04:35 <emilio> present+
17:04:40 <miriam> present+
17:04:44 <schenney> schenney has joined #css
17:04:45 <ChrisL> present+
17:04:51 <noamr> dbaron: the issue came up from customizable select
17:04:58 <vmpstr> present+
17:05:04 <noamr> dbaron: look at the screen capture in the issue
17:05:19 <noamr> dbaron: I believe the issue is showing with the default UA styles for customizable select
17:05:31 <oriol> present+
17:05:33 <noamr> dbaron: whether or not it should be part of the UA styles is separate
17:05:55 <noamr> dbaron: regardless of the default UA styles, these would be custom styles people would want to write for customizable select and others
17:06:11 <noamr> dbaron: the problem is that :hover and :active are hierarchical
17:06:34 <noamr> 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"
17:06:58 <noamr> dbaron: CSS can't distinguish between "the select is being hovered" and "something in the select is being hovered, e.g. a popup"
17:07:14 <noamr> dbaron: masonf suggested that we break the hierarchical nature of :hover/:active for the top layer
17:07:39 <noamr> dbaron: putting something in the top layer is a strong indication that you probably don't want the hierarchical hover/select behavior
17:07:53 <noamr> dbaron: welcome to chime in on how to word it, but less important for the call
17:08:02 <noamr> dbaron: I want to get consensus that this is a reasonable direction
17:08:03 <JakeA> Seems reasonable
17:08:09 <ydaniv> +1
17:08:18 <noamr> astearns: just hover and active? Or other hierarchical pseudos?
17:08:26 <joshtumath> +1 to making an exception for top-layer
17:08:26 <JakeA> focus?
17:08:36 <noamr> dbaron: I think it's just :hover and :active? Not sure about :focus-within
17:08:48 <noamr> dbaron: Haven't thought deeply about :focus-within, maybe not.
17:09:05 <noamr> masonf: makes more sense to keep current behavior for :focus-within
17:09:10 <chrishtr> present+
17:09:16 <JakeA> q+
17:09:22 <dholbert> q+
17:09:24 <dholbert> present+
17:09:30 <noamr> fantasai: :focus-within is sometimes used specifically for this, e.g. that the focus is within the popup, so would not change it
17:09:58 <noamr> astearns: if we make this change, can we somehow enable the current hierarchical behavior?
17:10:05 <miriam> :hover:not(:has(:hover))
17:10:10 <noamr> dbaron: you could do it with :has
17:10:35 <noamr> dbaron: doable, but the vast majority case here is what we propose
17:10:44 <noamr> masonf: +1, it's the most common case
17:10:45 <bkardell_> bkardell_ has joined #css
17:10:49 <astearns> ack JakeA
17:11:04 <noamr> JakeA: would the same happen for JS events related to hover/
17:11:07 <ydaniv> q+
17:11:09 <bkardell_> present+
17:11:17 <noamr> dbaron: I don't think we will currently be proposing this
17:11:27 <noamr> dbaron: not proposing DOM event changes
17:11:47 <vmpstr> q+
17:11:53 <JakeA> q+
17:11:57 <noamr> masonf: +1, in CSS this is confusing, but in JS changing bubbling in this way would be confusing
17:12:00 <astearns> ack dholbert
17:12:32 <noamr> dholbert: one use of :hover is to show which a element would be activated
17:12:43 <noamr> dholbert: would that change that behavior?
17:13:00 <noamr> dbaron: probably true. It's probably a bad idea to put interactive content inside an A element.
17:13:17 <astearns> ack ydaniv
17:13:24 <noamr> noamr: recursive interactive elements are against ARIA guideliens
17:13:25 <emeyer> emeyer has joined #css
17:13:30 <emeyer> present+
17:13:40 <noamr> ydaniv: this is the default behavior for menus, working as we expected. So this would be breaking menus
17:13:53 <noamr> dbaron: there is a q of whether menus are in the top layer?
17:14:03 <noamr> masonf: It depends on how you construct the DOM tree to build the menu
17:14:28 <noamr> masonf: the prev example does do exactly that - you can currently activate a link from within the top layer
17:14:54 <noamr> ydaniv: I think people rely on the current hover behavior
17:15:01 <noamr> masonf: It's still possible to do that
17:15:14 <noamr> masonf: are you saying there might be a compat issue?
17:15:16 <noamr> ydaniv: yes
17:15:21 <noamr> masonf: need to explore compat
17:15:25 <astearns> ack vmpstr
17:16:10 <noamr> 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
17:16:12 <kizu> q+
17:16:15 <astearns> ack JakeA
17:16:27 <noamr> JakeA: perhaps a CSS property that creates a boundary for active/hover etc?
17:16:38 <noamr> JakeA: that can be in the UA stylesheet
17:16:42 <noamr> q+
17:16:44 <masonf> q+
17:16:54 <noamr> vmpstr: that would work for my use case
17:17:01 <astearns> ack kizu
17:17:14 <noamr> kizu: I think a CSS property might be dangerous, we try not to create loops
17:17:25 <noamr> kizu: maybe an HTML attribute?
17:17:41 <noamr> kizu: like enabling it by default for select and not other elements?
17:17:42 <JakeA> good point about the loop. It's always the loop
17:17:46 <bramus> scribe+
17:17:53 <astearns> ack noamr
17:17:56 <bramus> noamr: perhaps we can use overflow for this?
17:18:19 <bramus> … 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
17:18:36 <bramus> … not going to help people relying on it today, but better than relyigng on top layer
17:18:39 <bramus> … not sure
17:18:49 <bramus> q+
17:18:52 <noamr> dbaron: that might get too many other cases where we want the hierarchical behavior
17:19:07 <astearns> ack masonf
17:19:10 <noamr> masonf: I really like the idea of a CSS property
17:19:21 <noamr> masonf: an attribute can be a lot cleaner
17:19:26 <astearns> q+
17:19:41 <noamr> vmpstr: should be CSS, because it's pseudo-elements
17:19:55 <noamr> dbaron: I think we already have solutions for loops for hover/active
17:20:04 <noamr> dbaron: we already break loops for hover/active
17:20:16 <noamr> dbaron: as long as we don't also touch other things like focus within
17:20:26 <noamr> masonf: how does it break the loop?
17:20:58 <noamr> dbaron: we don't have spec definitions/interop, but we break loops. I think we update it only once for refresh cycles
17:21:10 <PaulG> PaulG has joined #css
17:21:18 <noamr> kizu: in Safari/firefox it doesn't exactly work
17:21:26 <noamr> dbaron: hover/active already fully have this problem
17:21:33 <astearns> ack bramus
17:21:53 <noamr> bramus: would this also apply to regular select, or only customizable select?
17:22:02 <bramus> https://codepen.io/bramus/pen/GgKWmVg/6a7fa40ecea75e5f07e423d32cc07a7f
17:22:04 <noamr> masonf: the old style select doesn't set hover
17:22:10 <noamr> bramus: it does, see demo ^^^
17:22:32 <noamr> bramus: they apply in chrome/safari, not firefox
17:22:42 <noamr> dbaron: I wouldn't be surprised if it's OS specific as well
17:22:44 <noamr> q+
17:22:57 <ydaniv> q+
17:23:00 <noamr> masonf: one key difference is that you can do interesting things with the options, but not here
17:23:36 <noamr> 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
17:23:51 <noamr> astearns: maybe go back to the issue?
17:23:51 <astearns> ack noamr
17:23:56 <astearns> ack astearns
17:24:25 <bramus> noamr: maybe can be another contain? As in “your hover is contained”. perhaps can do something like that. Need to think about it further.
17:24:28 <astearns> ack ydaniv
17:24:49 <noamr> ydaniv: contain might put us in a loop? Perhaps a new hover-*/active-* sort of things that don't bubble?
17:24:50 <kizu> https://codepen.io/kizu/pen/GgKWEZp — CSS hover loop example, behaves differently in Chrome, Safari, and Firefox (but, well, works)
17:25:06 <noamr> astearns: taking back to the issue
17:25:52 <noamr> 17:04 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9141
17:26:05 <github-bot> Topic: [css-values] A way to dynamically construct custom-ident and dashed-ident values
17:26:47 <noamr> 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
17:27:01 <bramus> https://github.com/w3c/csswg-drafts/issues/9141#issuecomment-2536648501
17:27:07 <noamr> bramus: e.g. view-timeline-name. The ident() function together with attr(), can have those created in one go
17:27:10 <noamr> bramus: see examples
17:27:27 <noamr> bramus: e.g. combining the data-* attribute with other strings
17:27:41 <noamr> bramus: another example where view-transition-name is dynamically constructed from the enclosing element
17:27:55 <noamr> bramus: proposing an ident() function with space-separated items, can be string/integer/ident
17:28:11 <noamr> bramus: can you just use attr?
17:28:31 <noamr> bramus: sometimes you need to glue pieces together, some of which are attr and some not, e.g. strings
17:29:05 <noamr> 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"
17:29:12 <kizu> +1, wanted this in 2016
17:29:45 <noamr> astearns: a bit concerned that stitching together ident() really depends on the context in which the function is being used
17:30:08 <noamr> astearns: I can see myself being confused about why my ident() is not matching because of not thinking of the context
17:30:31 <noamr> bramus: dev tools can definitely help with that, to find the generated values
17:30:35 <miriam> q+
17:30:49 <astearns> ack miriam
17:30:50 <noamr> bramus: like see a mapping of references to names in view-timeline etc
17:31:07 <noamr> miriam: to clarify, when creating idents like this in CSS, it generally means we have to refer to them somewhere else
17:31:23 <noamr> miriam: in most of these pieces it makes sense that you've created the name, and then you need to reference them
17:31:24 <noamr> q+
17:32:03 <noamr> 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
17:32:24 <noamr> bramus: so e.g. the sibling-index() can be used with ident() to rebuild the ident()
17:32:32 <astearns> ack noamr
17:32:56 <bramus> noamr: one issue of this is css custom props wher eyou put on an an ancestor and then refer to that var
17:33:15 <bramus> … sometimes the attr you want is somewhere above and the participing element is somwheer down below
17:33:34 <noamr> bramus: similar to how the attr() behaves, they resolve before inherited
17:34:00 <noamr> 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
17:34:08 <bramus> s/how the attr() behaves/how the attr() behaves when used in a custom prop
17:35:06 <Rossen1> Rossen1 has joined #css
17:35:24 <noamr> astearns: PROPOSED RESOLUTION that we resolve the feature
17:35:33 <noamr> fantasai: proposal should be to adopt to the css-values-5
17:35:47 <noamr> PROPOSED RESOLUTION: work on this issue in css-values-5 draft
17:35:52 <fantasai> PROPOSED: Adopt ident() function into css-values-5
17:35:54 <noamr> astearns: objection?
17:35:59 <argyle> present+
17:35:59 <fantasai> RESOLVED: Adopt ident() function into css-values-5
17:36:07 <astearns> topic: administrivia
17:36:30 <astearns> https://wiki.csswg.org/planning/cupertino-2025
17:36:33 <fantasai> Register for the F2F! ^^^
17:36:48 <bramus> astearns: please update the wiki with your availability
17:36:56 <bramus> … dates have been confirmed
17:37:11 <bramus> … (for the f2F)
17:37:14 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10995
17:37:14 <github-bot> Topic: [css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID
17:37:14 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10995.
17:37:47 <bramus> noamr: we have a way to generate v-t-names with the keyword `auto`.
17:38:39 <bramus> … auto generates name based on the id attribute or element identity when two elements on both end of the VT are the same.
17:38:51 <bramus> … the id approach also works cross-document
17:39:15 <bramus> … 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
17:39:26 <JakeA> q+
17:39:44 <bramus> … in the breakout for VTs a few weeks ago elika proposed match-element which we like
17:39:58 <bramus> … are proposing to put that as a function for the purpose of feature detection
17:40:14 <bramus> … because right now `v-t-n: match-element` parses as supported
17:40:37 <bramus> … important to ship both things together. bigger groups of people who ship sites need a better layering.
17:40:42 <Rossen1> q?
17:40:53 <bramus> … auto has a better default behavior, but want to allow people to use a cleane rseparation if they so choose
17:41:12 <Rossen1> ack fantasai
17:41:12 <Zakim> fantasai, you wanted to comment on parsin and to comment on parsing
17:41:19 <bramus> fantasai: so the v-t-n accepts none an dcustom ident, which start with double dash
17:41:31 <bramus> … browsers should be rejecting any value that does not start with --
17:41:37 <bramus> … dont think we should introduce `()`
17:42:10 <bramus> bramus: dashed idents are subset of custom idents
17:42:15 <emilio> q+
17:42:16 <vmpstr> +1
17:42:19 <bramus> fantasai: oh, right. still dont like the parenthesis
17:42:24 <Rossen1> ack JakeA
17:42:33 <fantasai> fantasai: implies there's argument, but definitely there's none
17:42:37 <bramus> JakeA: I think we should unship/unspec `auto` as it exists now
17:42:52 <bramus> … aim of VTs was to have same behavior for same-doc and cross-doc
17:43:12 <bramus> … `match-element` is a useful departure from that but need to make it clear that the behavior only works in one of the two
17:43:31 <bramus> … `auto` muddies the water as it has `match-elemetn` but also `[id]` and creates this half-working feature but definitely different between MPA and SAP
17:43:44 <bramus> … I dont think that `auto` as “will do it all for you” here
17:44:15 <bramus> … might come up with other triggers like hover - should make sure definition of a transition is the same
17:44:29 <Rossen1> ack emilio
17:44:40 <bramus> emilio: strong agree with fantasai. no need for (). lot of other props with similar syntax restrict which idents they can parse
17:44:43 <JakeA> q+
17:44:51 <noamr> q+
17:44:51 <bramus> … am sure we can come up with an ident that is not a compat conceren
17:45:04 <Rossen1> ack fantasai
17:45:16 <bramus> fantasai: like to focus on noam’s ask of whether we add match element.
17:45:24 <bramus> … lets discuss meaning of auto later
17:45:27 <Rossen1> ack JakeA
17:45:41 <bramus> JakeA: i want to make sure that `match-element` is not as useful as people think it is
17:45:46 <bramus> … similar in codepen/tech demos
17:46:14 <bramus> … 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
17:46:26 <bramus> … element equality is not guaranteed
17:46:53 <Rossen1> ack noamr
17:47:01 <JakeA> That's an argument for not adding this behaviour into something like `auto`
17:47:07 <bramus> noamr: regarding compat: we could go back to CSS vt-1 and make it an illegal keyword
17:47:20 <JakeA> …because it's a complex behaviour and you need to know what you're opting into
17:47:23 <bramus> … think about compat is not about whether sites use it, its whether sites would catch it
17:47:24 <dbaron> For what it's worth, I think I have different opinions about element equality: https://dbaron.org/log/20200221-dom-identity
17:47:47 <JakeA> q+
17:47:50 <bramus> … to go back to vt-1 then say that its illegal, then new implementations can do that
17:47:58 <bramus> … instead of try and parsing it as a name
17:48:08 <bramus> … but right now in current implementations it does parse
17:48:11 <bramus> q+
17:48:17 <Rossen1> ack fantasai
17:48:35 <bramus> fantasai: there is a wide grey area in types of ?? and web apps between a demo page and sth that is using a particular framework style
17:48:43 <bramus> … we should be designing CSS to be usable and comfortable to it
17:48:53 <bramus> … I reject his argument that element identity is not useful at all
17:49:00 <Rossen1> ack JakeA
17:49:07 <bramus> JakeA: didnt say it wasnt usefull at all, but that it is less useful
17:49:09 <fantasai> s/at all/at all on real websites/
17:49:23 <bramus> … I covered other ground of simple page changes that fetch data and innerHTML it
17:49:24 <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
17:49:36 <bramus> … in all simple demos I created they use innerHTML
17:49:42 <bramus> … widely used pattern, outside of frameworks
17:49:55 <bramus> JakeA: I am worrried about kicking the auto discussion down the road
17:50:06 <bramus> … concerns were raised in october and safari shipped in december
17:50:18 <bramus> … not covering now could leave us stuck with it
17:50:36 <bramus> fantasai: given that chrome is not even shipping can indicatate that its a really useful feature
17:50:48 <astearns> -1 to the practice of allowing browsers to ship things and then see if compat issues come up
17:50:52 <bramus> … if we both shippped it and it was harmful then ???
17:51:13 <bramus> … fine to discuss, but dont think we need to resolve
17:51:15 <JakeA> q+
17:51:20 <fantasai> s/???/it would be urgent to remove/
17:51:27 <fantasai> s/resolve/resolve today necessarily/
17:51:37 <Rossen1> ack JakeA
17:51:39 <bramus> JakeA: agree with it just being safari then there is less of a riks
17:51:47 <bramus> … but dont like that being used as an excuse
17:52:18 <bramus> … 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
17:52:30 <astearns> q+
17:52:31 <bramus> … could block us from doing useful things in the future
17:52:35 <Rossen1> ack bramus
17:53:08 <noamr> bramus: re match-element being a function, it solves a short term, while in the long term a keyword would be best
17:53:24 <noamr> bramus: fine with match-element as a keyword, even without it being feature-detectable
17:53:25 <fantasai> +1 let's design for hte ong term
17:53:31 <fantasai> s/hte ong/the long/
17:53:32 <Rossen1> ack astearns
17:53:56 <bramus> 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
17:53:57 <noamr> astearns: at the very least I would appreciate it if the Safari folks would not talk about the auto value until we figure out if we want to support it long term
17:54:06 <bramus> … the less it gets evanglized the more options we have in the future
17:54:21 <bramus> Rossen1: ok, let’s see if we can wrap this up
17:54:49 <bramus> noamr: proposed resolution would be then to have match-element as keyword and thus to disallow it as a name in v-t-1
17:54:55 <JakeA> +1 to `match-element`
17:55:03 <bramus> Rossen1: Any additional feedback or objections?
17:55:12 <bramus> fantasai: overall sounds good
17:55:24 <bramus> … did we call the other names? `self` and `match-element`
17:55:38 <bramus> … tab commented we should have a keyword that also works equally well in `random()`
17:56:00 <bramus> Rossen1: which one of the two is currently being used int he issue or spec?
17:56:05 <bramus> fantasai: mostly `match-element` is used
17:56:13 <bramus> Rossen1: can we stick to that for now and bikshed later?
17:56:19 <vmpstr> +1 to `match-element`
17:56:25 <Rossen1> ack fantasai
17:56:25 <bramus> noamr: this is already result of a lot of bikshedding inthe issue and a breakout before
17:56:36 <bramus> … I suggested `self` but like `match-element` today
17:56:45 <bramus> Rossen1: OK
17:57:03 <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)
17:57:11 <bramus> RESOLVED: use the `match-element` keyword for this and disallow it as a value in vt1 spec
17:57:43 <github-bot> Topic: [css-inline-3] inline boxes and line-fit-edge vs text-box-trim/edge
17:58:06 <bramus> fantasai: Was making the edits for this and noticed we have an issue around
17:58:32 <bramus> … resolution wasnt 100% clear.
17:58:32 <bramus> … have two different line height sizing modes
17:58:55 <bramus> … depending on line fit
17:59:19 <bramus> … we resolveed to make t-b-trim affect inline boxes
17:59:19 <bramus> … and it definitely affects where the content edge is drawn
17:59:57 <noamr> fantasai: we have a transparency principle
18:00:07 <noamr> fantasai: an unstyled span around some text should not affect layout
18:00:08 <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>.
18:01:14 <noamr> Sorry, have to drop
18:01:15 <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).
18:03:09 <JakeA> Thank you all! Have a good break
18:03:17 <fantasai> present+
18:03:45 <Rossen1> Topic: end
18:03:50 <Rossen1> Zakim, end meeting
18:03:50 <Zakim> As of this point the attendees have been dbaron, JakeA, bramus, rachelandrew, kizu, joshtumath, noamr, jensimmons, ydaniv, masonf, Rossen, stepheckles, jfkthame, emilio, miriam,
18:03:53 <Zakim> ... ChrisL, vmpstr, oriol, chrishtr, dholbert, bkardell_, emeyer, argyle, fantasai
18:03:53 <Zakim> RRSAgent, please draft minutes v2
18:03:55 <RRSAgent> I have made the request to generate https://www.w3.org/2024/12/18-css-minutes.html Zakim
18:04:02 <Zakim> I am happy to have been of service, Rossen1; please remember to excuse RRSAgent.  Goodbye
18:04:02 <emeyer> emeyer has left #css
18:04:02 <Zakim> Zakim has left #css
18:04:18 <cptaffe> cptaffe has joined #css
18:06:25 <jamesn> jamesn has joined #css