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: Fri, 08 Jul 2011 10:20:17 +0200
To: public-html@w3.org
Message-ID: <op.vyaj33qlsr6mfa@kirk>
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.)

Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 8 July 2011 08:20:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:15 UTC