- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Aug 2018 15:45:54 +0000
- To: public-css-archive@w3.org
The specified version isn't meant to be exactly identical to the prefixed version, as the prefixed version is sort of insane. The biggest problem with the prefixed version is that there's not value that lets native form control just do their normal thing. You need a gigantic list of values, some of which are meant to apply to non-standard pseudo elements that represent parts of form controls. As far as I know, no browser is planning on harmonizing the full list of pseudos+values. The proposed "standard" version has an "auto" value to cope with that problem, so you don't need the full laundry list of values (and associated pseudos) for it to work at all. `auto` does nothing on divs, and does the right thin on the right type of control. That said, we could add a few select values that people do want to opt into, either because they're genuinely useful, or for compat reasons. Browser representatives in the css wg have so far objected to doing that, but there's nothing in the design of the property that prevents us from adding more than just `auto` and `none`. If we do add more, there are two ways to go about it. `appearance: foo` (with `foo` being something else than `auto` and `none`, such as `buttton`, or `fieldset`…) could mean either: * just turn anything into a foo, so you can turn regular divs into foos, you can turn bars into foos, etc. * do the same as `auto` The second one is much more limited, but also much easier to implement. The reason it might be useful despite the limitation is that very often, people use that value to negate an earlier `appearance: none` and turn back the control into what it was supposed to be in the first place. Had they had an `auto` value, they'd have used that, but they don't so they're being specific. Since browser have so far said that they're not terribly interested in letting people turn buttons into fieldsets, or select menus into legends, maybe that's an easier path. Last time we talked about it, it looked like this might be enough to make the "standard" `appearance` web compatible, but this was not an in depth investigation. We should do one. The other thing that needs to be investigated in depth is exactly what `appearance: none` does, and how much of the form controls' parts it turns off. In the prefixed version, this is a relatively straightforward question, and the complexity is in how many non-standards pseudos you need to apply it to if you want to make various bits go away. But since the standard version is trying to do without pseudos, we need a detailed answer to that question. The high level principle is that since this is an appearance property, not a behavior property, it should leave everything that is necessary to be able to operate the control and for which a functional equivalent cannot be otherwise recreated in pure CSS, within the limits allowed by web compat. However, going through all the form controls and figuring out exactly what that means for each of them hasn't been done. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3024#issuecomment-417001915 using your GitHub account
Received on Wednesday, 29 August 2018 15:45:58 UTC