Re: Response to call for public review of WebVTT FPWD

Hi Andreas,

Sorry for the late reply, but I think we've got most of your feedback
covered in the bug tracker now, so will be tracked there.

Some more feedback / questions inline.


On Mon, Mar 23, 2015 at 4:39 AM, Andreas Tai <tai@irt.de> wrote:

>
>     GENERAL OBSERVATIONS
>>
>> It is an interesting approach to provide different sections to different
>> target groups (e.g. WebVTT authors and WebVTT parser implementers) so
>> they do not have to read the complete spec. My experience is (after
>> reading different versions of WebVTT) that even for a specific task it
>> is difficult to get the necessary information without reading through
>> the complete spec.
>>
>> If you are an author of WebVTT who wants to get the normative (!) text
>> how to write a timed subtitle in WebVTT that should appear at a specific
>> position at the bottom of the screen, where the text should have a
>> specific font size in relation to the video height and the text color of
>> the first line should be white and the text colour of the second line
>> shall be yellow than it is not sufficient to just read through the data
>> model and syntax sections. You have to read the rendering section which
>> also refers back to concepts of the parsing section.
>>
>>
>  You shouldn't need to read the rendering section, but you are right. You
> will need to read the CSS extensions section for the color changes only
> thought. Would it help to make the syntax of the CSS extensions a separate
> section?
>
>
> Not sure about the concrete solution. An author should get a hint where to
> look if we he wants to know how to set display properties like font or
> color properties. It may not been obvious for a non webvtt expert which
> display properties are defined by CSS and which are defined by webvtt
> syntax. It is as well important to have easy access to document parts where
> the default properties for color and fonts are specified. These are quite
> important for captions.
>


I've tried to capture a proposal in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28408 . Please provide
feedback there.



>
>      If for the above task you want to get the information about a specific
>> presentation feature like positioning or writing direction you have to
>> extract from every section the different information. Often a part of a
>> section stand is dependent of other parts. You have to know the general
>> concepts that are outlined in a section (e.g. the concept of WebVTT
>> nodes in the parsing section). Also you presentation features depend on
>> each other (e.g. writing direction and positioning).
>>
>>
>  Positioning and writing direction should be sufficiently specified in
> the syntax. Of course, the syntax section is not a complete authoring guide
> - we have https://docs.webplatform.org/wiki/concepts/VTT_Captioning and
> other articles or tutorials on the Web for that.
>
>    Yes, these kind of authoring guides are very helpful. Maybe you can
> link directly from the spec to resources like that above?
>


Not really. Specs are not meant to contain authoring guides. Authoring
guides come and go and you're better off searching for the best spec around
at the current time when you need it. If you had a stackoverflow question
open about best webvtt authoring guides, we could capture them there, I
guess.



>    Also, why would you need to understand the concept of WebVTT nodes in
> the syntax section? I don't follow. Can you explain?
>
>
> If you want to apply CSS than this is bound to the concept of WebVTT nodes
> (if I am not mistaken).
>


No, not really. But maybe putting a styling section into the syntax section
can help clarify this - see bug above.


     To re-assure you that you have authored a WebVTT file that will be
>> processed exactly as you want (based on normative text) and also if you
>> want to write a WebVTT compliant parser you most probably have to read
>> the complete spec.
>>
>>
> There's a validator at https://quuz.org/webvtt/ that will help write
> valid WebVTT files.
> If you want to write a parser, yes, you will need to read more than the
> syntax - also the parser section.
>
>
> Yes, Anne von Kesteren's tool is very helpful. But as author you also want
> to know how your content get´s rendered.
>


Use your Web browser for that.

[..]

>     Thanks for all the feedback. I'd like to encourage you to register
> more bugs where you would like to see improvements to the specification
> text. It's the best way to keep track.
>
>
> Will do so!
>
> Thanks to you and Philip for changes and discussion,
>

No worries. Do stay involved in the bug discussions! Your help is very much
appreciated.

Cheers,
Silvia.