W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2012

[Bug 15606] <track> clarification of TextTrackCue.getCueAsHTML() conversion rules

From: <bugzilla@jessica.w3.org>
Date: Wed, 08 Feb 2012 23:46:38 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RvHDi-00084j-8Q@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15606

--- Comment #7 from Glenn Adams <glenn@skynav.com> 2012-02-08 23:46:37 UTC ---
(In reply to comment #6)
> > that's a good point (about not exposing a possible text track if the format is
> > not known or supported); perhaps there should be normative language to that
> > effect?
> 
> There is. That's what's I cited for you earlier.
> 
> You can't get to the situation you are describing.

ok, based on one reading of 4.8.10.12.2 (in-band):

"When a media resource contains data that the user agent recognises and
supports as being equivalent to a text track, the user agent runs the steps to
expose a media-resource-specific text track with the relevant data, as
follows."

and of 4.8.10.12.3 (out-of-band):

"If the fetching algorithm fails for any reason ... or if the sniffed type of
the resource is not a supported text track format, then queue a task to first
change the text track readiness state to failed to load..."

i can agree that no spec change is necessary; however, it would be a little
more clear if 4.8.10.12.2 had an "otherwise... do not expose ... a
media-resource-specific text track" as the the alternate to "when ..."

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 8 February 2012 23:46:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 February 2012 23:46:43 GMT