[Bug 21851] revert removal of text and getCueAsHTML members; address constructor changes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851

--- Comment #36 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to comment #31)
> As far as I am concerned, there are two questions of interest:
> 
> 1. Should TextTrackCue have the .text property?
> 
> 2. Should there be a TextTrackCue constructor?

Indeed. Both of these were discussed at length.

> For the first question, I don't really see why it should. Even for TTML it
> doesn't seem like a useful property to have, even if the DOM fragment
> representing the cue can be serialized. It seems far more useful to just
> expose the DOM fragment directly, no?

I don't know the current state of mind of the TTML WG on this, but last time I
looked, the way they were proposing to deal with the TextTrack API was to
convert TTML files to an intermediate format consisting of a sequence of TTML
region elements with the styled content in it, then further convert to styled
HTML document fragments for rendering. I suppose the intermediate region
elements would be in the .text content and the styled HTML fragments would be
used in getCueAsHTML().


> I'm not sure if anyone has serious
> plans to support bitmap subtitles in things like MPEG-2, but a text property
> obviously wouldn't make sense for that either.

If there's one thing I learnt in the discussions, it's that we shouldn't
address hypothetical use cases. Is anyone keen to implement a binary format on
the text track?

For example, assuming your use case is a concrete one, I would expect that
while having a bitmap to render on top of the video, there could still be a
.text attribute that would contain the textual equivalent of the bitmap for
accessibility and search purposes.

Right now we have a concrete, non-hypothetical use case where there is a spec
to expose textual cue content from MPEG files that are not WebVTT cues and
whose type is specified in TextTrack.inBandMetadataTrackDispatchType so the JS
developer is able to apply a particular cue parser to it without the browser
doing the parsing or rendering:
http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf

This is the main reason to get the .text back on something more generic than
VTTCue.


> (Most of the discussion for these changes happened while I was on leave, so
> let me know if I've missed something.)

You likely have: I've updated the summary of the discussion at
http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange#Discussion_issues
so you can review it there.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 12 August 2013 22:33:50 UTC