Spec -webkit-appearance

[miketaylr]

See https://bugzilla.mozilla.org/show_bug.cgi?id=605985#c28 for some good notes.

Edge supports none, button and textfield values: https://msdn.microsoft.com/en-us/library/dn793580%28v=vs.85%29.aspx

[karlcow]

ok found something about differences of implementations in
webcompat/web-bugs#1006 (comment)

See the codepen at http://codepen.io/anon/pen/QyJMGx

[karlcow]

WebKit and Blink drops the -webkit-appearance: button when there is a background-image.

[karlcow]

Created https://bugzilla.mozilla.org/show_bug.cgi?id=1246836

[miketaylr]

Thank you @karlcow -- I think there's a lot to learn about what people expect from (-webkit-)appearance. Would be good to sit down with you at some point in the near future and hash this all out.

[karlcow]

(just stating the obvious for people passing by)

It's kind of nasty because the -vendor- were specifically designed to allow experimentation so that each rendering engine could have difference of implementations. Which is exactly this in this case.
The issue comes back with the reality of developers relying on it because of the big market share of one of the rendering engine and then the space for experimentation becomes now a space of constraints where we need to replicate the behavior of others

The possibility is to have a real appearance standard property but that's not the case.

• MDN doc
• dropped CSS3 feature
• CSS4 draft. It's defined with two values only: auto and none. @frivoal is the current editor.

[karlcow]

Just to be sure I looked at Blink in devtools on
http://codepen.io/anon/pen/QyJMGx

We can see the -webkit-appearance: button and background

but then if we check in the computed value tab, we can see that the value was set to none:

😖

[frivoal]

My CSS 4 draft only has two values because that is what browser vendors have stated they wanted it to have. I am ready to include a handful more options (button and the like) if there's demand for it, but so far there were explicit requests against it.

This is a case where various browsers behavior are different enough that the spec cannot merely pave the cow paths, but has to find some sensible core behavior into this mess. I'm sure that the behavior I have for now is underspecified, but I do think I got the basics right. @miketaylr and @karlcow , if you're having a meeting to dig into this, I'd be happy to join you remotely.

[miketaylr]

This is a case where various browsers behavior are different enough that the spec cannot merely pave the cow paths, but has to find some sensible core behavior into this mess.

Yes, agreed.

if you're having a meeting to dig into this, I'd be happy to join you remotely.

Great, thanks! It might be further down the road a bit (and it might be entirely remote), but I'll ping you before hand.

[miketaylr]

Here's a related issue https://bugzilla.mozilla.org/show_bug.cgi?id=605985#c41:

[...] we use feature-detection to style the checkbox properly:

- With "webkit-appearance:none + custom background and border" on Webkit,
- With a custom label on other browsers.

[karlcow]

OK so not so sure about the behavior of Blink/WebKit which is in fact normal.
But Gecko on the other hand is acting strangely.

Play with this

<style>select {}</style>
<select>
    <option value="0">First option</option>
</select>

Then

<style>select {-moz-appearance: button;}</style>
<select>
    <option value="0">First option</option>
</select>

Then

<style>select {-moz-appearance: button;
    background-color: #e8a907;
}</style>
<select>
    <option value="0">First option</option>
</select>

👀

[bzbarsky]

Gecko's behavior is because we use OS theme drawing to implement appearance in general, and OS themes don't generally (across platforms) allow saying things like "draw me an OS-default button, but with the background set to this custom color". And even if they do for buttons they might not for other controls...

[karlcow]

@bzbarsky ah! Thanks.

[frivoal]

@bzbarsky I'd appreciate if you had time to go through https://drafts.csswg.org/css-ui-4/#appearance-switching and give some feedback (though I'd understand if you had better things to do...)

[karlcow]

note to myself when I do the research about the appearance behaviors: to check on different browsers AND OSes

[bzbarsky]

@frivoal The "All decorative visual aspects of a form control which are not caused by a CSS style rule" wording leaves lots of room for non-interop, because UAs may be implementing all sorts of stuff in terms of UA style rules.

Apart from that, I believe that for some form controls some UAs treat them as non-replaced elements (e.g. rendering ::before content), and pages try to use that with appearance:none. In practice, I think that means that appearance: none needs to make some things non-replaced elements. Try this testcase in a WebKit-based browser:

<!DOCTYPE html>
<style>
  * { -webkit-appearance: none }
  input::before { content: "hey" }
</style>
<input type="text" value="text input">
<input type="checkbox">
<input type="radio">
<input type="range">

And note that for the range thing, the fact that the slider appears but other things disappear is totally arbitrary: in practice the look of all that stuff would be defined as UA CSS rules, at least in Gecko...

[frivoal]

@bzbarsky :

The "All decorative visual aspects of a form control which are not caused by a CSS style rule" wording leaves lots of room for non-interop, because UAs may be implementing all sorts of stuff in terms of UA style rules.

Isn't that something that can be dealt with using all: unset? Or are you thinking that in addition, the UA would use (non-standard) pseudo elements to represent various parts of the control, and we'd need to override these as well?

I think that means that appearance: none needs to make some things non-replaced elements

Are there things which need to stay replaced elements, or can appearance:none make everything non-replaced? I suspect that the answer is that some things need to stay replaced elements (such as <input type=text>), but what's your take?

And note that for the range thing, the fact that the slider appears but other things disappear is totally arbitrary: in practice the look of all that stuff would be defined as UA CSS rules, at least in Gecko...

I have a hard time seeing how you make the slider knob exclusively with UA CSS rules. The slider knob isn't merely decorative. The way manipulating it affects the state of the control cannot be replicated in CSS, which is why I don't think its existence should be impacted by CSS, even if its look may be (through a The same goes for the drop down in <select> or the calendar in <input type=date>. In contrast, a magnifying glass in an <input type=search> is purely decorative, and should be disabled.

As I understand, Gecko does it by styling non-standard pseudos like ::-moz-range-track and ::-moz-range-thumb. I don't count this as "<input type=range> is done purely in CSS", since the existance of these pseudos isn't caused by CSS, and you couldn't do <input type=range> in CSS without them.

I am not saying that this is clear cut for every control, and we'll probably need to dive in and make some judgement calls in a few cases, but as a high level guideline, it makes sense to me.

[bzbarsky]

Isn't that something that can be dealt with using all: unset?

I don't know what you mean by "dealt with". Let me put it more simply: the border around an <input type="text"> is produced by a CSS rule in the UA stylesheet. Should appearance: none cause that border to disappear or not? As the spec is written right now, sounds like "not". But I expect the "correct" behavior is it should disappear.

Are there things which need to stay replaced elements

Text inputs certainly need to stay replaced, as you said. Probably <select> too, unless you want all the options dumped onto the page as text.

I have a hard time seeing how you make the slider knob exclusively with UA CSS rules.

The behavior wouldn't be. But the way it looks would be.

Put another way, a slider knob is just a thing with some border and border-radius and maybe a background gradient (probably on a pseudo-element). Should those things still be applied when appearance: none? If yes, how is that reconciled with the text input border situation above?

As you note, it's exactly like the dropdown arrow in <select>. What is the principled thing that describes why one is hidden and the other is not hidden?

In practice what I think you will need to do is for every control define separately what appearance: none means. For some it will mean "just make it a non-replaced element". For some it will mean "render it just like a text input" or something. For some it will mean other things. I doubt you'll be able to write any high level guidelines here that don't have tons of exceptions.

[FremyCompany]

As a followup to the CSSWG Telcon mention of this thread, I just wanted to mention that for instance input[type=file] works very differently than others even with appearance:none, too:
https://jsfiddle.net/grLynqq8/1/

[karlcow]

Another example.
https://sp5971.jal.co.jp/sp/RsvFlightInfo.do
https://webcompat.com/issues/1005

[karlcow]

note to myself.
https://n8finch.com/changing-select-menus-cross-browser-compatibility/

[karlcow]

@frivoal are there tests in the CSS test suite for appearance? I don't see any test suite link into CSS4-ui draft.

[karlcow]

note to self
See also w3c/csswg-drafts#119 and http://logs.csswg.org/irc.w3.org/css/2016-05-10/#e683581

[frivoal]

@karlcow I don't believe there's any yet (haven't written or reviewed any). I do plan on writing some, but haven't found the time yet. I do expect to find some time for this not too far from now, so don't despair just yet. If you want to write some and send a pull request on https://github.com/w3c/csswg-test/, I am more than happy to review and merge them.

[karlcow]

@frivoal I guess it should be a new folder with css-ui-4 or something similar. I need to read again how the CSS WG is managing the tests.

Looking at https://github.com/w3c/csswg-test/tree/master/css-ui-3
And https://github.com/w3c/csswg-test/#contributing
I don't see a step by step for contributing.

I have started today to collect some naïve tests for appearance. This is very early (in progress) stuff. http://codepen.io/webcompat/pen/yJKbgp

[frivoal]

The csswg is currently looking into updating the way we manage test contributions, but regardless, this should be an unsurprising affair if you're used to other testing on the web plaform:

This applies as usual: http://testthewebforward.org/docs/test-style-guidelines.html
Primarily, we're interested in reftests: http://testthewebforward.org/docs/reftests.html, although tests harness test or manual tests are ok as well if you cannot do otherwise.

As for metadata, the historic documentation is this: http://testthewebforward.org/docs/css-metadata.html. Note that we've relaxed these requirements these days and have not yet updated documentation:

• The updated rule about the title element should be "use common sense"
• author / reviewer metadata is not needed since it's in the commit log
• The specification link is optional since the spec can be inferred from the path. you store the file in. You can still use it to be more specific or link to multiple specs
• some of the flags are outdated and useless, and will be removed. Most of the time an empty list is OK, but if not I'll pick it up during review.

[karlcow]

Some screenshot http://codepen.io/webcompat/full/yJKbgp/ (still work in progress)

[karlcow]

Yeah found another funky one:
http://codepen.io/webcompat/pen/vXOdAX

from left to right: Gecko, WebKit, Blink

on <input name="type" type="radio"> (checked or not).

Why is it important?

on http://transit.yahoo.co.jp/

[karlcow]

Added to https://bugzilla.mozilla.org/show_bug.cgi?id=605985#c50

[karlcow]

for this case, display:none seems to fix the layout.

[miketaylr]

Yeah found another funky one:

In case codepen blows up, it looks like -moz-appearance: none w/ width:100% on a radio input causes the input to turn into a sideways egg. 🍳

[karlcow]

And yet another one
https://www.chromestatus.com/feature/5668635896971264

Web authors had no way to completely disable UA rendering of METER element, and were unable to render them with pure CSS. This feature is to implement the standard appearance:none behavior for METER element as -webkit-appearance:none. -webkit-appearance:none removes UA rendering at all, and renders the content of element.

http://codepen.io/webcompat/pen/RGAoRX

[karlcow]

Rendering differences: Firefox/gecko left, Opera/Blink right

[karlcow]

fyi.

Added a new -webkit-appearance CSS property for Apple Pay buttons — https://developer.apple.com/safari/technology-preview/release-notes/

[miketaylr]

Edge supports none, button and textfield values: https://msdn.microsoft.com/en-us/library/dn793580%28v=vs.85%29.aspx

Either this was true at the time, or it was never true. Quick testing in latest shows that they support the none value but not button or textfield.

[miketaylr]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1333482 for implementing -webkit-appearance: none|auto (as an alias of unprefixed appearance).

[frivoal]

Either this was true at the time, or it was never true.

I do not recall whether I had tested this. Maybe I did, maybe I just trusted the MSDN article.

[karlcow]

Scratching my eyes with
https://www.chromestatus.com/feature/5743649186906112

[miketaylr]

Scratching my eyes with
https://www.chromestatus.com/feature/5743649186906112

I think we can ignore this for this issue -- it seems to just be about making the buttons in MacOS use native themes.

[karlcow]

We are working on this with @miketaylr and @MDTsai checking the different values/behaviors in different browsers to know what we should do in Firefox.

[FremyCompany]

@karlcow Please let us know if you find anything that is not already mentioned on the w3c issue:
w3c/csswg-drafts#1250 (comment)

[stephenmcgruer]

Hi all; I landed web-platform-tests/wpt@1419513 recently to add a tentative test for -webkit-appearance standardization efforts. The test just sets each known value (based on the Chromium implementation) to an element, and then asserts that getComputedStyle(elem).webkitAppearance matches.

As it turns out, currently the test fails on Chromium on OSX due to some platform-specific behavior in the implementation (menulist turns into menulist-button for getComputedStyle). I'm seeing some pushback against the test there as some see this test as too early and for a non-spec feature.

Would appreciate input from those looking at implementing -webkit-appearance: is the landed WPT test helpful in working towards a spec, or is still too early for this test to be defined?

[stephenmcgruer]

Ping; if there is no support for web-platform-tests/wpt@1419513 as a useful test, then I will revert it in two weeks time. Further discussion with @miketaylr has implied it isn't that useful, as -webkit-appearance acts differently on different elements, whilst the test as written just tests the computed style of divs.

[miketaylr]

Given https://drafts.csswg.org/css-ui-4/#propdef--webkit-appearance, I think we can just close this.