W3C home > Mailing lists > Public > public-html@w3.org > July 2011

Re: ISSUE-163 navigating-tracks: Chairs Solicit Change Proposals

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 07 Jul 2011 13:01:09 +0200
To: public-html@w3.org
Message-ID: <op.vx8wv7vasr6mfa@kirk>
On Thu, 07 Jul 2011 02:03:06 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Wed, Jul 6, 2011 at 11:50 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Wed, 06 Jul 2011 14:56:12 +0200, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>>>> For WebVTT I am expecting a discussion in the WHATWG, since it's not
>>>>> specified in this WG. There is bugs that track this, see
>>>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12662 .
>>>>
>>>> OK, thanks.
>>>
>>> Do you also think this approach of putting hierarchies inside cues is
>>> simpler than building hierarchical structures through separate cues,
>>> or even with separate tracks? Or do you have a nicer way of dealing
>>> with DAISY-like requirements?
>>
>> There are a few things with
>> <http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation> that I'm not a  
>> fan of:
>>
>>  * I seems a bit random to me to represent top-level chapters as time
>> ranges, but sub-chapters as time cues.
>>  * There can be no more than two levels. Not a big deal, but all else  
>> equal
>> not having this limitation would be better.
>
>
> No, that's not true. The example at
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation#Example_markup_with_3_hierarchical_levels
> shows 3 levels and there can be an unlimited number.

OK, the second is not true. But if you're doing it like this, why bother  
with cues at all? Wouldn't it be cleaner to have *only* a root <nav> with  
possible <nav> children? Using ranges for some chapters and cues for other  
is not very appealing, IMO.

>>  * New WebVTT markup and somewhat magic transformation to HTML.
>
> Not magical - it follows the way in which the WebVTT mapping is
> already defined at
> http://www.whatwg.org/specs/web-apps/current-work/webvtt.html#webvtt-cue-text-dom-construction-rules
> , but only adds one element to create the hierarchy.

Not magical, but mapping it to <ul><li> is rather odd IMO. <section><h1>  
would seems more natural, but I think no additional mapping at all would  
be simpler.

>> Something that could be trivially parsed by both web browsers and  
>> scripts
>> would be nicer, IMO. If you consider that a chapter is a range, you can
>> build a chapter tree by just looking at which chapters are contained  
>> within
>> another. Example:
>>
>> WEBVTT
>>
>> 00:00:00.000 --> 00:00:10.700
>> Title Slide
>>
>> 00:00:10.700 --> 00:00:47.600
>> Introduction by Naomi Black
>>
>> 00:00:47.600 --> 00:07:37.900
>> Talk on WebVTT
>>
>> 00:00:47.600 --> 00:01:50.100
>> Impact of Captions on the Web
>>
>> 00:01:50.100 --> 00:03:33.000
>> Requirements of a Video text format
>>
>> 00:03:33.000 --> 00:04:57.766
>> Simple WebVTT file
>>
>> 00:04:57.766 --> 00:06:16.666
>> Styled WebVTT file
>>
>> 00:06:16.666 --> 00:07:37.900
>> Internationalized WebVTT file
>>
>> From this you could programmatically find the chapter tree.
>
> That is possible and is also something I considered at
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation#3._Single-track.2C_multiple_cues
> . The parsing of this and creation of the hierarchical navigation tree
> would need to deal with all kinds of possible markup errors, which is
> why I find it not so simple to use by authors.
>
> After today's media accessibility task force call, I've added header
> markup to that example, which more explicitly states the hierarchical
> level. That may help with some of the parsing and could even
> auto-correct some markup errors. It could also be more lax about
> overlapping time regions and basically just care about start times.

It would seem to make parsing more complicated, as there can be  
conflicting information about the depth.

Parsing of what I suggested above seems very straight-forward:

"root chapter" = [empty tree]
for each cue in document order:
   create "new chapter" with name sourced from the cue text
   let "parent chapter" be the last chapter in "root chapter" (depth first  
search) which start before "new chapter" and ends after "new chapter"
   if a "parent chapter" was found:
     append "new chapter" to "parent chapter"
   else:
     append "new chapter" to "root chapter"

I don't think it needs to be more complicated. If people make overlapping  
chapters, they'll just not get a parent-child relationship and they'll  
hopefully notice. (Validators should also warn about overlapping chapters.)

>> It also has the
>> benefit that it's possible to use this as a visible track for debugging
>> purposes, as all currently active chapters would be visible.
>
> How are you suggesting to make chapter tracks visible? I've got an
> experiment at  
> http://www.html5videoguide.net/demos/google_io/3_navigation/
> and am finding it hard enough to make one level of navigation visible
> in the transport bar (the list on the right would not be a default
> rendering). I have no good solutions for making multiple hierarchical
> levels visible.

I'm thinking that at the top of the bottom there's a thin black bar which  
shows the chapter hierarchy of where you are, as such:

Introduction by Naomi Black > Simple WebVTT file

Depending on the power of the CSS pseudo classes, this may or may not  
require scripting.

>> With some
>> script+CSS I suppose it might even be a useful technique in production.  
>> The
>> only downside that I can see is that it's a bit tricky to author.
>
> Yes, I found the ul/li way of authoring more immediately readable.
> Providing a non-hierarchical list of cues and making them hierarchical
> just through analysis of time markers is asking for a rather complex
> algorithm, which is why I tried to avoid it.

Sure, each approach has pros and cons. However, just using plain cues  
certainly appeals more to my aesthetics and seems simpler to handle both  
natively in the browser and for scripts.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Thursday, 7 July 2011 11:01:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:26 UTC