- From: Eric Carlson <eric.carlson@apple.com>
- Date: Thu, 3 Mar 2011 07:43:52 -0800
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
On Mar 2, 2011, at 2:04 PM, Silvia Pfeiffer wrote: > > So, the question is what we expect people to do with the alternatives. > If, as you say, the list of resources in the <track> element would be > gone through using the source selection algorithm and the first one > that that browser understands will be displayed, then what is the > author of these captions to do? > > If I am the author and I create a WebVTT file and all browsers support > this format, why should I also author a TTML file? Unless that would > give me something in addition to the WebVTT, I wouldn't. Thus, the > TTML would necessarily be able to provide "higher quality" of some > sort to make me want to use it instead of the baseline WebVTT. The > same with any other format. And in addition, I'd have to make sure to > provide the TTML ahead of the WebVTT in the markup, since otherwise no > browser will ever get to it (this is always under the assumption that > everyone will in fact implement WebVTT support). > Yes, this is exactly the situation we have today with browsers that support more than one media container format. > The "damage" I am talking about is that of requiring people to have to > author more than one format. But you are right - this is not dependent > on the markup, this is a general problem of having more than one > format available as a solution - it's the same for the img element, so > ignore this comment. > > The question still stands: is the choice sufficiently possible just > through the formats that the browser supports in the analogous way > that the <img> element supports both png and jpg? > If all browsers end up supporting a common format, and if that format meets all captioning needs, there won't be a *need* to have <source> for text tracks. However, if we allow the inclusion of audio and video through <track> we will *require* <source> to deal with alternate encodings and it will be silly to forbid the use of <source> for text tracks. eric
Received on Thursday, 3 March 2011 15:44:28 UTC