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

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

--- Comment #19 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
(In reply to comment #11)
> 
> It is possible to have an implementation in a UA that parses timed tracks
> and exposes cues, but the UA has no implementation for how to further parse
> the cue content.

This has nothing to do with parsing the cue content. It's about parsing the
cues. In an implementation such as you describe, you'd still have a new Cue
interface, for whatever text track format you're dealing with.


> It would, of course, be better to have a dedicated API for TTMLCue or
> SCC708Cue, but if there is no further data than just the cue content,
> TextTrackCue is entirely sufficient if it has a .content (or .text) API.

That's really poor API design.

If you have a potential hierarchy of interfaces, and some leafs of this
hierarchy would only have one or two APIs, you don't therefore not bother to
create the leaves and instead put the APIs on the abstract common ancestor. You
only put things on the abstract common ancestor if they apply to _every_
descendant interface.

There's no harm in having a "TTMLCue" interface that has a .text API. Or
alternatively, in having an interface that inherits from the abstract
TextTrackCue and that is inherited by WebVTTCue, which can then be used for
those formats where the UA essentially just has a subset of WebVTT (though that
would be inferior to having separate leaf interfaces, since you'd want each one
to have its own rendering rules, and it'd be confusing to have a single
interface used for multiple different rendering rules).

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

Received on Tuesday, 28 May 2013 21:07:04 UTC