- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Aug 2017 15:26:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS UI 4 and appearance`, and agreed to the following resolutions:
* `RESOLVED: Put a note into "appearance" saying it's not ready to implement, list the possible solutions discussed here, ask impls which they want to do.`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: CSS UI 4 and appearance<br>
<TabAtkins> ScribeNick: TabAtkins<br>
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1250<br>
<TabAtkins> Florian: There's an appearance proeprty. We started standardizing it, because a lot of people use "none" on form controls to make them styleable in CSS.<br>
<TabAtkins> Florian: This previous existed as a prefixed form in most browsers.<br>
<TabAtkins> Florian: Before stadndardization, the values other than none was a very long list of all the ways an element could look; this list was different across browsers.<br>
<TabAtkins> Florian: We concluded this was impossible to standardize, in part because many apply to pseudo-elements that other browsers don't have, as they construct form elements differently.<br>
<TabAtkins> Florian: Instead, we'd just have an "auto" value that makes form controls look like whatever they need, and a "none" value that suppresses it.<br>
<TabAtkins> Florian: We could possibly exxtend this into a small list of special values, like "button" to make it look like a native button, but so far ahve resolved not to.<br>
<TabAtkins> Florian: Now Moz said that they need to implement all of the -webkit-appearance values.<br>
<TabAtkins> Florian: I'm a little suspicious.<br>
<TabAtkins> dbaron: Not sure if that's accurate.<br>
<TabAtkins> dbaron: I think it's, *when* we implemented both appearance and -webkit-appearance, sites broke.<br>
<TabAtkins> Florian: They first said they aliased them to each other, and that broke stuff.<br>
<TabAtkins> Florian: That's expected, they're very different.<br>
<TabAtkins> Florian: They said "we need to ipmlement all the -webkit values anyway, so the simple one isn't useful to us"<br>
<TabAtkins> dbaron: Not sure that's what we said/meant.<br>
<TabAtkins> Florian: Then I'm confused and need to know what they mean.<br>
<TabAtkins> Florian: "fwiw, we intend to support -webkit-appearance with all values that Chrome supports" ~ Mats Palmgren, June 7<br>
<astearns> comment here: https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-306788821<br>
<TabAtkins> dbaron: There are sites that specifically set "input { appearance: none; } input[type=checkbox] { appearance: checkbox; }"<br>
<TabAtkins> Florian: We did say that, if needed for webcompat, we could add a handful of required values.<br>
<TabAtkins> Florian: This is very different from adding all 50+ webkit values.<br>
<tantek> FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1368555<br>
<TabAtkins> dbaron: If that's the case, then don't put 'appearance' in a spec ready for impl.<br>
<TabAtkins> dbaron: Otherwise people try to implement it.<br>
<fantasai> TabAtkins: Maybe have a scary notice saying this is problemantic<br>
<fantasai> Florian: I had that note. WG asked me to remove it.<br>
<tantek> see the webcompat.com URLs in the above bugzilla bug<br>
<fantasai> TabAtkins: I'm fine with putting note back<br>
<fantasai> TabAtkins: to say that we might need some values<br>
<TabAtkins> Florian: Cool. But that's different from saying we need all the webkit values. Because then we need all the webkit pseudo-elements, and I'm not speccing that.<br>
<TabAtkins> jet: Doesn't mean we might not need it.<br>
<TabAtkins> Florian: Maybe, but it'll be a huge effort. Need good proof it's needed.<br>
<fantasai> and Florian should be given a correspondingly significant budget for working on it :)<br>
<TabAtkins> TabAtkins: So suggestion: add note saying don't implement this property yet; it needs some subset of the -webkit-appearance values; impls need to tell us which subset is necessary<br>
<TabAtkins> Florian: Initial draft included the other values Edge supports for -webkit; presumably that's for compat reasons.<br>
<TabAtkins> Florian: WG told me to remove it.<br>
<TabAtkins> gregwhitworth: My recollection was a question whether it was even needed.<br>
<TabAtkins> TabAtkins: David suggested we did - his example would break checkbox rendering.<br>
<TabAtkins> dbaron: I don't know the exact details, there's so many bugs and compat stuff it'll take a while to untangle.<br>
<TabAtkins> Florian: So two options: none | auto | <non-exhaustive-list> ; or none | <exhaustive-list><br>
<TabAtkins> fremy: Alternatiely: let it take any keyword, treat unknown ones as "auto".<br>
<TabAtkins> Florian: That doesn't match today.<br>
<TabAtkins> astearns: Why is "auto" only with non-exhaustive list?<br>
<ericwilligers> +q<br>
<TabAtkins> TabAtkins: We could put it with exhaustive, and we could omit it from the non-exhaustive list. Depends on details.<br>
<tantek> q?<br>
<astearns> ack ericwilligers<br>
<TabAtkins> fremy: If you have "div { -webkit-appearance:button}", nothing happens. But "input { -webkit-appearance: none; }" does work; using "checkbox" will work on a checkbox input, but won't turn a text input into a checkbox.<br>
<TabAtkins> ericwilligers: I heard dbaron say that if they ship appearance it'll break compat. Can we just change the name?<br>
<fremy> TabAtkins, yes<br>
<tantek> q+ to note or we go with original guidance to drop appearance from CSS UI, and let it get documented in https://compat.spec.whatwg.org/ instead (all prefix or not variants)<br>
<TabAtkins> Florian: And then we can avoid saying "none", and use "normal" instead, which sounds better.<br>
<tantek> per https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-306788821<br>
<TabAtkins> dino: Who implements unprefixed appearance?<br>
<fremy> TabAtkins, input { -webkit-apperance:none} input[type=button] { -webkit-appearance: checkbox } renders as a button<br>
<TabAtkins> Florian: Nobody that I know, but I last checked a while ago.<br>
<TabAtkins> dbaron: We tried, but backed it out before it hit stable.<br>
<TabAtkins> dbaron: It's not clear what portions of the problem were with "appearance" and which were with "-webkit-appearance".<br>
<TabAtkins> dino: I was considering implementing unprefixed with just "none" and "auto".<br>
<TabAtkins> ack tantek<br>
<Zakim> tantek, you wanted to note or we go with original guidance to drop appearance from CSS UI, and let it get documented in https://compat.spec.whatwg.org/ instead (all prefix or not<br>
<Zakim> ... variants)<br>
<TabAtkins> tantek: One of the points Mats made is that this isn't a particularly useful feature for web authors.<br>
<TabAtkins> tantek: So one proposal is just to drop it entirely.<br>
<TabAtkins> fantasai: People use it a lot.<br>
<TabAtkins> TabAtkins: I use "none" plenty to do styles on my buttons, etc.<br>
<TabAtkins> dbaron: It's not cleaer to me which of these was the good reason to back the whole thing out.<br>
<TabAtkins> dbaron: ONe of my guidelines is that if a user reports a bug, that's a compat problem; if the dev does, that's not a compat problem.<br>
<TabAtkins> dbaron: And one of them was reported by a dev, because it comes with a jsfiddle.<br>
<fantasai> s/not/not necessarily/<br>
<fantasai> TabAtkins: That said, your example looks believable<br>
<fantasai> TabAtkins: It would be fixed by fremy's proposal<br>
<fantasai> astearns: would also be fixed by minting an entirely new property<br>
<TabAtkins> astearns: So that seems like a cleaner solution.<br>
<TabAtkins> TabAtkins: Possible conclusion, just leave this unresolved, but note the handful of possible solutions and ask impls to tell us which they want to do.<br>
<TabAtkins> Florian: Seems better than trashing it.<br>
<tantek> seems like a lot of work for very little benefit<br>
<tantek> so I question why<br>
<TabAtkins> RESOLVED: Put a note into "appearance" saying it's not ready to implement, list the possible solutions discussed here, ask impls which they want to do.<br>
<fantasai> TabAtkins: Answer to tantek's question is that people use it for useful things today<br>
<fantasai> TabAtkins: and there is no other solution for what they want today<br>
<tantek> where is the documentation of the use-case in the spec? let's drop a URL here for the minutes<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-320003220 using your GitHub account
Received on Thursday, 3 August 2017 15:26:46 UTC