- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Apr 2021 23:38:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `appearance: base to enable interoperable styling of controls/components`, and agreed to the following: * `RESOLVED: This feature should be solved with an attribute rather than a CSS value` <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: appearance: base to enable interoperable styling of controls/components<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5998<br> <myles> gregwhitworth: The context is that we're trying to start down the path of standardizing form controls and components. We'll need an agreed-upon DOM and styles.<br> <myles> gregwhitworth: Last time I presented on this, I presented about the base appearance keyword and the pseudo element for checkbox. I want to de-tangle them. I've had requests for input type=range<br> <myles> gregwhitworth: I want to move forward with the base keyword.<br> <myles> gregwhitworth: For more context, the base keyword would be a toggle that informs the browser that you want to have a standardized dom and styles for a given element. That would allow you to style interoperably.<br> <myles> gregwhitworth: UAs want to provide their own defaults. Authors need to opt-in.<br> <emilio> q+<br> <myles> gregwhitworth: I'm looking for feedback. questions, thoughts.<br> <Rossen_> ack emilio<br> <florian> q+<br> <myles> emilio: If we want this to change the shadow dom that UAs create, this is better as an attribute, despite that option sucking.<br> <myles> emilio: for gecko, it's kind of okay to create a lot of dom during layout. it's not amazing. I'd like to get rid of that mechanism. Blink generates the shadow dom at the DOM level, not depending on layout.<br> <myles> emilio: Making CSS changes affect DOM for them, i suspect it would be more of an issue.<br> <myles> emilio: Conceptually, it feels wrong<br> <myles> gregwhitworth: Sure. I'm primarily .... not that that's bikeshedding .... I want to get at the more meta-issue. If implementors say they prefer the attribute, I can bring this to WHATWG. I'm asking if this group accepts standardized styles and standarized DOM<br> <myles> emilio: I'm definitely okay in getting more interop in form controls.<br> <myles> emilio: This detail probably matters.<br> <myles> emilio: Can chrishtr weigh in?<br> <hober> q+<br> <myles> emilio: Is CSS the right place for this toggle?<br> <tantek> +1 emilio<br> <myles> hober: My understanding is that we're also pretty reluctant to add more mechanisms in CSS that cause DOM to get created.<br> <myles> hober: So, I think, this does seem like a problem we should be trying to solve. An attribute would be less weird.<br> <myles> hober: ... on the implementation side of things.<br> <Rossen_> ack florian<br> <myles> florian: In addition to the implementation complexity, I have 2 other reasons for why attributes are probably better.<br> <Rossen_> ack hober<br> <myles> florian: 1. If we got with a CSS property with a single bas keyword, we need to introduce it simultaneously on all the elements that accept it, or have a bunch of values so people can detect their way into doing the right thing. That problem isn't true if we do it as an attribute.<br> <myles> florian: 2. Depending on whether an element is base or not base, you want to style it differently. If you cause it to be base or not base through CSS, then you can't select on it.<br> <tantek> +1 florian about what you want to style differently<br> <myles> florian: The UA stylesheet needs to be different for a regular checkbox vs a base checkbox, if the switch is in CSS, all that solves itself if the switch is done via an attributre.<br> <Rossen_> ack fantasai<br> <myles> florian: We have multiple things pointing in this direction. All of these work better if we got with an attribute vs a CSS property.<br> <myles> fantasai: Just to throw a wrench into that, florian, you want to style them differently based on the attribute, but also on whether or not the browser supports that attribute<br> <myles> florian: We should have an attribute an attribute AND a pseudoclass.<br> <myles> fantasai: We can also add an @supports query.<br> <myles> fantasai: We need a way to answer the question "is this implemented"<br> <myles> florian: The base pseudoclass would mean "is it present AND implemented"<br> <fremy> +1 to the pseudo-class suggested by florian<br> <myles> florian: pseudoclasses are simpler<br> <tantek> +1 to considering pseudoclass<br> <myles> fantasai: For style vs content vs behavior, this belongs more in CSS than HTML. But emilio and florian gave good arguments for why it might have to end up in HTML regardless.<br> <myles> fantasai: If we add appearance: value, I would go for appearance: basic<br> <tantek> in general I'm opposed to any extension to the 'appearance' property, but that's a lower level concern<br> <heycam> `input[type=checkbox]:custom`<br> <myles> Rossen_: Most of the conversation leans toward attribute. gregwhitworth, does that work?<br> <myles> gregwhitworth: I want a resolution, as ammunition for going to WHATWG<br> <myles> gregwhitworth: Also for adding styles to checkbox. I'm looking for a resolution.<br> <myles> florian: 2 resolutions: 1. to use an attribute, and 2. to add a pseudoclass<br> <myles> fantasai: proposed resolution: This functionality be pursued as an attribute, and CSS adds a mechanism to detect an element in this mode in a browser that has support for it<br> <myles> gregwhitworth: I'm fine working on that BTW<br> <fantasai> "CSS Working Group recommends that"<br> <myles> bkardell_: Wouldn't existing "define" work?<br> <myles> bkardell_: the "define" pseudoclass<br> <myles> bkardell_: should work<br> <myles> bkardell_: I guess not, because it's already defined. never mind<br> <myles> emilio: It almost works, because you can't extend form controls. But maybe you can. If you can, then it doesn't work<br> <myles> gregwhitworth: I don't want to go down that rabbit hole<br> <myles> emilio: It seems cleaner to use a different thing<br> <myles> Proposed resolution: This functionality be pursued as an attribute instead of a CSS property, and CSS adds a mechanism to detect an element in this mode in a browser that has support for it<br> <bkardell_> it woudl already be true, is the real problem I think<br> <myles> florian: I support the resolution as it stands. But I would also support a more specific resolution: the mechanism is a pseduclass. @supports would be awkward. Psedudoclass would make it easy. If we do a pseudoclass, we have to figure out which element you're testing against. Would look like a selector<br> <bkardell_> 0 specificity pseudo please?<br> <myles> fantasai: Yeah, this is element-by-element<br> <myles> florian: It's also applied element-by-element<br> <myles> fantasai: yeah.<br> <myles> fantasai: I guess that what it's going to have to be. I can't think of a name that makes sense<br> <myles> florian: We should match the name that HTML sues<br> <myles> bkardell_: Can it be 0 specficity?<br> <myles> gregwhitworth: Can we figure this out after I open the issue?<br> <myles> bkardell_: yes.<br> <myles> fantasai: I support greg investigating whether or not it should be 0 specificity<br> <myles> s/greg/gregwhitworth/<br> <myles> Rossen: We were leaning toward using an attribute. Second resolution: Adding a mechanism to detect the state of the feature. Is this right?<br> <myles> RESOLVED: This feature should be solved with an attribute rather than a CSS value<br> <fantasai> [I would like to note that it's not great that, in order to change the styling of the form element, it's necessary to change the markup. But it seems we're constrained by practical considerations.]<br> <myles> ACTION gregwhitworth: Create an issue about adding a mechanism in CSS to determine if this feature is enabled<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5998#issuecomment-816302367 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 April 2021 23:38:22 UTC