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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 6 Jul 2011 22:56:12 +1000
Message-ID: <CAHp8n2kDZvj77h91xBPK7VzU==7QK+m8wie0kVMGLaFn1v_EeQ@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-html@w3.org
On Wed, Jul 6, 2011 at 9:50 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 06 Jul 2011 12:47:35 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Wed, Jul 6, 2011 at 6:33 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> On Fri, 01 Jul 2011 16:29:23 +0200, Silvia Pfeiffer
>>> <silviapfeiffer1@gmail.com> wrote:
>>>> Hi Paul, all,
>>>> after analyzing this problem thoroughly, which I have documented [1],
>>>> I have come to the conclusion that there is no need for introduction
>>>> of any normative text into the specification to satisfy this use case.
>>>> Right now, we have a linear navigation means through text tracks of
>>>> kind chapter.
>>>> IMO the best means to provide hierarchical navigation, which is
>>>> particularly useful to vision-impaired users, is to make it possible
>>>> to provide navigation lists inside the cues that make up
>>>> kind="chapters" track. As such cues are handed to AT, their markup is
>>>> interpreted and made available to AT, including any associated lists.
>>>> My only suggestion would be to potentially add a recommendation to the
>>>> specification underneath where "chapters" are introduced [2]
>>>> which essentially states that subnaviation within chapter cues should
>>>> be provided through list elements (ul,li) inside a chapter's cue.
>>> There are no list elements in WebVTT, are you suggesting they be added?
>> Yes,  am. If you look at the examples, I added a <nav> element and am
>> using the <time> elements as list elements, since the time markers
>> provide the navigation points.
> Oops, I didn't notice you'd linked to
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation until now.
>>> To
>>> provide a chapter tree, would it not be better to have dedicated syntax
>>> for
>>> it? Perhaps:
>>> 00:00.000 --> 01:00.000
>>> 1. Foo
>>> 00:00.000 --> 00:30.000
>>> 1.1. Foo, Part 1
>>> 00:30.000 --> 01:00.000
>>> 1.2. Foo, Part 2
>>> The spec would need to add some parsing for kind=chapters, to deduce the
>>> level of nesting from the leading x.y.z...
>> I've considered this, but with this kind of markup you cannot
>> guarantee that the sublevels are temporally within the main level and
>> you have to deconstruct the hierarchy. I think parsing something like
>> this into a navigation tree is much harder.
>> Also, navigation currently works in accessibility technology very
>> easily through lists, so if we can map whatever we do in WebVTT into a
>> list markup, that makes it simple. Therefore, I came up with the list
>> markup as given in the wiki page:
>> <ul>
>>        <li><? target='timestamp' data='00:00:03.450'>Subchapter 1</li>
>>        <li><? target='timestamp' data='00:00:04.000'>Subchapter 2</li>
>>        <ul>
>>          <li><? target='timestamp' data='00:00:04.000'>Paragraph 1</li>
>>          <li><? target='timestamp' data='00:00:04.500'>Paragraph 2</li>
>>          <li><? target='timestamp' data='00:00:05.000'>Paragraph 3</li>
>>        </li>
>>        <li><? target='timestamp' data='00:00:06.000'>Subchapter 3</li>
>>      </ul>
>> That is using the mapped timestamps from WebVTT to provide the
>> navigation points and the list markup to allow making use of
>> screenreaders' hierarchical navigation capabilities.
> OK, so the idea is that markup as in
> http://www.w3.org/WAI/PF/HTML/wiki/Media_Navigation#Possible_Markup_for_WebVTT
> should get converted into a list for getCueAsHTML? That seems a bit funky,
> how about just letting it be a HTML <nav> element?

If I understand the <nav> element in HTML correctly, then it's just a
<div>-like construct that encapsulates an area that contains
naviagtion markers, but the navigation itself is still done in a list.
I'm looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-nav-element

We could put the <nav> around the <ul> in the above example, but it's
not really necessary.

<nav> seemed useful for grouping <timestamp> markers together on a
level in WebVTT though. And it's just one element, not two like <ul>
and <li>.

> The syntax here doesn't seem very important though, so let's discuss that
> when the times actually comes to include this in the spec.

Agreed. I was just trying to come up with something simple.

>>> I'm not convinced this should be added to the spec right away,
>> Are we talking about adding something to the WebVTT spec or the HTML spec?
>> For HTML, we don't have to add anything, because IIUC the above markup
>> (with <ul> etc) would already be supported. We might add an example,
>> if/when we think this is the right way forward.
> I don't understand, HTML doesn't seem involved here except for getCueAsHTML,
> right?

Yes, that's where it comes in - in getCueAsHTML.

>> 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?

Received on Wednesday, 6 July 2011 12:57:09 UTC

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