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

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

--- Comment #3 from Glenn Adams <glenn@skynav.com> ---
(In reply to comment #2)
> These members don't make sense for all formats.
> 
> We could have a common interface that inherits from TextTrackCue and is
> inherited by WebVTT, though, if it's so common that duplicating the two
> members in multiple interfaces is considered bad. But that seems like
> overkill.
> 
> (In reply to comment #0)
> > 
> > (1) it is no longer possible to create or add a text track cue to a text
> > track by programmatic means (JS) when not using VTT;
> 
> That's not true; you can use whatever API the format provides. If your UA
> supports DVD cues, for example, there could be a .setImage() method that
> takes a BitmapImage. It's up to the cue's spec, just like WebVTT exposes the
> attributes mentioned in this bug.

As presently defined in HTML5.0, it is not necessary for an application to know
what interface is implemented by a cue object beyond TextTrackCue if it's only
goal is to obtain a text or an html representation of the cue.

While it is true that the application would need to either (1) have a priori
knowledge about what type of content is delivered with a given text track or
(2) sniff the content based on what (if anything) is returned when evaluating
the text IDL attribute, as presently defined, it can at least assume that a
string or null is returned, though the current 5.0 prose doesn't really provide
sufficient detail about the return value when the user agent doesn't know how
to constitute a text value.

The present language, in HTML 5.0 section 4.8.10.12.5 states:

"The text attribute, on getting, must return the raw text track cue text of the
text track cue that the TextTrackCue object represents. On setting, the text
track cue text must be set to the new value.

The getCueAsHTML() method must convert the text track cue text to a
DocumentFragment for the script's document of the entry script, using the
appropriate rules for doing so. For example, for WebVTT, those rules are the
WebVTT cue text parsing rules and the WebVTT cue text DOM construction rules.
[WEBVTT]"

This prose is sufficiently general to support the continue presence of these
two members regardless the text track format.

I would point out that:

(1) a TextTrack, by mere use of the qualifier "Text", leads one to believe that
a text representation for its content is reasonable, or at least possible;

(2) in the case of text tracks that refer to binary data, it is straightforward
to define that the text IDL attribute evaluates to null or to a text
representation of the binary data, e.g., a BASE64 encoding; this has indeed
been done with a CableLabs specification [1] that provides access to MPEG-2
program specific information (PSI) via TextTrack and TextTrackCue;

[1] http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf

(3) in the case of caption formats that use image data, such as DVD, it is
straightforward to define that text returns null or returns an alternate text
or description text if available; it could also return a URL to a built-in
protocol handler that permits dereferencing the image from an image cache;

The point is, there is always a reasonable defined value for the text
attribute: either null or some string of useful value.

> 
> 
> > (2) it is no longer possible to access a text form of the cue by
> > programmatic means (JS) when not using VTT;
> > (3) it is no longer possible to access an HTML form of the cue by
> > programmatic means (JS) when not using VTT;
> 
> Again, for formats where doing so makes sense, the format's API can just
> expose these attributes and methods.

The problem with the approach entailed by moving these two members out of
TextTrackCue is that it doesn't recognize that the primary intent of these
interfaces is to expose text and that all referenced text track formats can
define a reasonable text expression (even if null in some cases where no text
representation whatsoever makes sense).

The same can be said for the getCueAsHTML member. Even DVD sub-picture images
could be represented in HTML by merely returning an img element that employs a
UA specific internal URL value that the UA knows how to dereference (since it
created it).

Overall, I'd say the proposed change to remove these members is a case of
allowing the tail to wag the dog.

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

Received on Saturday, 27 April 2013 03:41:32 UTC