New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec -webkit-appearance #6

Open
miketaylr opened this Issue Jul 30, 2015 · 42 comments

Comments

6 participants
@miketaylr
Collaborator

miketaylr commented Jul 30, 2015

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 9, 2016

Collaborator

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

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

Collaborator

karlcow commented Feb 9, 2016

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

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

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 9, 2016

Collaborator

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

Collaborator

karlcow commented Feb 9, 2016

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

@karlcow

This comment has been minimized.

Show comment
Hide comment
Collaborator

karlcow commented Feb 9, 2016

@miketaylr

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Feb 9, 2016

Collaborator

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.

Collaborator

miketaylr commented Feb 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 9, 2016

Collaborator

(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.

Collaborator

karlcow commented Feb 9, 2016

(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.

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 9, 2016

Collaborator

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

capture d ecran 2016-02-09 a 14 19 41

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

capture d ecran 2016-02-09 a 14 21 43

😖

Collaborator

karlcow commented Feb 9, 2016

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

capture d ecran 2016-02-09 a 14 19 41

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

capture d ecran 2016-02-09 a 14 21 43

😖

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Feb 9, 2016

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.

frivoal commented Feb 9, 2016

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 comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Feb 9, 2016

Collaborator

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.

Collaborator

miketaylr commented Feb 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Feb 16, 2016

Collaborator

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.
Collaborator

miketaylr commented Feb 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 23, 2016

Collaborator

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>

👀

Collaborator

karlcow commented Feb 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Feb 23, 2016

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...

bzbarsky commented Feb 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 23, 2016

Collaborator

@bzbarsky ah! Thanks.

Collaborator

karlcow commented Feb 23, 2016

@bzbarsky ah! Thanks.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Feb 23, 2016

@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...)

frivoal commented Feb 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Feb 23, 2016

Collaborator

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

Collaborator

karlcow commented Feb 23, 2016

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

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Feb 24, 2016

@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...

bzbarsky commented Feb 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Feb 24, 2016

@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.

frivoal commented Feb 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Feb 24, 2016

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.

bzbarsky commented Feb 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Mar 16, 2016

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/

FremyCompany commented Mar 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
Collaborator

karlcow commented Apr 1, 2016

@karlcow

This comment has been minimized.

Show comment
Hide comment
Collaborator

karlcow commented Jul 5, 2016

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Jul 21, 2016

Collaborator

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

Collaborator

karlcow commented Jul 21, 2016

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

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow
Collaborator

karlcow commented Jul 21, 2016

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jul 21, 2016

@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.

frivoal commented Jul 21, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Jul 21, 2016

Collaborator

@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

Collaborator

karlcow commented Jul 21, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jul 21, 2016

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.

frivoal commented Jul 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Jul 21, 2016

Collaborator

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

Collaborator

karlcow commented Jul 21, 2016

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

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Sep 8, 2016

Collaborator

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

from left to right: Gecko, WebKit, Blink

capture d ecran 2016-09-08 a 15 10 31

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

Why is it important?

capture d ecran 2016-09-08 a 15 13 11

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

Collaborator

karlcow commented Sep 8, 2016

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

from left to right: Gecko, WebKit, Blink

capture d ecran 2016-09-08 a 15 10 31

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

Why is it important?

capture d ecran 2016-09-08 a 15 13 11

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

@karlcow

This comment has been minimized.

Show comment
Hide comment
Collaborator

karlcow commented Sep 8, 2016

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Sep 8, 2016

Collaborator

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

Collaborator

karlcow commented Sep 8, 2016

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

@miketaylr

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Sep 8, 2016

Collaborator

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. 🍳

Collaborator

miketaylr commented Sep 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Sep 13, 2016

Collaborator

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

Collaborator

karlcow commented Sep 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Sep 13, 2016

Collaborator

Rendering differences: Firefox/gecko left, Opera/Blink right
capture d ecran 2016-09-13 a 12 05 12

Collaborator

karlcow commented Sep 13, 2016

Rendering differences: Firefox/gecko left, Opera/Blink right
capture d ecran 2016-09-13 a 12 05 12

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Sep 29, 2016

Collaborator

fyi.

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

Collaborator

karlcow commented Sep 29, 2016

fyi.

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

@miketaylr

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Jan 24, 2017

Collaborator

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.

Collaborator

miketaylr commented Jan 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Jan 24, 2017

Collaborator

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

Collaborator

miketaylr commented Jan 24, 2017

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

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jan 25, 2017

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.

frivoal commented Jan 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karlcow
Collaborator

karlcow commented Aug 8, 2017

@miketaylr

This comment has been minimized.

Show comment
Hide comment
@miketaylr

miketaylr Sep 4, 2017

Collaborator

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.

Collaborator

miketaylr commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Sep 4, 2017

Collaborator

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.

Collaborator

karlcow commented Sep 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 5, 2017

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

FremyCompany commented Sep 5, 2017

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

@stephenmcgruer

This comment has been minimized.

Show comment
Hide comment
@stephenmcgruer

stephenmcgruer Feb 15, 2018

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 commented Feb 15, 2018

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?

aarongable pushed a commit to chromium/chromium that referenced this issue Feb 26, 2018

Count getComputedStyle() for -webkit-appearance
Now getComputedStyle() for -webkit-appearance returns adjusted values.
See [1].  We'd like to know whether we can remove this behavior or not.

[1] whatwg/compat#6 (comment)

Bug: 810162
Change-Id: Icc17d681d7105d8a77ff07e18b7f270bd6918f01
Reviewed-on: https://chromium-review.googlesource.com/936523
Reviewed-by: Takayoshi Kochi <kochi@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Kent Tamura <tkent@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539142}
@stephenmcgruer

This comment has been minimized.

Show comment
Hide comment
@stephenmcgruer

stephenmcgruer Jun 13, 2018

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.

stephenmcgruer commented Jun 13, 2018

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.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 11, 2018

Remove webkit-appearance.tentative.html WPT test
This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see
whatwg/compat#6), and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug: 810162
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b

aarongable pushed a commit to chromium/chromium that referenced this issue Jul 12, 2018

Remove webkit-appearance.tentative.html WPT test
This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see
whatwg/compat#6), and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug: 810162
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b
Reviewed-on: https://chromium-review.googlesource.com/1134387
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574546}

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jul 12, 2018

Remove webkit-appearance.tentative.html WPT test
This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see
whatwg/compat#6), and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug: 810162
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b
Reviewed-on: https://chromium-review.googlesource.com/1134387
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574546}

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Jul 12, 2018

Remove webkit-appearance.tentative.html WPT test
This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see
whatwg/compat#6), and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug: 810162
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b
Reviewed-on: https://chromium-review.googlesource.com/1134387
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574546}

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jul 24, 2018

Bug 1475152 [wpt PR 11933] - Remove webkit-appearance.tentative.html …
…WPT test, a=testonly

Automatic update from web-platform-testsRemove webkit-appearance.tentative.html WPT test

This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see
whatwg/compat#6), and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug: 810162
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b
Reviewed-on: https://chromium-review.googlesource.com/1134387
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574546}

--

wpt-commits: 4981a13ac22db892707dcaac3a6678e623224268
wpt-pr: 11933

jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Jul 25, 2018

Bug 1475152 [wpt PR 11933] - Remove webkit-appearance.tentative.html …
…WPT test, a=testonly

Automatic update from web-platform-testsRemove webkit-appearance.tentative.html WPT test

This test is not a good indicator of -webkit-appearance support; it only
checks whether computed-value == applied-value for -webkit-appearance
values specified on a vanilla <div>. In reality most values of
-webkit-appearance are not of interest to other UAs (see
whatwg/compat#6), and the behavior is
different on different elements (e.g. <input>).

Since this has caused issues across different platforms on Chrome (see
bug), remove it.

Bug: 810162
Change-Id: I9d469cb624569f453978f3c56cc180eb07435b5b
Reviewed-on: https://chromium-review.googlesource.com/1134387
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574546}

--

wpt-commits: 4981a13ac22db892707dcaac3a6678e623224268
wpt-pr: 11933
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment