search

w3c / webvtt

WebVTT Standard
https://w3c.github.io/webvtt/
Other
103 stars 40 forks source link

'outline' property exposes implementation differences #235

Open zcorpan opened 8 years ago

zcorpan commented 8 years ago

https://zcorpan.github.io/live-webvtt-viewer/#style=%3A%3Acue+%7B%0Aoutline%3A500px+solid+red%0A%7D

We should consider whether we want 'outline' to be in the list of supported properties. What's the use case?

zcorpan commented 8 years ago

cc @eric-carlson @foolip @rickeyre

foolip commented 8 years ago

On which browsers does this give different results? Screenshots would be nice :)

zcorpan commented 8 years ago

Opera (Presto):

The outline bleeds outside of the video.

Opera (Blink):

The outline covers the full width of the video, but is clipped at the cue's edges vertically.

Safari:

The outline covers almost the full width of the video, and is clipped a bit outside the cue's edges vertically.
foolip commented 8 years ago

@eric-carlson @jernoble, is WebKit adding some padding to the cue background box, or something?

zcorpan commented 8 years ago

Gecko doesn't support styling yet AFAICT.

I suppose we can ignore Presto. The difference between Safari and Blink can be explained by Safari's default style not matching the spec -- it has a block background with rounded corners and padding, instead of an inline background box with background:rgba(0,0,0,0.8) as the spec says.

Still, I'm not certain that the spec's rendering rules, if implemented literally, would result in any of the behaviors we see here. I would have expected the outline to be clipped at the video element's edges, since that's the viewport for WebVTT.

zcorpan commented 8 years ago

Compare with http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3737 (outline in an iframe)

foolip commented 8 years ago

Yeah, that is pretty odd. Doesn't border have any of these problems?

zcorpan commented 8 years ago

'border' is not in the list of supported properties (it affects layout).

foolip commented 8 years ago

Oh, right. How about background, then? It seems like the root cause here is deliberately different styles on the background box, so we should get that aligned somehow.

zcorpan commented 8 years ago

Yes, though it seems I can't select the root element in Safari to change the background; only ::cue(c) etc works to select children. But yeah, we should decide between block and inline for the background box, and if it should be possible to switch to the other with CSS without having to use a <c> in every cue to get an inline background...

silviapfeiffer commented 8 years ago

The 5px gap in Safari likely comes from the "edge margin" which we introduced to cope with overscan. So, I think what Safari does is correct with the background - just not with the cue itself. ;-) And what blink does is correct, too, because the "edge margin" is browser defined.

zcorpan commented 8 years ago

Neither of them is correct -- the video viewport is not that narrow vertically. The outline should fill the video viewport per spec.

silviapfeiffer commented 8 years ago

BTW: the use case is compatibility with CEA-708

eric-carlson commented 8 years ago

Apple's ports of WebKit take the system level caption user preferences into account (on OS X, System Preferences -> Accessibility -> Captions).

foolip commented 8 years ago

As of recently there is some of this in Blink as well, integrating with Android: https://code.google.com/p/chromium/issues/detail?id=457850 https://developer.android.com/about/versions/kitkat.html#44-accessibility

However, it doesn't look like Android has any settings for window padding or rounded border radius, is that what iOS has that's at play here?

One problem is that the spec doesn't have any notion of a bounding box of all the text boxes of a cue that could be styled in the absence of regions. What does that box correspond to in WebKit? I can't find anything that seems to fiddle with padding or border radius, but it must be there somewhere :)

silviapfeiffer commented 8 years ago

The "cue box" is supposed to be the bounding box of all the text boxes.

zcorpan commented 8 years ago

Hmm, I noticed that the spec is probably wrong in that 'outline' applies to the cue box rather than the background box. Presto outlines the cue box (notice there is white on the sides of the text) but WebKit and Blink outline the background box.

silviapfeiffer commented 8 years ago

CEA708 puts the outline on the bounding box of all the text boxes, not on a full right-to-left covering box. Since it's implementing the same use case, 'cue box' seems more correct that 'background box' to me.

foolip commented 8 years ago

But WebVTT doesn't have a box for the bounding box of all the text boxes, the cue box is whatever size is specified by the size setting, subject to clamping.

foolip commented 8 years ago

I suppose that as part of https://github.com/w3c/webvtt/issues/249 we could add such a box, though.

silviapfeiffer commented 8 years ago

That's what I was hoping for. :-)