- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Jun 2024 15:25:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui] DOM/Box structure for appearance:base-select`, and agreed to the following: * `RESOLVED: <select> internals can be represented with shadow DOM (but shadow DOM support is not required as long as the behavior is the same)` * `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` <details><summary>The full IRC log of that discussion</summary> <emilio> scribenick: emilio<br> <emilio> chrishtr: we can mark as needs edit and once that's done that'd get review and get closed<br> <emilio> annevk: sounds good<br> <dbaron> (above was about the previous item on the agenda)<br> <emilio> jarhar: That's a proposal for base-select behavior and DOM structure<br> <emilio> ... higher level questions would be whether it'd be ok to use shadow dom for this<br> <emilio> ... the other thing would be that in chromium elements inside the shadow root for the base and auto appearance<br> <gregwhitworth> q?<br> <emilio> ... and switch based on the computed value<br> <emilio> ... wonder if that's acceptable<br> <emilio> annevk: I think shadow roots are fine for this, we have the precedent of <details><br> <fantasai> +1 to avoiding a true dependency on the shadow DOM<br> <emilio> ... in theory an implementation could not use shadow root<br> <emilio> q+<br> <emilio> jarhar: that sounds promising<br> <emilio> ... it sounds like we can define this as a shadow root<br> <emilio> masonf: are we doing resolutions?<br> <fantasai> PROPOSED: <select> internals can be represented with shadow DOM<br> <masonf> +1<br> <dandclark> +1<br> <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<br> <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<br> <emilio> emilio: sounds good<br> <gregwhitworth> chrishtr: they need to end up with the same interoperable result<br> <emilio> chrishtr: it's not observable that there's a shadow root right?<br> <masonf> shady-dom<br> <emilio> jarhar: I think that's correct<br> <emilio> chrishtr: we can put a non-normative note in the spec about it being possibly implemented with other technology<br> <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)<br> <emilio> gregwhitworth: so fine to go with Elika's resolution<br> <emilio> *?<br> <masonf> +1<br> <keithamus> +1<br> <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)<br> <emilio> jarhar: I want to also go through the slots and so on<br> <emilio> gregwhitworth: Should we resolve that in this issue or move that to a different one?<br> <emilio> annevk: the one concern from our side is about the `multiple` attribute<br> <emilio> ... without that we can agree to this<br> <emilio> ... but with `multiple` one of the slots ends up not being there or rendered<br> <emilio> jarhar: we can change the shadow DOM for the `multiple` attribute<br> <emilio> ack emilio<br> <gregwhitworth> ack fantasai<br> <emilio> jarhar: so that there's a shadow DOM but can be completely different<br> <chrishtr> q+<br> <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<br> <gregwhitworth> q+<br> <masonf> q+<br> <emilio> ... I think we can split that into multiple axes<br> <masonf> that's the multiple and size attributes, respectively.<br> <annevk> (modulo iOS where it's a little different from that even)<br> <gregwhitworth> ack chrishtr<br> <jarhar> q?<br> <lwarlow> (and android)<br> <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<br> <emilio> chrishtr: all those things can be figured out but can we leave those not defined yet?<br> <emilio> ... and define just the non-multiple case for now?<br> <emilio> fantasai: I think we might need to come back and change things once we tackle the others<br> <gregwhitworth> ack gregwhitworth<br> <gregwhitworth> ack masonf<br> <emilio> chrishtr: we can take an action item to dig into that to make sure that changes might not be needed<br> <emilio> masonf: there's `multiple` and `size` which theoretically create those two axes<br> <emilio> ... behavior is a bit different in mobile vs. not, I think there are a lot of issues with `multiple` without that<br> <gregwhitworth> q+<br> <emilio> ... so I think we need feature detection but I'd like not to block on that<br> <lwarlow> q+<br> <emilio> fantasai: I think that'd be surprising, I'd like multiple to be defined for styleable select<br> <emilio> ... I think you can't just ignore the semantics of `multiple`<br> <gregwhitworth> ack gregwhitworth<br> <emilio> masonf: I was thinking of just forcing `auto` rather than ignoring `multiple`<br> <lwarlow> q-<br> <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<br> <emilio> chrishtr: agree on solvable, I don't think it blocks resolving on jarhar's proposal for the single case<br> <emilio> fantasai: I think the structure makes sense except the svg<br> <emilio> ... because it doesn't respect writing-mode<br> <emilio> ... in respect on the names of pseudos we want to be consistent with other stuff we expect to do elsewhere<br> <jarhar> q?<br> <chrishtr> proposed: "accept shadow dom structure as proposed initial comment in the issue, except for svg part"<br> <emilio> ... but over-all structure makes sense otherwise<br> <fantasai> s/to do elsewhere, so probably should discuss separately/<br> <emilio> jarhar: for pseudo names I agree they're not great<br> <chrishtr> "pseudo element names to be decided later"<br> <emilio> ... there's another issue for that<br> <emilio> ... as for the SVG I agree, there's a similar discussion for checkmarks<br> <emilio> ... we moved to a unicode character<br> <emilio> ... there's a down arrow thing<br> <chrishtr> q+<br> <emilio> ... do you think using it would be reasonable<br> <emilio> fantasai: if you use disclosure-open then it takes care of those issues<br> <gregwhitworth> ack chrishtr<br> <dbaron> s/disclosure-open/the disclosure-open counter style/<br> <emilio> chrishtr: suggestion is to make some forward progress on this. We can discuss checkmarks / svg / names later<br> <emilio> gregwhitworth: I agree, follow-up issues for glyph and pseudo-elements makes sense<br> <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"<br> <emilio> fantasai: should probably be one issue for the pseudos and such, we should decide them together<br> <jarhar> i already created an issue for pseudo elements here: https://github.com/w3c/csswg-drafts/issues/10462<br> <masonf> +1<br> <gregwhitworth> q?<br> <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"<br> <emilio> fantasai: inside the button one of the elements is a `<span>` and another a `<div>`, why?<br> <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<br> <emilio> jarhar: good question, maybe I was relying on block vs inline layout, but I might be overriding display anyways<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10380#issuecomment-2195015239 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 June 2024 15:25:53 UTC