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. ericReceived on Thursday, 3 March 2011 15:44:28 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:33 UTC