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

On Fri, 08 Jul 2011 11:43:25 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Fri, Jul 8, 2011 at 6:20 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Fri, 08 Jul 2011 02:51:45 +0200, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>>
>>>
>>> On 08/07/2011, at 4:55 AM, "Tab Atkins Jr." <jackalmage@gmail.com>  
>>> wrote:
>>>
>>>> On Thu, Jul 7, 2011 at 4:01 AM, Philip Jägenstedt <philipj@opera.com>
>>>> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Agreed.  The markup in the wiki is very confusing, imo, since
>>>> top-level chapters are indicated in a completely different way from
>>>> subchapters.
>>>>
>>>
>>> In my mind, the single-level subdivision  as in DVD chapters is the 80%
>>> use case. Even with many Daisy files I have only seen single level
>>> subdivision. This subdivision would also be the one that I would  
>>> visually
>>> represent in the player. I have an experiment at
>>> http://html5videoguide.net/demos/google_io/3_navigation/ with chapter
>>> markers on the timeline.
>>>
>>> So, the hierarchical navigation - as much as there is a need for it -
>>> could just stay within the cue.
>>>
>>> That seemed an appropriate solution that wouldn't need any new HTML
>>> features. I'm not wedded to this solution though.
>>
>> <nav> in WebVTT and new logic in getCueAsHTML are new features :) Given  
>> that
>> we all agree that this is a <20% use case, doing something less  
>> intrusive
>> but slightly less author-friendly seems rather reasonable...
>>
>> (As a side note, having all chapters be explicit ranges makes it easier  
>> to
>> say "play this chapter and pause when done", possibly via Media  
>> Fragments
>> #id or #chapter.)
>
> Fair enough. I'm more than happy to find something that doesn't need
> new markup. I guess it will, however, require mention of the parsing
> algorithm and a note that browsers should expose this to accessibility
> tools as a hierarchical navigation tree.

I've filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=13184 suggesting  
this.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Friday, 8 July 2011 12:29:49 UTC