Intent to Implement and Ship: -webkit-appearance:none for METER and PROGRESS elements

[TAMURA, Kent]

Contact emails

tk...@chromium.org

Spec

https://drafts.csswg.org/css-ui-4/#appearance-switching

Summary

Implement and ship the standard appearance:none behavior for METER and PROGRESS elements as -webkit-appearance:none. It enables web authors to style METER and PROGRESS with pure CSS.

In short words, we'll render http://www.am530.de/lab/html5/meter.php perfectly.

Motivation

Web authors want to replace these widget rendering completely with keeping element semantics.

Interoperability and Compatibility Risk

This is a standard behavior, but other major browsers don't implement it. prefixed-appearance:none has no effect.

If a page has <meter style="-webkit-appearance:none"></meter> without any additional style, the METER element disappears.

This affects 0.0001% of page views in the METER case. https://www.chromestatus.com/metrics/feature/timeline/popularity/994

We don't have the data for PROGRESS. It must be much smaller than 0.09%, which is the whole PROGRESS usage https://www.chromestatus.com/metrics/feature/timeline/popularity/484 .

Ongoing technical constraints

The implementation is a bit tricky. We can't update UA Shadow DOM structure in response to -webkit-appearance value. It will use custom style callbacks.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/602928

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5668635896971264

Requesting approval to ship?

Yes.

--

TAMURA Kent
Software Engineer, Google

[PhistucK]

Why not appearance: none?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[TAMURA, Kent]

I think we're not ready to ship the 'appearance' property yet.  This is the first step towards unprefxing -webkit-appearance.

1. Make each of elements with native rendering switchable to CSS with -webkit-appearance:none.

2. Implement -webkit-appearance:auto

3. Deprecate and remove -webkit-appearance values other than 'none' and 'auto'.

4. Ship appearance:auto/none.

[Rick Byers]

In general I don't think we want to be "adding features" to prefixed APIs, but I don't think that's what's really going on here.  We already have the -webkit-appearance:none feature and it affects all form elements, but is ignored for <meter> and <progress> due to an implementation detail, right?

If that's the case I don't think this really deserves an intent, it's just a bugfix of -webkit-appearance (it's not like we need to update MDN docs to say that -webkit-appearance now works on more elements).

Nevertheless (in case others disagree), LGTM1 to ship

On Wed, Apr 13, 2016 at 3:07 AM, TAMURA, Kent <tk...@chromium.org> wrote:

I think we're not ready to ship the 'appearance' property yet.  This is the first step towards unprefxing -webkit-appearance.

1. Make each of elements with native rendering switchable to CSS with -webkit-appearance:none.

2. Implement -webkit-appearance:auto

3. Deprecate and remove -webkit-appearance values other than 'none' and 'auto'.

4. Ship appearance:auto/none.

This plan sounds OK to me.  Though this may be slightly better (avoids adding properties to prefixed APIs and also ships appearance sooner):

1.  Make each of elements with native rendering switchable to CSS with -webkit-appearance:none.

2.  Ship appearance:auto/none.  (with separate CSS parsing form -webkit-appearance but all the same backing logic)

3.  Deprecate and remove -webkit-appearance values other than 'none' and 'auto' (though note that Edge apparently supports "button" and "textfield" so those may be required for compat and then should be added to the spec).

4.  Make -webkit-appearance a strict alias of appearance (removing redundant parsing logic)

[Elliott Sprehn]

Using custom style callbacks is bad, I'd rather we didn't use more of them. If we want to implement this I'd suggest we wait until we have @apply, then make appearance: none define some -internal CSS variable that resets the style and display: none's the guts of the element. Hacks using customStyleForLayoutObject end up being technical debt for many years.

[TAMURA, Kent]

On Thu, Apr 14, 2016 at 10:03 AM, Rick Byers <rby...@chromium.org> wrote:

In general I don't think we want to be "adding features" to prefixed APIs, but I don't think that's what's really going on here.  We already have the -webkit-appearance:none feature and it affects all form elements, but is ignored for <meter> and <progress> due to an implementation detail, right?

That's right for <meter> and <progress>.  But I'm not sure if the following elements with -webkit-appearance:none have expected behavior now.  We should discuss it on www-style.

* input[type=number]

-webkit-appearance:none doesn't remove a spin button. Should we remove it?

* input[type=date/datetime-local/month/time/week]

 -webkit-appearance:none doesn't remove a spin button, clear button, and picker indicator button.  Should we remove them?

* input[type=range]

 -webkit-appearance:none doesn't disable UA rendering for a slider thumb.  Should we disable it?

* input[type=color]

  webkit-appearance:none doesn't remove a selected color box.  Should we remove it?

* input[type=submit/reset/button]

  Text labels in these buttons are not INPUT element content.  Should we remove them if appearance:none?

  

 

If that's the case I don't think this really deserves an intent, it's just a bugfix of -webkit-appearance (it's not like we need to update MDN docs to say that -webkit-appearance now works on more elements).

Nevertheless (in case others disagree), LGTM1 to ship

On Wed, Apr 13, 2016 at 3:07 AM, TAMURA, Kent <tk...@chromium.org> wrote:

I think we're not ready to ship the 'appearance' property yet.  This is the first step towards unprefxing -webkit-appearance.

1. Make each of elements with native rendering switchable to CSS with -webkit-appearance:none.

2. Implement -webkit-appearance:auto

3. Deprecate and remove -webkit-appearance values other than 'none' and 'auto'.

4. Ship appearance:auto/none.

This plan sounds OK to me.  Though this may be slightly better (avoids adding properties to prefixed APIs and also ships appearance sooner):

1.  Make each of elements with native rendering switchable to CSS with -webkit-appearance:none.

2.  Ship appearance:auto/none.  (with separate CSS parsing form -webkit-appearance but all the same backing logic)

3.  Deprecate and remove -webkit-appearance values other than 'none' and 'auto' (though note that Edge apparently supports "button" and "textfield" so those may be required for compat and then should be added to the spec).

4.  Make -webkit-appearance a strict alias of appearance (removing redundant parsing logic)

Thank you for the advice!

On Thu, Apr 14, 2016 at 12:06 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Using custom style callbacks is bad, I'd rather we didn't use more of them. If we want to implement this I'd suggest we wait until we have @apply, then make appearance: none define some -internal CSS variable that resets the style and display: none's the guts of the element. Hacks using customStyleForLayoutObject end up being technical debt for many years.

That's an interesting idea.  It seems we already have @apply implementation.

I guess adding internal-only CSS variable infrastructure needs non-trivial code, and we still need some kind of hook to inject an internal-only variable.  I'm not sure it's better than custom style callbacks.

[Rick Byers]

On Thu, Apr 14, 2016 at 12:54 AM, TAMURA, Kent <tk...@chromium.org> wrote:

On Thu, Apr 14, 2016 at 10:03 AM, Rick Byers <rby...@chromium.org> wrote:

In general I don't think we want to be "adding features" to prefixed APIs, but I don't think that's what's really going on here.  We already have the -webkit-appearance:none feature and it affects all form elements, but is ignored for <meter> and <progress> due to an implementation detail, right?

That's right for <meter> and <progress>.  But I'm not sure if the following elements with -webkit-appearance:none have expected behavior now.  We should discuss it on www-style.

* input[type=number]

-webkit-appearance:none doesn't remove a spin button. Should we remove it?

* input[type=date/datetime-local/month/time/week]

 -webkit-appearance:none doesn't remove a spin button, clear button, and picker indicator button.  Should we remove them?

* input[type=range]

 -webkit-appearance:none doesn't disable UA rendering for a slider thumb.  Should we disable it?

* input[type=color]

  webkit-appearance:none doesn't remove a selected color box.  Should we remove it?

* input[type=submit/reset/button]

  Text labels in these buttons are not INPUT element content.  Should we remove them if appearance:none?

I'd assume that the answer in all cases is yes. The point of appearance:none is to let the developer completely style the control themselves from CSS, in which case I think there really can't be any built-in rendering (unless I'm missing something).

[TAMURA, Kent]

Florian, who is the editor of css-ui-4, and I met last week, and discussed this.  I proceed this intent as is, and will post our thoughts on other form controls to www-style.

[Elliott Sprehn]

I'd be great to review the patches for this. :) The form controls have a lot of technical debt from the style callbacks, I'm still concerned this is adding more.

[Rick Byers]

Yep, I think you should just proceed with this as a bug-fix (with appropriate codereview from the architecture team).  But if anything changes to make you think there is non-trivial compat risk, please circle back here.

[TAMURA, Kent]

I found we needed to unship ::-webkit-progress-* pseudo elements to implement this behavior for PROGRESS element, and we don't have use counters for them.  So I drop PROGRESS element from this intent, and will collect data and send new intent for PROGRESS.