[Webkit-unassigned] [Bug 157635] REGRESSION (STP 4): Unable to target pseudo element webkit-media-controls

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 13 15:39:51 PDT 2016


--- Comment #11 from Jer Noble <jer.noble at apple.com> ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > I think you have some other, better supported techniques available for this
> > scenario. Your in-page CSS could hide (visibility:hidden) the video element
> > entirely (or cover it with a poster <img>, and only un-hide it once your
> > script clears the 'controls' attribute.  The <video> poster image attribute
> > takes time to download, decode, and paint, so this wouldn't introduce any
> > additional flash that wasn't there already.
> I just want a style based way to say: "don't show controls", which
> apparently won't be possible anymore. I'm also not concerned about a FOUC or
> reflow, i'm specifically concerned about 50 video frames showing a
> controlbar on mobile device in nigeria that takes 70 seconds to load the
> entire page. Which would result in one video after the other then loads the
> JS player. I want to eliminate that temporary moment of controls, after
> which the user has to reset his expectations with a new set of controls. And
> I need to keep my DOM clean of non-semantic <img> elements.

I think I understand; you're more concerned with the look-and-feel of the controls changing half-way through the page-load.

I mean, I'm not really trying to tell you how to redesign your page to work around this issue, but it still seems like there are options. Just off the top of my head, you could do something like this to solve the "javascript disabled" case:

document.write('<video src="foo"></video>');
<video controls src="foo"></video>

For the "external users who don't have my javascript player library", the script tag would have to look something like:

document.write('<video src="foo" ' + (hasMyJSLibrary() ? '' : 'controls')  + '></video>');

> I guess the only other alternative that might get me what i want is to use a
> top loading synchronous JS fragment, but i don't think our performance team
> will like that. ..

Well, if you can articulate this use case to the CSS WG (or some representative thereof), the best way to do this moving forward is to convince the WG to add explicit and standardized support for showing or hiding the controls through CSS. Then WebKit can expose just that without pages mucking around with the internals of the controls.

> I know, our requirements are somewhat crazy :)

Crazy requirements make for the most interesting bugs. :)

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160513/e3d8f670/attachment.html>

More information about the webkit-unassigned mailing list