This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dev.w3.org/html5/webvtt/#extension-of-the-texttrack-interface-for-region-support Strictly speaking, the spec is redefining the TextTrack interface, which is clearly no intended. Use "partial interface".
Good catch, thanks.
The indentation is a bit weird as well, might want to fix that at the same time.
To piggy-back some more, the indentation in http://dev.w3.org/html5/webvtt/#vttcue-interface is even stranger.
*** Bug 22961 has been marked as a duplicate of this bug. ***
Um, isn't it bad to expose these VTT features on all TextTracks? Even the non-VTT ones? It seems like the better solution would be to have a subclass of TextTrack for VTT text tracks. Am I missing something?
(In reply to Ian 'Hixie' Hickson from comment #5) > Um, isn't it bad to expose these VTT features on all TextTracks? Even the > non-VTT ones? It seems like the better solution would be to have a subclass > of TextTrack for VTT text tracks. Am I missing something? Maybe. However, rendering regions are a common way of restricting the rendering of a caption track to a certain area on the video viewport. We're also about to have WebVTT always render into a region - if none is given, there is a default region that covers the whole viewport. And we want to allow users to create regions by script. So, I don't think it's worth restricting this to VTT only.
(In reply to Silvia Pfeiffer from comment #6) > (In reply to Ian 'Hixie' Hickson from comment #5) > > Um, isn't it bad to expose these VTT features on all TextTracks? Even the > > non-VTT ones? It seems like the better solution would be to have a subclass > > of TextTrack for VTT text tracks. Am I missing something? > > Maybe. However, rendering regions are a common way of restricting the > rendering of a caption track to a certain area on the video viewport. We're > also about to have WebVTT always render into a region - if none is given, > there is a default region that covers the whole viewport. And we want to > allow users to create regions by script. So, I don't think it's worth > restricting this to VTT only. I don't know, I think it's unlikely that the API added for the VTT Regions concept is going to applicable to other track types as well. We've already been talking about interactions between the VTT layout algorithm and VTT Regions like having them grow to contain their content and possibly overlap avoidance. I'd be happy with making VTT Regions tightly bound to VTT, but if we go the other route we should make sure that the regions concept is really orthogonal to VTT, and not have "VTT" in the name, a rendering-specific member like "scroll", etc. This wasn't the topic for which I opened this bug, I'll try to remember opening another bug before closing this one.
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24380
IDL syntax fixed in https://github.com/w3c/webvtt/pull/12