WebVTT regions

Features of WebVTT regions

SP: Looked at requirements for 708 -- WebVTT regions compared with 'normal' captions

SP: Need to be able to do rollups

SP: Region in which captions are rendered: beyond three lines (say) should not be rendered.

SP: Background (colour) for cue could be different.

SP: Grouping of cues: a region for grouping cues, rather than artificially grouping.

SP: Align setting plus region setting?

SP: If vertical setting on cue, can't be part of a region

PJ: why?

KH: print direction plus scroll direction -- not all used or have to be implemented

SP: Only scroll direction parameter currently supported is "up" -- but could be down and/or left or right.

KH: What does FCC require? - this is where it gets vague - has to be a functional equivalent - caption online should match TV - noone uses weird features such as scrolling backwards

PJ: Chinese TV (e.g.) scrolls vertically

SP: Syntax is open to be extended

KH: window 708 concept are great, but many details of style and features

SP: We can try to make sure the *syntax* allows for those things

KH: comment about width... width can't be determined exactly

PJ: how is width expressed, 608 and 708?

KH: column count, based on number of characters

PJ: can we use ems?

EC: problem is if we don't have a good mapping to CSS

DK: em would be least attractive

JP: care about non browser implementations?

SP: change percentage to number of characters?

EC: Problem is percentage, when font is larger than you expected, will wrap in ways you didn't expect

KH: dynamically fitting for display

VC: what does em measure really mean

JP: 20em can mean a lot more

KH: what is CSS friendly?

EC: when user selects large font size, things start to look terrible, bad wrapping

LGR: em is somewhat better

PJ: what do columns mean in 708?

KH: depends on font

PJ: you specify a number of columns and you'll get wrap after a certain number of columns?

KH: yes

LGR: Could interact in odd ways with anchor point

SP: 'no width' means 100% wide

PJ: width and anchor point specified in 708?

VC: in 708, fixed set of nine anchor points

KH: think of it as a push pin, pinning on a box, percentage is more flexible - what Silvia is suggesting

Discussion of alignment

KH: What we've found is, the width is not the issue for pop ons or paint ons -- but is an issue for rollups -- because those areas are defined first and then content dropped in -- make a guess -- pretty sure uses ems

PJ: spec v implementation -- way to fix would be font-size-relative units

SP: how does region grow?

KH: both specs give plenty of ways to screw yourself!

EC: if user chooses different font?

KH: your recommendation is what, to keep visible?

PJ: without regions, rules about line breaking -- something CSS doesn't do

SP: box fixed width or flexible

LGR: fixed width, but relative to font (ems)

SP: would be happy to change fixed width to number of characters

KH: you mean 'this many pixels'?

PJ: 708 character count approach -- *not* like CSS

LGR: matches intention

DK: word wrapping in 708?

PJ: support for popups and paint ons? would be lovely if regions only for scrollup

KH: if we don't have a region, how do we cope with font changes? for popups

PJ: fall back to other rendering algorithm -- font size just increases, and... it just works, though can make it break

KH: keep it roughly where it is supposed to be width/percentage/line-wrap...

LGR: em width implementation is separate question

VC: no 'none' value for scrolling! just default

SP: can do

VC: only part missing plain WebVTT is grouping of cues

PJ: is there a margin?

VC: main concern is people will end up with different versions, extended VTT, etc.

SP: some people might implement regions, some might not... but cue will still get rendered, only not correctly -- but normal cues would have implicit region

PJ: implicit region -- are the rendering algorithms so incompatible

KH: went through complete reimplementation, iOS, simple XML format, want every caption to be in a region -- works but ugly -- opted for implicit regions, so for every pop on, will make up region depending on content

PJ: would love one rendering way!

EC: if radically different rendering, then...

SP: can look at on hack day

KH: simple format into our internal format -- pretty simple, like old format 1

SP: overlap avoidance?

VC: they're just boxes!

SP: regions fixed in a place

EC: can move cues within region!

KH: 708 defines a priority

SP: regions are fixed, priority of which goes on top

SP: my overlap avoidance method is a flexbox

VC: if you want animated scrolling, can't use a flexbox

LGR: animated scrolling = smooth scrolling?

PJ: place new cue below old one, honor transition, can use CSS, support smooth scrolling and 'jumpiness'

EC: order of animating rules?

LGR: is jumpy scrolling an acceptable implementation, thinking of non-browser platforms?

KH: what do Apple do?

EC: don't do anything, no regions yet

SP: as action, change width from percentage to character width based?

LGR: how do you make an implicit region if starting from percentage

EC: compatibility concern is HLS -- renderer doesn't really honor size

DK: our clients too

add em as size unit

SP: but... em doesn't count characters

EC: when an author specifies a width, no line breaks in cues, need a rule -- but when they have line breaks?

KH: the point is that the line should have everything shown

SP: specify as number of characters, number of ems?

PJ: problems of wrapping

SP: want row and column locking

LGR: sounds like people have thought of percentages in different ways

SP: Eric has to polish laptops before going home!

KH: this was a very useful session

PJ: yes!