Re: Absolute region positioning (was Re: Alternative approach to scrolling, with demos)

On Thu, May 8, 2014 at 1:52 AM, Christian Vogler
<christian.vogler@gallaudet.edu> wrote:
> I'll respond in depth later when I'm not otherwise traveling our in
> meetings. Appreciate your thoughts.
>
> For now I'll reiterate something I said earlier: it might be helpful to
> review the features that you are struggling with and how they are impacted
> by your proposals, keeping in mind that the goal is equal to or better than
> TV captions, not identical.

WebVTT regions were created to bring in the following features:

* rollup captions
* handling of a group of captions as an entity, in particular:
  ** explicit fixed width and height box for rendering a group of
captions into ("fixed width" in terms of px right now, but proposed to
be changed to em to approximate number of characters; "fixed height"
in terms of a maximum number of lines of caption cues that are visible
on screen at the same time in the caption group)
  ** background color and border on groups of captions (rather than
just a single caption) so that there won't be any gaps between the
rendered captions' backgrounds and borders
  ** defining how change in font size changes the group box size,
namely around an anchor point (this is a concept borrowed from 708)
* overlap is being dealt with through z-index

Also, there are other possible features when you deal with a group of
captions rather than individual ones, such as moving the group
together (without having to repeat text and thus destroy the
simplicity of doing semantic analysis on cue text), transitioning on
the whole group (e.g. fading out the whole group together), flex-box
like distribution of the caption cues within the region box etc. These
latter are possibilities for the future, not something we need now,
but something that is enabled when we introduce the concept of a
"group of cues" rather than just individual cues.

If all of these are regarded as non-essential features, then of course
I am prepared to drop the concept of regions right now, stop these
discussions, and focus on getting the core of WebVTT polished.

However, if my reading of the FCC rules is correct, rollup captions,
explicit width/height control, and the handling of background color
and border on a group of captions have been deemed important core
features. This being the case, and having followed the last 3 years of
discussions around how to add rollup support, my conclusion is that
the concept of cue groups is both specific enough to solve the core
features that the FCC requires, and generic enough to allow satisfying
other use cases in future that relate to a group of captions.


> I don't have a good handle on what these are,
> because they're spread out over so many threads. If you could condense them
> in a single message, that would be very helpful.
>
> One thing I can say with certainty is that doing positioning well is
> absolutely essential. That is not negotiable. I'll get back to you about
> some more use cases re positioning soon, too.

Positioning has been a key feature from the start of WebVTT. We have
recently added some clarification to that by making it clear how
alignment and positioning interact. This gives sufficient ability to
authors to have fine-grained control over the placement of
*individual* cues. I do not believe that positioning of *individual*
cues is a reason to introduce WebVTT regions.


> More later, including consumer stances (to whom I regularly provide
> technical advice) and the importance of standardization.
>
> Best wishes
> Christian
>
> Sent from my mobile phone.  Please excuse any touchscreen-induced weirdness.
>
> On May 7, 2014 11:28 AM, "Philip Jägenstedt" <philipj@opera.com> wrote:
>>
>> On Wed, May 7, 2014 at 1:02 AM, Christian Vogler
>> <christian.vogler@gallaudet.edu> wrote:
>> > Saying that we need to do something because of some legalities is not
>> > the
>> > right stance to take. It is because video accessibility to people with
>> > disabilities matters, that we are doing this. A lot of the FCC
>> > legalities
>> > with respect to internet video actually exist because that is what
>> > consumers
>> > with disabilities, who first-hand depend on the outcome and use captions
>> > on
>> > a daily basis, asked for. Not all the nooks and crannies are wonderful
>> > or
>> > make sense, but a lot of them are there for good reasons.
>>
>> I agree that accessibility is important, that's why I want to work on
>> WebVTT! It matters to me, not least because I use subtitles myself
>> almost every day.
>>
>> Since I hope to keep working on WebVTT, it's kind of my job to
>> criticize new features. When I don't understand the good reasons
>> behind them, legalities is all that remains, and that's not a
>> compelling reason to work on something. (Obviously, I have no veto
>> power, and maybe others will do the work instead.)
>>
>> > I apologize for being so blunt, but my biggest fear right now is that we
>> > end
>> > up rehashing arguments again that were very hard fought over, because
>> > everyone has a different idea of what is important. That in part caused
>> > us
>> > to end up where we are now: web browsers missed the 2014 deadlines and
>> > are
>> > not complying with accessibility laws and rules. This isn't a legality
>> > but
>> > something that affects us concretely on a day to day basis, and the only
>> > reason that advocacy organizations are taking a wait and see stance,
>> > rather
>> > than going after noncompliance, is that they are aware that WebVTT
>> > standardization efforts are not complete yet.
>>
>> I don't work for a browser vendor based in the US and am not a lawyer,
>> so I'm not in a good position to evaluate this claim. Is it public
>> knowledge that some organizations indent to go to court if browser
>> vendors don't implement and ship specific WebVTT features, even if
>> those features can be implemented in JavaScript?
>>
>> > One way this situation concretely affects us is that the mobile browsing
>> > experience is just inaccessible. As an experiment, try
>> > http://tap.gallaudet.edu/articles/fcc/ on mobile browsers. Take Android
>> > JellyBean with the old WebKit browser. No captions at all. Take Android
>> > KitKat with Chrome, or standalone Chrome, and captions work - as long as
>> > you
>> > don't try to switch to fullscreen mode. Take a desktop browser and
>> > fullscreen works. But mobile isn't there and content providers have
>> > already
>> > stated that they need to get the browser manufacturers to get their act
>> > together in order to meet their obligations to caption everywhere.
>> > Because
>> > that hasn't happened yet we are missing a huge part of the mobile
>> > existence.
>> > We're kind of hoping that WebVTT will get us there, not the least
>> > because we
>> > don't have good alternatives in sight.
>>
>> The fullscreen problem is serious, I agree. If you try the latest
>> Chrome beta for Android you'll find that it has finally been fixed. I
>> haven't tested it, but I assume that overlaying custom controls or
>> captions using JavaScript also works. (I think this fix landed in
>> Chromium 35, so before long Opera will also have it.)
>>
>> This problem was unrelated to the WebVTT implementation, though.
>>
>> > Consumers probably won't care if we do a feature via native WebVTT or
>> > JavaScript, but they will care if JavaScript polyfill doesn't work in
>> > fullscreen, which is where we are right now. Either way, browser
>> > manufacturers are on the hook, and in my view it's better to have a
>> > standard
>> > than a wild west of JavaScript based methods that are inconsistent from
>> > site
>> > to site and browser to browser.
>>
>> With the fullscreen issue resolved, it sounds like native WebVTT
>> support is more of a convenience than an actual requirement. Even
>> though I hope that WebVTT implementations will improve rapidly, I'd
>> bet that for at least a few years, rolling your own rendering in
>> JavaScript is going to be more reliable.
>>
>> Philip

Received on Wednesday, 7 May 2014 23:07:26 UTC