Re: Yet Another Scroll-Up Idea (YASUI) in VTT

On Fri, Sep 21, 2012 at 4:47 PM, Simon Pieters <simonp@opera.com> wrote:
> On Fri, 21 Sep 2012 03:25:12 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> It's  a bit outdated and replaced by
>> http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
>>  now. I have emailed the group about this before and asked if it can
>> become part of what we're working on.
>
>
> The style sheet looks wrong. You should drop the "video track" from all
> selectors. Also this ruleset seems mostly wrong:
>
> video track {
>   font-family: monospace;
>   font-size: 100%;
>   font-style: normal;
>   font-weight: normal;
>   font-effect: none;
>   background-color: black;
>   color: white;
>   line-height: 100%;
>   position: absolute;
>   top: 10%;
>   left: 10%;
>   width: 80%;
>   height: 80%;
> }
>
> The selector should be just ::cue (matches the WebVTT root), there's no
> font-effect property, position, top, left, width and height do not apply to
> WebVTT elements.
>
> Are you sure you want font-size:100%? IIRC it will inherit the font size of
> the video element (which is likely to be 16px or so; won't scale with the
> video). The default is 5vh i.e. 5% of the video viewport's height.
>

Thanks, that's good feedback. I'll make the changes.


>>> Why can't such UAs just support the subset of CSS that they want to
>>> support,
>>> like 'color' and 'background-color'? WebVTT already subsets which CSS
>>> properties apply, so full CSS support is not needed for WebVTT. Sure, you
>>> need a CSS parser, but that's pretty easy and even has a state machine
>>> tokenizer and parser spec now. http://dev.w3.org/csswg/css3-syntax/
>>
>>
>> That spec was created for offline players in particular. The default
>> CSS style sheet is not one that I would bake into the browsers, but
>> one that I would supply the browser with when given a WebVTT file that
>> uses 608 features. Thus, from the browser's point of view nothing
>> changes.
>
>
> If offline players support it, and content authors start publishing
> subtitles with these classes but without a style sheet, browsers are likely
> to feel pressured into supporting the classes.
>
> I think we should aim for interoperability, which is to say, an author
> should be able to author an arbitrary WebVTT file, test it in any WebVTT UA,
> and have it work the same everywhere. If that means everyone need a default
> style sheet, fine, but at that point, maybe we should use <font> or so
> instead of default classes?

This is for a particular subclass of users that all want to convert
their scc files from 607/708 to WebVTT. It helps them to create the
conversion software rather than having to come up with the solutions
by themselves. It also provides them with a style sheet that they can
just cut and paste to deliver with their WebVTT file to Web browsers.


> Are offline players not willing to implement support for the CSS subset that
> applies to WebVTT?

I can't answer that question, since I can't speak for offline players.
I do know that I got push-back at VDD. Maybe JB has more to say on
this.


Actually, I spoke too quickly when I said this is targeted at offline
players. Players should indeed support the full WebVTT spec. However,
what I meant to say is that this is for conversion tools. For example,
owners of caption file collections who want to convert them to WebVTT
need to know how to go about styling them. The 608/708 document
particularly targets such caption file collection owners who support
608/708 type content (usually SCC files).


>>> The WebVTT rendering rules don't really work like "divs" at all.
>>>
>>> The rendering rules do things like avoid overlapping. What happens if a
>>> rollup cue and a positioned cue within a region overlap?
>>
>>
>> The browser should just let that happen it's the responsibility of the
>> author to deal with that. If they intended them to overlap, then so be
>> it.
>
>
> I'd rather not support line:n% positioning than not supporting
> avoid-overlapping. If overlapping is possible, it will happen and that's bad
> user experience.

I spoke only with reference to the suggested new region feature. I did
not mean to suggest any changes to the existing avoid-overlapping
features of cues.

I'm saying that if an author created a region and expects it to be
displayed in a certain location on the video, the browser should not
try to move it anywhere, not even to avoid collision with another
region, since that is what the author decided to create. The browser
should not try to avoid the overlap when it was done intentionally. If
the author wants to avoid overlap, they should not use the region
feature.

Regards,
Silvia.

Received on Friday, 21 September 2012 09:03:03 UTC