- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Feb 2020 17:32:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Custom state pseudo class proposal`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Custom state pseudo class proposal<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4805<br> <bkardell_> q+<br> <dael> Rossen_: This is about a custom state pseudo classes. Being worked on in WICG.<br> <dael> Rossen_: Ready to be shipped by chrome in I believe 82 which is 4 or 6 weeks from now-ish. I don't know exact dates for when it's on by default but feature will be spread and enabled for large amount of users<br> <dael> Rossen_: Some of TAG feedback was around shape of API and it only allows bool state checks<br> <dael> Rossen_: This was acknowledged by feature authors but dismissed as can live with for now<br> <Rossen_> q?<br> <dael> Rossen_: Talking about with WG is I looked through past feautre discussion and didn't see this covered. Before it's too late wanted to give air time with group and gather if any reservations or concerns<br> <dael> bkardell_: I wanted to mention that a whole bunch of people from WG have been involved in design and discussion. This is like constructable stylesheets where that's the case and it's hard to know right venue for discussion. Given there's history and thought would it make sense to present a bit about it?<br> <dael> Rossen_: Sounds great. If you want to take a couple minutes and frame the feature and intent it would be great. Are you the right person or should we ask somebody else<br> <dael> bkardell_: I suppose I could, but TabAtkins is on and can do a good job<br> <dael> TabAtkins: Been a bit since I looked at it. Core deal is custom elements sprout a new dom token map that takes strings. Can match with :state you say :state and it can match<br> <dael> TabAtkins: Reason is you want to expose internals selectors can match w/o manipulating visible dom. shadow dom is a lot exposing attributes without impacting outside. Design is canted toward that direction wehre it's bool token or not. Future room for name and value but right now it focuses on class<br> <dael> bkardell_: Not unlike :fcous, :hover internal states<br> <Rossen_> q?<br> <dael> TabAtkins: That's what it's meant to be able to expose. Internal tates like that. It could be done via a class but b/c it's UA it's pseudoclasses<br> <emilio> q+<br> <Rossen_> ack bkardell_<br> <dael> Rossen_: Questions here. Is the current proposal in it's form going to preclude addition of anything other than bool?<br> <dael> TabAtkins: No. Syntax is easily extensible to allow it when we want to do it.<br> <dael> Rossen_: And this was major concern raised and attempted to be debunked in issue I linked to. It was that there are no interesting bool states and no need to feature creep. Checkbox has 3 states and things like that. As long as non-bool aren't precluded in the future this is not too bad<br> <bradk> So, not really for things similar to ‘nth-child()’ ?<br> <dael> TabAtkins: Correct. Nothing would prevent that in the future<br> <plinss> q+<br> <Rossen_> ack emilio<br> <dael> emilio: This is for top level custom element, right? Find it weird it works for custom and not regular elements. Exposing states from parts they must be custom or different like tokens. It's . abit ugly<br> <dael> emilio: Let's say you want to expose a state in a component. It would only work if the part is a custom element. If you don't want custom for example if it's SVG you need part elements instead using :state which is meh. Why doesn't it work for all elements?<br> <dael> TabAtkins: Main reason is...eaiser to put this structure on the root instead of arbitrary elements. You articulate a good use case for parts of shadow element exposing states. Ordinary element can just use class and multi ways for same thing is weird. Leads to there is a way to do bool state in parts which is add more part names. parts are basically classes and states are basically classes<br> <dael> emilio: Could use same arguement to say top level element can use class<br> <fremy> q+<br> <dael> TabAtkins: But then if you use class component messes with outer page visible section which we try and avoid, espeicially with things like aria stuff we're trying to mess with. Exposing controls without visible extra attributes is the goal of shadow dom. That's what's different for class. Doesn't apply to state vs part<br> <dael> emilio: Okay, I can buy that. A bit weird to have 3 ways to attach bool token to element<br> <dael> bkardell_: If you read the issue there is a desire to have parity where we could do the same thing on focus and hover type elements. They work today and it would be handy to have a custom element where you can have state. I agree this isn't solving all prblems like this but I think the idea here is limit the scope<br> <dael> plinss: Two concerns<br> <Rossen_> ack plinss<br> <dael> plinss: I accept that majority of use cases are bool. There are examples of non-bool state. Happy it's extensible in css but JS api is not in .away that's dev friendly. There's already things that are map-like but we don't use map api. I'd like work done on api to make it more future proof. I'd like it to be able to handle non-bool cleanly<br> <AmeliaBR> q?<br> <dael> plinss: Second is should it be :state or :--[name] and really make it a custom pseudoclass and not an odd pseudoclass called state<br> <dael> TabAtkins: Not a bad suggestion. Alright.<br> <dael> plinss: If we change this to :--[name] I'd like to see part do the same for consistency. For syntax they should be a unit. I have other issues with :part but that's sep. convo<br> <bkardell_> I have brought this up in the past, I think :--name is more interesting, but I think the argument is made this is diff and specifically about a kind of parity<br> <dael> fremy: I think plinss brought a good point. Thinking similar. I understand TabAtkins arg about need for aria mapping not changing with setting attribute. But we could do same as :part Maybe we want JS API to be able to remove values not in attrbute<br> <emilio> q+<br> <emilio> ack fremy<br> <dael> fremy: I don't understand why we need :State and :part. Why can't we have same API that applies on the same thing as :part. Maybe it's a point to think about<br> <bkardell_> can I ask how is it the same as parts, it seems not the same to me... ?<br> <bkardell_> +1 what peter said<br> <dael> plinss: That ties into my issues about part. I think it's valid to have custom state and custom part. How part is now is like a pseudoclass and I"d like to be a pseudo element thing. Then it makes sense to have them as 2 things<br> <bkardell_> and to what emilio said :)<br> <dael> fremy: Can query multiple part things, but I was going to mention that [missed]<br> <dael> fremy: It does make sense, fine.<br> <dael> TabAtkins: Switching to ::-- we're switching to tag name not class name. Requires if people to decide if it's class name or part name like. Maybe shouldn't expose to authors.<br> <dael> TabAtkins: Can we put this in GH repo? This is good.<br> <bkardell_> q+<br> <emilio> ack emilio<br> <dael> plinss: I raised this is tag review and didn't get a fair shake i felt. It would be good if it's addressed. You and I can haggle part separately. this is about state for now<br> <dael> Rossen_: Given we're 30 min into call I think reasoning and motivation to put this in group is achieved. Raising awareness and getting right people while we can provide feedback and engage with folks getting ready to ship.<br> <dael> Rossen_: I see two people on queue. I'd prefer to move on unless emilio or bkardell_ want to bring something pressing<br> <emilio> Rossen_: was already out of the queue ;)<br> <Rossen_> ack bkardell_<br> <dael> bkardell_: one thing before it's lost. Of course I 100% agree with plinss with wanting to see :: for custom pseudoclass and pseudostate.<br> <dael> bkardell_: Question worth getting plinss and group thought is if that's the same as this or if this is discrete and about custom elements. It's been portrayed to me that they are different. Encapsulating state is a different things then a general purpose pseudoclass<br> <dael> bkardell_: Interesting to think about<br> <dael> Rossen_: Let's continue in linked gh and WICG.<br> <dael> Rossen_: We'll also take this is TAG<br> <bkardell_> s/::/:--<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-591547956 using your GitHub account
Received on Wednesday, 26 February 2020 17:32:40 UTC