[whatwg] Google Feedback on the HTML5 media a11y specifications

On Tue, Feb 8, 2011 at 9:57 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> Even text can amount to a substantial amount of data. Compressed http
> delivery will help. Keeping the caption/subtitle tracks in separate
> files and only delivering those that a user really wants helps, too.
> But even then a caption file for a 2 hour video can be a fairly big
> file and we want them downloaded to the browser as quickly as
> possible, such that the video player is not held back from playback of
> the video through still downloading the captions. So, serving billions
> of caption files at as little latency as possible are both good
> arguments for keeping the format dense.
>

Without doing a lot of sampling and just looking at an SRT for an arbitrary
long movie (LOTR #1), it's 110k uncompressed, 45k deflated--that seems small
enough to not cause latency problems, as long as you're only downloading the
track you need.

Of course, I agree that it shouldn't be necessary to actually repeat
information for each cue--it makes authoring painful.

(Ouch.  This .SRT I downloaded at random uses commas for the decimal
separator.)



>  Agreed. I'm happy for the previously suggested "//" at the line start
> to be comments, or, for that matter, "#" or ";" or any other special
> character. I would prefer not to use "/*" since it implies a "*/" is
> required to end the comment. Similarly we should avoid "<!--" and
> "-->" or anything else that requires a special comment end mark and
> more than one or two characters.
>

Comment end markers aren't a major burden in HTML and CSS.  Block comments
allow easily commenting out sets of cues, midsentence comments within a cue
(translator/editor comments), and (putting aside the --> token conflict,
which will go away if the timestamp separator is changed) <!-- ... --> can
be used without adding any new escapes.  All of the other suggestions would
also need to be escaped more frequently: // happens in URLs, and # and ;
occur in plain language.

>
-- 
Glenn Maynard

Received on Wednesday, 9 February 2011 17:17:22 UTC