– DRAFT –
Joint meeting with Open UI/WhatWG/CSSWG Taskforce

github-bot, take up w3c/csswg-drafts#10380

[css-ui] DOM/Box structure for appearance:base-select

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10380.

chrishtr: we can mark as needs edit and once that's done that'd get review and get closed

annevk: sounds good

<dbaron> (above was about the previous item on the agenda)

jarhar: That's a proposal for base-select behavior and DOM structure
… higher level questions would be whether it'd be ok to use shadow dom for this
… the other thing would be that in chromium elements inside the shadow root for the base and auto appearance
… and switch based on the computed value
… wonder if that's acceptable

annevk: I think shadow roots are fine for this, we have the precedent of <details>

<fantasai> +1 to avoiding a true dependency on the shadow DOM

annevk: in theory an implementation could not use shadow root

jarhar: that sounds promising
… it sounds like we can define this as a shadow root

masonf: are we doing resolutions?

<fantasai> PROPOSED: <select> internals can be represented with shadow DOM

<masonf> +1

<dandclark> +1

<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

<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

emilio: sounds good

<gregwhitworth> chrishtr: they need to end up with the same interoperable result

chrishtr: it's not observable that there's a shadow root right?

<masonf> shady-dom

jarhar: I think that's correct

chrishtr: we can put a non-normative note in the spec about it being possibly implemented with other technology

<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)

gregwhitworth: so fine to go with Elika's resolution

*?

<masonf> +1

<keithamus> +1

RESOLUTION: <select> internals can be represented with shadow DOM (but shadow DOM support is not required as long as the behavior is the same)

jarhar: I want to also go through the slots and so on

gregwhitworth: Should we resolve that in this issue or move that to a different one?

annevk: the one concern from our side is about the `multiple` attribute
… without that we can agree to this
… but with `multiple` one of the slots ends up not being there or rendered

jarhar: we can change the shadow DOM for the `multiple` attribute

jarhar: so that there's a shadow DOM but can be completely different

fantasai: currently in html we combine two things, if you can select one it's a popup and otherwise it's an embedded control
… I think we can split that into multiple axes

<masonf> that's the multiple and size attributes, respectively.

<annevk> (modulo iOS where it's a little different from that even)

<lwarlow> (and android)

fantasai: 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

chrishtr: all those things can be figured out but can we leave those not defined yet?
… and define just the non-multiple case for now?

fantasai: I think we might need to come back and change things once we tackle the others

chrishtr: we can take an action item to dig into that to make sure that changes might not be needed

masonf: there's `multiple` and `size` which theoretically create those two axes
… behavior is a bit different in mobile vs. not, I think there are a lot of issues with `multiple` without that
… so I think we need feature detection but I'd like not to block on that

fantasai: I think that'd be surprising, I'd like multiple to be defined for styleable select
… I think you can't just ignore the semantics of `multiple`

masonf: I was thinking of just forcing `auto` rather than ignoring `multiple`

fantasai: I think I worry about site issues once we start making changes there, I think it's solvable and we should fix it

chrishtr: agree on solvable, I don't think it blocks resolving on jarhar's proposal for the single case

fantasai: I think the structure makes sense except the svg
… because it doesn't respect writing-mode
… in respect on the names of pseudos we want to be consistent with other stuff we expect to do elsewhere

<chrishtr> proposed: "accept shadow dom structure as proposed initial comment in the issue, except for svg part"

fantasai: but over-all structure makes sense otherwise

<fantasai> s/to do elsewhere, so probably should discuss separately/

jarhar: for pseudo names I agree they're not great

<chrishtr> "pseudo element names to be decided later"

jarhar: there's another issue for that
… as for the SVG I agree, there's a similar discussion for checkmarks
… we moved to a unicode character
… there's a down arrow thing
… do you think using it would be reasonable

fantasai: if you use the disclosure-open counter style then it takes care of those issues

chrishtr: suggestion is to make some forward progress on this. We can discuss checkmarks / svg / names later

gregwhitworth: I agree, follow-up issues for glyph and pseudo-elements makes sense

<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"

fantasai: should probably be one issue for the pseudos and such, we should decide them together

<jarhar> i already created an issue for pseudo elements here: w3c/csswg-drafts#10462

<masonf> +1

<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"

fantasai: inside the button one of the elements is a `<span>` and another a `<div>`, why?

RESOLUTION: 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

<gregwhitworth> github-bot, take up whatwg/html#9144

<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.

jarhar: good question, maybe I was relying on block vs inline layout, but I might be overriding display anyways

Add anchor attribute #9144

masonf: it's related to anchor pos and popover more than select
… proposal is to add an `anchor` attribute which does a few thing
… one is that it adds an element as implicit anchor

<dbaron> github: whatwg/html#9144

masonf: 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
… the other one is about accessibility, and is that it'd be good to have an html link to control focus fixup and accessibility
… there's been some pushback

fantasai: first q is why can't popover not create an implicit anchor relationship?

masonf: how would it be automatic?

fantasai: doesn't it know the relationship between the button and the popover?

masonf: if you use invokers for it then yes
… but if there's no button in the first popover or you open it via JS then that would be the attribute

annevk: those use cases wouldn't be using the declarative markup correctly right? Shouldn't this be an API feature?

masonf: like, connecting the elements on the JS call, via an argument? That's already a proposal
… 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?

<fantasai> whatwg/html#9144 (comment)

lwarlow: is there a use case for non-popover anchored things? If so then that wouldn't work right?
… worth keeping in mind

fantasai: for things that are not popovers we need to do something
… 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)
… so html needs an anchoring markup but it's not going to be only about anchor positioning in the CSS
… if we add something to HTML we need to make it about the semantics
… as proposed right now it's just presentational
… this proposal doesn't go far enough to provide what HTML actually needs in terms of anchoring semantics

masonf: what would you propose to be added
… a multi-valued anchor or somesuch?

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
… the other thing is does this have an appropriate description that we can point authors to?

masonf: I think a few things belong to aam and so but others would belong to html

gregwhitworth: would the explicit JS API allow to solve some of these use cases?

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
… would be interesting to resolve to look into that direction

fantasai: I'd say to add an markup to represent anchoring relationships (i.e. not specific to anchor positioning)

<tantek> +1 fantasai markup for indicating anchoring relationships

annevk: do we know what the a11y mapping would be or so?
… seems too vague

chrishtr: the idea is to agree something is needed

annevk: the way I interpreted fantasai is "this what I'd expect of a semantic attribute", not exactly what that might look like

fantasai: I agree, but "something is needed" is true

<gregwhitworth> emilio: if we resolve on the invoker stuff to setup the anchor relationship then doesn't that mean

<fantasai> s/go further and//

<gregwhitworth> emilio: don't we want that to work with non-popovers and we can explore that

<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

<gregwhitworth> emilio: the other thing is whether we do an explicit JS API or some other thing?

<gregwhitworth> masonf: yes, invoker relationships creates one of those and some attribute or set of attributes will create an implicit anchor relationship

<gregwhitworth> emilio: that's a bit confusing to me

<gregwhitworth> masonf: there is also the invoker/command attribute that will do this for other things

<gregwhitworth> chrishtr: if we could find a way for one thing to do both; then the better

annevk: by invoker you mean popovertarget?

masonf: I mean command/commandfor

annevk: but we should do it for popovertarget too right?

masonf: yeah

<masonf> Proposed: popovertarget creates an implicit anchor element reference.

<lwarlow> +1

sgtm

<keithamus> +1

RESOLUTION: popovertarget creates an implicit anchor element reference

<fantasai> PROPOSED: Develop HTML markup to represent semantic anchoring relationships (and which also set the implicit anchor element) to address non-popover use cases

<tantek> +1

<lwarlow> +2

<masonf> +3

<keithamus> +4

<tantek> +1 emilio, including non-popover use-cases

<gregwhitworth> PROPOSED: Develop HTML markup to represent semantic anchoring relationships (and which also set the implicit anchor element) for non-popover use cases.

<tantek> +1

<masonf> thank you

<keithamus> +1

fantasai: I'd expect popover to work automatically as much as possible

masonf: I think the point is that even if it's a popover it'd work

annevk: I think we're too early in the process, doesn't really matter at this point

lwarlow: should we resolve on the imperative showPopover?

RESOLUTION: Develop HTML markup to represent semantic anchoring relationships (and which also set the implicit anchor element) for non-popover use cases.

chrishtr: we should check on the API

chrishtr: does anyone have concerns about the imperative API to establish that link?

lwarlow: I think it'd be necessary to solve the web components use case where you can't use the declarative API

<masonf> Proposed: it would be a good idea to add an imperative way to set invoker relationships between popovers.

<lwarlow> +1

<keithamus> +1

sg

RESOLUTION: it would be a good idea to add an imperative way to set invoker relationships between popovers.

<gregwhitworth> github-bot, take up w3c/csswg-drafts#10028

[css-ui] Changing UA styles based on the computed value of the appearance property

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10028.

jarhar: for appearance: base one of the things is that chrome and webkit have different border property and we want to make this interoperable
… for html-based solution this was not a proble

problem*
… so I thought it'd be not possible to solve, but lilles suggested something like light-dark
… that took multiple values, one for auto/none and one for base
… I implemented it for border and so on
… not sure if you need details

<chrishtr> +1

emilio: This is fine, but I'm sad that we can't get interoperable UA stylesheets

<gregwhitworth> emilio: this seems fine, it makes me sad that we can't get interoperable UA stylesheets

emilio: The fact that now we cannot use regular CSS to represent the HTML styles is a bit unfortunate

<gregwhitworth> emilio: now we can not use regular CSS to represent the HTML styles is unfortunate

<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

<gregwhitworth> emilio: it makes me a bit sad that it would spec fiction but maybe it's fine

<tantek> +1 emilio, it is surprising that appearance:none is not interoperable across engines

<gregwhitworth> emilio: I think we should look into interoperable UA stylesheet. Appearance: none is not interoperable at this point

masonf: first I think this doesn't mean that we shouldn't work on making appearance: none interoperable, but decouples it
… so that we don't have to worry about that for now

<chrishtr> PROPOSED: user agent styles can depend on appearance:base

masonf: the other thing is that maybe there should be an author-visible way to do this

jarhar: I agree we can work on make appearance: none more interop, but decoupling them is easier
… re author visibility, I had to implement it for each prop, so I'm reluctant to do that

<gregwhitworth> emilio: can we resolve on the issue with the goal of making things interoperable and this function would go away

<gregwhitworth> emilio: once we make appearance: none consistent this would go away

<chrishtr> PROPOSED: user agent styles can depend on appearance:base. Aim for eventual interoperability across all values of the property.

<tantek> +1 emilio

<gregwhitworth> jarhar: sounds good to me

<masonf> +1

<dandclark> +1

+1

<tantek> 0

RESOLUTION: user agent styles can depend on appearance:base. Aim for eventual interoperability across all values of the property.