Intent To Deprecate And Remove: media player webkit- pseudo IDs

105 views
Skip to first unread message

libe...@chromium.org

unread,
Jun 22, 2015, 5:00:27 PM6/22/15
to blin...@chromium.org, Renganathan Ramamoorthy

Primary eng (and PM) emails

liberato at chromium dot org (eng) renganathan at chromium dot org (pm)


Summary

Remove unsupported -webkit pseudo IDs from the media player, replace with -internal.


Motivation

These pseudo IDs interact with elements that are strongly managed by custom C++ code.  There is currently no guarantee that their behavior will not change.


As part of our new media playback UI, we would like to remove access to these pseudo IDs, to prevent use of this unsupported features.


Compatibility Risk

The pseudo IDs aren’t currently officially supported, though they have been present since 2013.


Alternative implementation suggestion for web developers

HTMLMediaElement provides better, and supported, methods for providing customized playback UI.


Usage information from UseCounter

We have not instrumented this, because it is currently unsupported.


OWP launch tracking bug

https://crbug.com/487344 (new media playback UI)


Entry on the feature dashboard

N/A - feature is currently unsupported.


Requesting approval to remove too?

Yes.

Chris Harrelson

unread,
Jun 22, 2015, 11:57:48 PM6/22/15
to libe...@chromium.org, blink-dev, Renganathan Ramamoorthy
Hi,

Please list the pseudo elements here for completeness. Also, do any of them happen to have user counters?

Secondly, am I correct that this means that there will no longer be any web-exposed pseudo elements for media player styling? Is there evidence that this will break legitimate use cases?

Thanks,
Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Rogers

unread,
Jun 23, 2015, 2:13:10 PM6/23/15
to Chris Harrelson, libe...@chromium.org, blink-dev, Renganathan Ramamoorthy
Can you explain what "The pseudo IDs aren’t currently officially supported" means? These pseudo ids seem to be used in the wild.

Frank Liberato

unread,
Jun 23, 2015, 2:53:44 PM6/23/15
to Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
Thanks for the feedback.

Chris: Here is the complete list (from WebKit/Source/core/html/shadow/MediaControlElements.cpp):

-webkit-media-controls-panel
-webkit-media-controls-enclosure
-webkit-media-controls-overlay-enclosure
-webkit-media-controls-mute-button
-webkit-media-controls-play-button
-webkit-media-controls-overlay-play-button
-webkit-media-controls-toggle-closed-captions-button
-webkit-media-controls-timeline
-webkit-media-controls-volume-slider
-webkit-media-controls-fullscreen-button
-webkit-media-controls-time-remaining-display
-webkit-media-controls-current-time-display

I'll follow up with any existing usage counters, if any.

Philip: I meant that we don't make any guarantees about what these pseudo ids will do if one twiddles with them, though there is some use of them.  This thread on our new media UI mentions that this might be good time to deprecate.  It seems like this has come up before, here (2014), which i somehow missed in my previous search.

I suspect that we'll land exactly where the 2014 thread did -- we need the usage counts.

thanks
-fl

Philip Jägenstedt

unread,
Jun 24, 2015, 6:14:00 PM6/24/15
to Frank Liberato, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
I've searched for the string "webkit-media-controls" in the 20150101 httparchive data. That's 380473 pages, and 414 (0.001%) pages had the string in one or more places. These are the number of hits for each:

    361 -webkit-media-controls
    156 -webkit-media-controls-seek-forward-button (not in Blink)
    156 -webkit-media-controls-seek-back-button (not in Blink)
     76 -webkit-media-controls-enclosure
     24 -webkit-media-controls-panel
     13 -webkit-media-controls-play-button
     10 -webkit-media-controls-fullscreen-button
      9 -webkit-media-controls-timeline
      8 -webkit-media-controls-volume-slider
      7 -webkit-media-controls-time-remaining-display
      7 -webkit-media-controls-mute-button
      5 -webkit-media-controls-overlay-play-button
      4 -webkit-media-controls-current-time-display
      3 -webkit-media-controls-toggle-closed-captions-button
      1 -webkit-media-controls-wireless-playback-picker-button (not in Blink)
      1 -webkit-media-controls-timeline-container (not in Blink)
      1 -webkit-media-controls-status-display (not in Blink)

-webkit-media-controls-overlay-enclosure is the only one not found at all.

It looks the most common usage is to hide all or parts of the controls, for example this from http://www.viewbix.com/layouts/html5/65/common.css:
video::-webkit-media-controls-overlay-play-button { display:none !important; } /* So video tag will never display its own overlay play button on Android */

There's also some pretty involved tweaking going on, for example https://transfer.sh/styles/main.css makes changes that are not going to be robust against changes to the controls.

I've put the resources with matches in https://gist.github.com/foolip/cac5f3d3d29012aaf3a2 if anyone wants to take a look.

I think that these pseudo-elements definitely should not be web-exposed, and I don't think there's much chance of standardizing something similar since that would require the overall structure of the controls in all browsers to be pretty similar. Rolling your own controls is more work, but it's the only reliable way to get the same look-and-feel cross-browser.

From my previous intent to remove these pseudo-elements there's http://css-tricks.com/custom-controls-in-html5-video-full-screen/ which combines ::-webkit-media-controls { display: none; } with a bug in our fullscreen implementation, namely that z-index on non-fullscreen elements can allow them to appear above the fullscreen element. It would probably be best to fix those two problems together, so that one gets exactly one set of controls, not zero or two depending on the order these are fixed.

Based on the seemingly low usage, I say LGTM to making everything except -webkit-media-controls hidden from web content, but being prepared to revert fully or partially if it turns out some of the usage in the wild is to work around other bugs we're not aware of yet.

Frank Liberato

unread,
Jun 25, 2015, 5:13:34 PM6/25/15
to Philip Jägenstedt, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
that's a neat trick.  thanks for providing this information!

while this discussion is ongoing, i'll see how badly our tests break if we make this change.  there are a fair number of them that contain "-webkit".

thanks
-fl

Elliott Sprehn

unread,
Jun 25, 2015, 6:03:10 PM6/25/15
to Frank Liberato, Philip Jägenstedt, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
On Thu, Jun 25, 2015 at 4:13 PM, 'Frank Liberato' via blink-dev <blin...@chromium.org> wrote:
that's a neat trick.  thanks for providing this information!

while this discussion is ongoing, i'll see how badly our tests break if we make this change.  there are a fair number of them that contain "-webkit".

We use -webkit for all kinds of things unrelated to media. :)

I think we should just go ahead and remove these media controls ones, authors can use the controls attribute, and libraries that provide their own controls.

- E

PhistucK

unread,
Jun 25, 2015, 6:15:38 PM6/25/15
to Frank Liberato, blink-dev, Renganathan Ramamoorthy
While they are "unsupported", you should still add this to the feature dashboard, in my opinion, as there are some tutorials that suggest using these and it will be nice towards developers to announce officially that they are going away.


PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Frank Liberato

unread,
Jun 25, 2015, 6:17:14 PM6/25/15
to Elliott Sprehn, Philip Jägenstedt, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
heh, indeed.  i typed the whole thing into code search, i promise :)

it's about 20 tests.

thanks
-fl

Philip Jägenstedt

unread,
Jun 29, 2015, 8:30:20 AM6/29/15
to Frank Liberato, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
I should also say that if this intent gets its LGTMs, make very, very sure that the new -internal pseudo elements are actually internal, as I don't think that will actually be the case without some new code to hide them from the outside world.

PhistucK

unread,
Jun 29, 2015, 8:47:29 AM6/29/15
to Philip Jägenstedt, Frank Liberato, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
I think I once saw that -internal- is a special, reserved prefix that sets this behavior.


PhistucK

Philip Jägenstedt

unread,
Jun 29, 2015, 8:55:45 AM6/29/15
to PhistucK, Frank Liberato, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
It isn't in all contexts, unfortunately, and the mistake has already been made in one case:

PhistucK

unread,
Jun 29, 2015, 8:57:42 AM6/29/15
to Philip Jägenstedt, Frank Liberato, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
Ouch. :(


PhistucK

Frank Liberato

unread,
Jun 29, 2015, 10:00:36 AM6/29/15
to PhistucK, Philip Jägenstedt, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
thanks for point this out.  and +1 :(

-fl

Dimitri Glazkov

unread,
Jul 1, 2015, 2:00:59 PM7/1/15
to Frank Liberato, PhistucK, Philip Jägenstedt, Philip Rogers, Chris Harrelson, blink-dev, Renganathan Ramamoorthy
LGTM to try to remove/replace with -internal-. Be prepared to revert.

:DG<

Chris Harrelson

unread,
Jul 1, 2015, 3:50:43 PM7/1/15
to Dimitri Glazkov, Frank Liberato, PhistucK, Philip Jägenstedt, Philip Rogers, blink-dev, Renganathan Ramamoorthy
LGTM

On Wed, Jul 1, 2015 at 11:00 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:
LGTM to try to remove/replace with -internal-. Be prepared to revert.

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Reply all
Reply to author
Forward
0 new messages