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!