01:20:33 <projecto-> projecto- has joined #css
01:21:03 <leaverou_> leaverou_ has joined #css
01:22:04 <Rossen-> Rossen- has joined #css
01:22:34 <shans_> shans_ has joined #css
01:23:06 <sylvaing_> sylvaing_ has joined #css
14:58:39 <RRSAgent> RRSAgent has joined #css
14:58:39 <RRSAgent> logging to https://www.w3.org/2024/06/27-css-irc
14:58:45 <gregwhitworth> Zakim, start meeting
14:58:45 <Zakim> RRSAgent, make logs Public
14:58:47 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
14:59:25 <gregwhitworth> gregwhitworth has changed the topic to: Agenda for June 27 Joint OpenUI/WhatWG/CSS TF: https://github.com/whatwg/html/issues/10401#issuecomment-2187251320
14:59:26 <gregwhitworth> chair: Greg Whitworth
14:59:45 <gregwhitworth> meeting: Joint meeting with Open UI/WhatWG/CSSWG Taskforce
15:01:01 <jarhar> jarhar has joined #css
15:01:51 <akeerthi> akeerthi has joined #css
15:02:24 <masonf> masonf has joined #css
15:02:31 <gregwhitworth> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10380
15:02:31 <github-bot> Topic: [css-ui] DOM/Box structure for appearance:base-select
15:02:31 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10380.
15:02:41 <annevk> annevk has joined #css
15:03:00 <sanketj_> sanketj_ has joined #css
15:04:29 <masonf> present+
15:04:34 <sanketj_> present+
15:04:38 <emilio> scribenick: emilio
15:04:40 <dbaron> Present+
15:05:01 <emilio> chrishtr: we can mark as needs edit and once that's done that'd get review and get closed
15:05:14 <emilio> annevk: sounds good
15:05:14 <akeerthi> present+
15:05:27 <dbaron> (above was about the previous item on the agenda)
15:05:47 <chrishtr> present+
15:06:04 <emilio> jarhar: That's a proposal for base-select behavior and DOM structure
15:06:14 <emilio> ... higher level questions would be whether it'd be ok to use shadow dom for this
15:06:53 <emilio> ... the other thing would be that in chromium elements inside the shadow root for the base and auto appearance
15:06:56 <bkardell_> present+
15:06:58 <gregwhitworth> q?
15:07:03 <emilio> ... and switch based on the computed value
15:07:17 <emilio> ... wonder if that's acceptable
15:07:30 <emilio> annevk: I think shadow roots are fine for this, we have the precedent of <details>
15:07:37 <fantasai> +1 to avoiding a true dependency on the shadow DOM
15:07:38 <emilio> ... in theory an implementation could not use shadow root
15:07:43 <emilio> q+
15:07:53 <emilio> jarhar: that sounds promising
15:08:07 <emilio> ... it sounds like we can define this as a shadow root
15:08:20 <emilio> masonf: are we doing resolutions?
15:08:21 <fantasai> PROPOSED: <select> internals can be represented with shadow DOM
15:08:34 <masonf> +1
15:08:38 <dandclark> +1
15:08:50 <annevk> annevk has joined #css
15:08:55 <keithamus> present+
15:09:05 <gregwhitworth> emilio: I wanted to clarify fantasai point, I think she's fine defining in terms of shadow DOM but in theory you can implement it with something else
15:09:36 <gregwhitworth> fantasai: yeah, that's exactly right we should define it using shadow but it's ok if the implementation does not use shadow DOM
15:09:47 <emilio> emilio: sounds good
15:09:54 <gregwhitworth> chrishtr: they need to end up with the same interoperable result
15:10:03 <emilio> chrishtr: it's not observable that there's a shadow root right?
15:10:05 <masonf> shady-dom
15:10:16 <emilio> jarhar: I think that's correct
15:10:50 <emilio> chrishtr: we can put a non-normative note in the spec about it being possibly implemented with other technology
15:10:58 <castastrophe> castastrophe has joined #css
15:11:02 <smaug> present+
15:11:20 <fantasai> PROPOSED: <select> internals can be represented with shadow DOM (but shadow DOM support is not required as long as the behavior is the same)
15:11:25 <emilio> gregwhitworth: so fine to go with Elika's resolution
15:11:27 <emilio> *?
15:11:29 <masonf> +1
15:11:40 <keithamus> +1
15:11:57 <emilio> RESOLVED: <select> internals can be represented with shadow DOM (but shadow DOM support is not required as long as the behavior is the same)
15:12:39 <emilio> jarhar: I want to also go through the slots and so on
15:13:07 <emilio> gregwhitworth: Should we resolve that in this issue or move that to a different one?
15:13:22 <emilio> annevk: the one concern from our side is about the `multiple` attribute
15:13:29 <emilio> ... without that we can agree to this
15:13:46 <emilio> ... but with `multiple` one of the slots ends up not being there or rendered
15:14:03 <emilio> jarhar: we can change the shadow DOM for the `multiple` attribute
15:14:05 <emilio> ack emilio
15:14:15 <gregwhitworth> ack fantasai
15:14:23 <emilio> jarhar: so that there's a shadow DOM but can be completely different
15:14:28 <chrishtr> q+
15:14:53 <emilio> fantasai: currently in html we combine two things, if you can select one it's a popup and otherwise it's an embedded control
15:14:53 <gregwhitworth> q+
15:14:56 <masonf> q+
15:15:07 <emilio> ... I think we can split that into multiple axes
15:15:10 <masonf> that's the multiple and size attributes, respectively.
15:15:19 <annevk> (modulo iOS where it's a little different from that even)
15:15:28 <gregwhitworth> ack chrishtr
15:15:33 <jarhar> q?
15:15:36 <lwarlow> (and android)
15:15:37 <emilio> ... so that we can make a popup where you can select multiple attributes, and you can have an embedded thing where you can select just one
15:15:49 <emilio> chrishtr: all those things can be figured out but can we leave those not defined yet?
15:15:57 <emilio> ... and define just the non-multiple case for now?
15:16:07 <tantek> tantek has joined #css
15:16:13 <tantek> present+
15:16:24 <emilio> fantasai: I think we might need to come back and change things once we tackle the others
15:16:27 <gregwhitworth> ack gregwhitworth
15:16:43 <gregwhitworth> ack masonf
15:16:45 <emilio> chrishtr: we can take an action item to dig into that to make sure that changes might not be needed
15:17:02 <emilio> masonf: there's `multiple` and `size` which theoretically create those two axes
15:17:51 <emilio> ... behavior is a bit different in mobile vs. not, I think there are a lot of issues with `multiple` without that
15:18:01 <gregwhitworth> q+
15:18:05 <emilio> ... so I think we need feature detection but I'd like not to block on that
15:18:07 <lwarlow> q+
15:18:31 <emilio> fantasai: I think that'd be surprising, I'd like multiple to be defined for styleable select
15:18:50 <emilio> ... I think you can't just ignore the semantics of `multiple`
15:18:58 <gregwhitworth> ack gregwhitworth
15:19:04 <emilio> masonf: I was thinking of just forcing `auto` rather than ignoring `multiple`
15:19:12 <lwarlow> q-
15:19:30 <emilio> fantasai: I think I worry about site issues once we start making changes there, I think it's solvable and we should fix it
15:19:53 <emilio> chrishtr: agree on solvable, I don't think it blocks resolving on jarhar's proposal for the single case
15:20:04 <emilio> fantasai: I think the structure makes sense except the svg
15:20:11 <emilio> ... because it doesn't respect writing-mode
15:20:31 <emilio> ... in respect on the names of pseudos we want to be consistent with other stuff we expect to do elsewhere
15:20:34 <jarhar> q?
15:20:34 <chrishtr> proposed: "accept shadow dom structure as proposed initial comment in the issue, except for svg part"
15:20:45 <emilio> ... but over-all structure makes sense otherwise
15:20:47 <fantasai> s/to do elsewhere, so probably should discuss separately/
15:20:51 <emilio> jarhar: for pseudo names I agree they're not great
15:20:55 <chrishtr> "pseudo element names to be decided later"
15:20:57 <emilio> ... there's another issue for that
15:21:12 <emilio> ... as for the SVG I agree, there's a similar discussion for checkmarks
15:21:18 <emilio> ... we moved to a unicode character
15:21:31 <emilio> ... there's a down arrow thing
15:21:44 <chrishtr> q+
15:21:51 <emilio> ... do you think using it would be reasonable
15:22:00 <emilio> fantasai: if you use disclosure-open then it takes care of those issues
15:22:02 <gregwhitworth> ack chrishtr
15:22:20 <dbaron> s/disclosure-open/the disclosure-open counter style/
15:22:24 <emilio> chrishtr: suggestion is to make some forward progress on this. We can discuss checkmarks / svg / names later
15:22:45 <emilio> gregwhitworth: I agree, follow-up issues for glyph and pseudo-elements makes sense
15:23:08 <chrishtr> "accept shadow dom structure as proposed initial comment in the issue, except for svg part and naming of pseudo elements. issues to be opened for those"
15:23:35 <emilio> fantasai: should probably be one issue for the pseudos and such, we should decide them together
15:23:37 <jarhar> i already created an issue for pseudo elements here: https://github.com/w3c/csswg-drafts/issues/10462
15:23:42 <masonf> +1
15:24:19 <gregwhitworth> q?
15:24:20 <chrishtr> "accept shadow dom structure as proposed in the initial comment in the issue, except for svg part and naming of pseudo elements. issues to be opened for those"
15:24:32 <emilio> fantasai: inside the button one of the elements is a `<span>` and another a `<div>`, why?
15:25:00 <gregwhitworth> RESOLVED: Accept shadow dom structure as proposed initial comment in the issue, except for the svg part and naming of pseudo elements. issues to be opened for those
15:25:31 <gregwhitworth> github-bot, take up https://github.com/whatwg/html/pull/9144
15:25:31 <github-bot> gregwhitworth, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts w3c/svgwg web-platform-tests/wpt WICG/animation-worklet WICG/construct-stylesheets WICG/scroll-animations WICG/custom-state-pseudo-class.
15:25:38 <emilio> jarhar: good question, maybe I was relying on block vs inline layout, but I might be overriding display anyways
15:25:49 <gregwhitworth> Topic: Add anchor attribute #9144
15:26:16 <emilio> masonf: it's related to anchor pos and popover more than select
15:26:25 <emilio> ... proposal is to add an `anchor` attribute which does a few thing
15:26:39 <emilio> ... one is that it adds an element as implicit anchor
15:27:07 <dbaron> github: https://github.com/whatwg/html/pull/9144
15:27:09 <emilio> ... when you're doing that with popovers is also affect the nesting rules so that when you anchor a popover to another popover the outer doesn't close
15:27:35 <emilio> ... the other one is about accessibility, and is that it'd be good to have an html link to control focus fixup and accessibility
15:27:40 <gregwhitworth> q?
15:27:40 <emilio> ... there's been some pushback
15:27:57 <emilio> ack fantasai
15:27:58 <gregwhitworth> ack fantasai
15:28:11 <emilio> fantasai: first q is why can't popover not create an implicit anchor relationship?
15:28:27 <emilio> masonf: how would it be automatic?
15:28:33 <lwarlow> q+
15:28:44 <emilio> fantasai: doesn't it know the relationship between the button and the popover?
15:28:53 <emilio> masonf: if you use invokers for it then yes
15:29:32 <emilio> ... but if there's no button in the first popover or you open it via JS then that would be the attribute
15:30:11 <emilio> annevk: those use cases wouldn't be using the declarative markup correctly right? Shouldn't this be an API feature?
15:30:32 <emilio> masonf: like, connecting the elements on the JS call, via an argument? That's already a proposal
15:31:16 <gregwhitworth> ack lwarlow
15:31:19 <emilio> ... if the proposal is to make the declarative popovertarget connection and also a new setting in the JS API to make this connection then that might meet the usecase?
15:31:53 <masonf> q+
15:31:59 <gregwhitworth> ack fantasai
15:32:02 <fantasai> https://github.com/whatwg/html/pull/9144#issuecomment-2189481315
15:32:02 <emilio> lwarlow: is there a use case for non-popover anchored things? If so then that wouldn't work right?
15:32:06 <emilio> ... worth keeping in mind
15:32:18 <emilio> fantasai: for things that are not popovers we need to do something
15:33:41 <emilio> ... but there are three use cases for anchored: semantic+presentationally anchored, presentation-only (like the 'new' example I linked above), and semantic only (like a footnote that pops up at the bottom of the screen, it's not visually anchored to its anchor)
15:34:01 <masonf> q-
15:34:03 <emilio> ... so html needs an anchoring markup but it's not going to make anchor positioning in the CSS
15:34:18 <emilio> ... if we add something to HTML we need to make it about the semantics
15:34:29 <emilio> ... as proposed right now it's just presentational
15:34:34 <tantek> tantek has joined #css
15:34:44 <masonf> q+
15:34:48 <emilio> ... this proposal doesn't go far enough to provide what HTML actually needs in terms of anchoring semantics
15:34:49 <gregwhitworth> ack masonf
15:34:53 <gregwhitworth> q+
15:34:58 <fantasai> s/not going to make/not going to be only about/
15:35:05 <emilio> masonf: what would you propose to be added
15:35:16 <emilio> ... a multi-valued anchor or somesuch?
15:36:11 <emilio> fantasai: there's a11y and aria bindings, there's focus and tabbing order (there are use cases for before and after), and the other one is whether it's easy enough that they'll reach for that and not just use CSS to get the right position
15:36:40 <emilio> ... the other thing is does this have an appropriate description that we can point authors to?
15:37:09 <emilio> masonf: I think a few things belong to aam and so but others would belong to html
15:37:49 <emilio> gregwhitworth: would the explicit JS API allow to solve some of these use cases?
15:37:54 <gregwhitworth> ack gregwhitworth
15:38:41 <emilio> masonf: there are a few things... would allow an explicit invoker relationship, but we should also connect that to anchor positioning as an implicit anchor
15:38:55 <emilio> ... would be interesting to resolve to look into that direction
15:38:59 <emilio> ack fantasai
15:38:59 <gregwhitworth> ack fantasai
15:39:32 <emilio> fantasai: I'd go further and say to add an attribute (or multiple) to represent html anchoring
15:39:43 <emilio> q+
15:39:53 <fantasai> s/attribute (or multiple)/markup/
15:39:55 <tantek> +1 fantasai markup for indicating anchoring relationships
15:40:08 <fantasai> s/html anchoring/anchoring relationships (i.e. not specific to anchor positioning)/
15:40:15 <emilio> annevk: do we know what the a11y mapping would be or so?
15:40:23 <emilio> ... seems too vague
15:40:30 <emilio> chrishtr: the idea is to agree something is needed
15:41:10 <emilio> annevk: the way I interpreted fantasai is "this what I'd expect of a semantic attribute", not exactly what that might look like
15:41:18 <emilio> fantasai: I agree, but "something is needed" is true
15:41:50 <fantasai> s/go further and/
15:41:50 <gregwhitworth> emilio: if we resolve on the invoker stuff to setup the anchor relationship then doesn't that mean
15:41:52 <fantasai> s/go further and//
15:42:01 <gregwhitworth> emilio: don't we want that to work with non-popovers and we can explore that
15:42:12 <tantek> FYI, per fantasai's list of use-cases for anchoring / anchoring relationships / anchoring presentation and combinations thereof, here is an example of semantic anchoring without presentational anchoring, the footnote link (and backlink) here: https://tantek.com/2024/131/t1/mozilla-origin-trials
15:42:14 <gregwhitworth> emilio: the other thing is whether we do an explicit JS API or some other thing?
15:42:39 <gregwhitworth> masonf: yes, invoker relationships creates one of those and some attribute or set of attributes will create an implicit anchor relationship
15:42:47 <gregwhitworth> emilio: that's a bit confusing to me
15:43:01 <gregwhitworth> masonf: there is also the invoker/command attribute that will do this for other things
15:43:14 <gregwhitworth> chrishtr: if we could find a way for one thing to do both; then the better
15:43:31 <emilio> annevk: by invoker you mean popovertarget?
15:43:39 <emilio> masonf: I mean command/commandfor
15:43:50 <emilio> annevk: but we should do it for popovertarget too right?
15:43:55 <emilio> masonf: yeah
15:44:09 <emilio> ack emilio
15:44:26 <masonf> Proposed: popovertarget creates an implicit anchor element reference.
15:44:37 <lwarlow> +1
15:44:49 <emilio> sgtm
15:44:52 <keithamus> +1
15:44:56 <emilio> RESOLVED: popovertarget creates an implicit anchor element reference
15:45:10 <fantasai> PROPOSED: Develop HTML markup to represent semantic anchoring relationships (and which also set the implicit anchor element).
15:45:18 <tantek> +1
15:45:27 <lwarlow> +2
15:45:32 <masonf> +3
15:45:37 <keithamus> +4
15:45:56 <tantek> +1 emilio, including non-popover use-cases
15:45:56 <fantasai> s/element)./element) to address non-popover use cases/
15:46:32 <gregwhitworth> PROPOSED: Develop HTML markup to represent semantic anchoring relationships (and which also set the implicit anchor element) for popover or non-popover use cases.
15:46:38 <tantek> +1
15:46:40 <masonf> thank you
15:46:42 <keithamus> +1
15:46:55 <lwarlow> q+
15:47:10 <emilio> fantasai: I'd expect popover to work automatically as much as possible
15:47:31 <emilio> masonf: I think the point is that even if it's a popover it'd work
15:47:44 <emilio> annevk: I think we're too early in the process, doesn't really matter at this point
15:47:50 <gregwhitworth> ack lwarlow
15:47:58 <emilio> lwarlow: should we resolve the imperative showPopover?
15:48:06 <emilio> s/the/on the/
15:48:08 <gregwhitworth> RESOLVED: Develop HTML markup to represent semantic anchoring relationships (and which also set the implicit anchor element) for popover or non-popover use cases.
15:48:40 <emilio> chrishtr: we should check on the API
15:49:14 <emilio> chrishtr: does anyone have concerns about the imperative API to establish that link?
15:50:06 <emilio> lwarlow: I think it'd be necessary to solve the web components use case where you can't use the declarative API
15:50:28 <masonf> Proposed: it would be a good idea to add an imperative way to set invoker relationships between popovers.
15:50:43 <lwarlow> +1
15:50:45 <keithamus> +1
15:50:51 <emilio> sg
15:50:54 <emilio> RESOLVED: it would be a good idea to add an imperative way to set invoker relationships between popovers.
15:51:38 <gregwhitworth> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10028
15:51:38 <github-bot> Topic: [css-ui] Changing UA styles based on the computed value of the appearance property
15:51:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10028.
15:52:13 <emilio> jarhar: for appearance: base one of the things is that chrome and webkit have different border property and we want to make this interoperable
15:52:23 <emilio> ... for html-based solution this was not a proble
15:52:32 <emilio> problem*
15:52:57 <fantasai> s/popover or/
15:53:00 <fantasai> s/popover or//
15:53:02 <emilio> ... so I thought it'd be not possible to solve, but lilles suggested something like light-dark
15:53:20 <emilio> ... that took multiple values, one for auto/none and one for base
15:53:34 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/27-css-minutes.html fantasai
15:53:41 <emilio> ... I implemented it for border and so on
15:53:45 <emilio> ... not sure if you need details
15:53:52 <emilio> q+
15:53:53 <chrishtr> +1
15:53:57 <gregwhitworth> ack emilio
15:54:14 <fantasai> scribe+
15:54:22 <fantasai> emilio: This is fine, but I'm sad that we can't get interoperable UA stylesheets
15:54:25 <tantek> present+ gregwhitworth
15:54:28 <gregwhitworth> emilio: this seems fine, it makes me sad that we can't get interoperable UA stylesheets
15:54:29 <masonf> q+
15:54:38 <tantek> present+ emilio
15:54:41 <fantasai> emilio: The fact that now we cannot use regular CSS to represent the HTML styles is a bit unfortunate
15:54:43 <gregwhitworth> emilio: now we can not use regular CSS to represent the HTML styles is unfortunate
15:55:04 <gregwhitworth> emilio: either we define this entirely and we can use this from HTML then we have to say "if appearance is base" you need to do this
15:55:13 <jarhar> q?
15:55:16 <gregwhitworth> emilio: it makes me a bit sad that it would spec fiction but maybe it's fine
15:55:36 <tantek> +1 emilio, it is surprising that appearance:none is not interoperable across engines
15:55:44 <gregwhitworth> emilio: I think we should look into interoperable UA stylesheet. Appearance: none is not interoperable at this point
15:55:51 <gregwhitworth> ack masonf
15:56:05 <tantek> present+ fantasai
15:56:16 <emilio> masonf: first I think this doesn't mean that we shouldn't work on making appearance: none interoperable, but decouples it
15:56:23 <emilio> ... so that we don't have to worry about that for now
15:56:36 <tantek> present+ jarhar
15:56:41 <chrishtr> PROPOSED: user agent styles can depend on appearance:base
15:56:41 <jarhar> q+
15:56:48 <emilio> ... the other thing is that maybe there should be an author-visible way to do this
15:56:48 <gregwhitworth> ack jarhar
15:57:14 <emilio> jarhar: I agree we can work on make appearance: none more interop, but decoupling them is easier
15:57:34 <fantasai> i/Topic: [css-ui] DOM/scribe+ gregwhitworth/
15:57:39 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/27-css-minutes.html fantasai
15:57:45 <tantek> present+ annevk
15:57:45 <emilio> ... re author visibility, I had to implement it for each prop, so I'm reluctant to do that
15:57:49 <emilio> q+
15:57:49 <masonf> q+
15:57:58 <gregwhitworth> ack emilio
15:58:02 <gregwhitworth> zakim, close queue
15:58:02 <Zakim> ok, gregwhitworth, the speaker queue is closed
15:58:21 <gregwhitworth> emilio: can we resolve on the issue with the goal of making things interoperable and this function would go away
15:58:32 <gregwhitworth> emilio: once we make appearance: none consistent this would go away
15:58:36 <chrishtr> PROPOSED: user agent styles can depend on appearance:base. Aim for eventual interoperability across all values of the property.
15:58:37 <tantek> +1 emilio
15:58:38 <gregwhitworth> jarhar: sounds good to me
15:58:40 <gregwhitworth> ack masonf
15:59:04 <masonf> +1
15:59:05 <dandclark> +1
15:59:09 <emilio> +1
15:59:15 <tantek> 0
15:59:22 <emilio> RESOLVED: user agent styles can depend on appearance:base. Aim for eventual interoperability across all values of the property.
16:00:08 <gregwhitworth> Zakim, end meeting
16:00:08 <Zakim> As of this point the attendees have been masonf, sanketj_, dbaron, akeerthi, chrishtr, bkardell_, keithamus, smaug, tantek, gregwhitworth, emilio, fantasai, jarhar, annevk
16:00:19 <Zakim> RRSAgent, please draft minutes v2
16:00:20 <RRSAgent> I have made the request to generate https://www.w3.org/2024/06/27-css-minutes.html Zakim
16:00:26 <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent.  Goodbye
16:00:26 <Zakim> Zakim has left #css
17:14:18 <Francis_Storr> Francis_Storr has joined #css
17:36:49 <Linux_Kerio> Linux_Kerio has joined #css
18:11:26 <Penny> Penny has joined #css
19:22:29 <Penny> Penny has joined #css
19:55:20 <Penny> Penny has joined #css