'outline' property exposes implementation differences

[zcorpan]

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]

cc @eric-carlson @foolip @RickEyre

[foolip]

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

[zcorpan]

Opera (Presto):

Opera (Blink):

Safari:

[foolip]

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

[zcorpan]

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]

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

[foolip]

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

[zcorpan]

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

[foolip]

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]

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]

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]

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

[silviapfeiffer]

BTW: the use case is compatibility with CEA-708

[eric-carlson]

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

[foolip]

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]

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

[zcorpan]

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]

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]

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]

I suppose that as part of #249 we could add such a box, though.

[silviapfeiffer]

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