This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Feedback by Addison Phillips from W3C I18N group: http://lists.w3.org/Archives/Public/public-tt/2015Mar/0066.html I18N comment: https://www.w3.org/International/track/issues/434 3.1 Text track cues http://www.w3.org/TR/2014/WD-webvtt1-20141111/#text-track-cues Line wrapping should take into account the special rules needed for scripts such as the following: - Chinese, Japanese and Korean wrap after characters, but don't put certain characters at the start/end of a line - Thai and other SE Asian scripts wrap at word boundaries, but words are not delimited by spaces – spaces are instead used to separate phrases. - Tibetan wraps after the tsek character that follows a syllable – words are not separated by spaces. - Indic and other complex scripts break at orthographic syllable boundaries, which are often two or more grapheme clusters. See http://www.w3.org/TR/css3-text/#line-breaking for additional background. (http://r12a.github.io/scripts/tutorial/part5 provides additional examples, if needed.) 6.2.1 says that "Text runs must be wrapped according to the CSS line-wrapping rules", but that is a little vague (and, to be honest, the CSS information on script behaviour is also somewhat sparse). No mention is made of default settings for the line-break and word-break properties. It would be good, as a minimum, to remind implementers that script-specific wrapping algorithms need to be supported for WebVTT content. (6.2.2 says that "the 'word-wrap' property must be set to 'break-word'". Note that a alternative, and somewhat more descriptive name for this property is overflow-wrap.) In addition, we noticed in: http://www.w3.org/TR/webvtt1/#cues-with-multiple-lines In Section 1.1, there is discussion about line-wrapping and line-breaking. The examples are given in English. "Balancing" line wrapping might take different forms because of the presentational needs of various langauges.
Silvia, any idea why regions have word-wrap and overflow-wrap settings? We say some silly things after "Text runs must be wrapped according to the CSS line-wrapping rules, with the following additional constraints:" Nobody implements any of that I think. I would really like it if line wrapping were simply the domain of CSS and that if we want some specific behavior we define it in terms of CSS. Someone would then have to do the work of specifying balanced line wrapping in CSS :/
(In reply to Philip Jägenstedt from comment #1) > Silvia, any idea why regions have word-wrap and overflow-wrap settings? The idea there was to make sure that the text is never going outside the region's dimensions. > We say some silly things after "Text runs must be wrapped according to the > CSS line-wrapping rules, with the following additional constraints:" That part is not for regions and was supposed to provide balanced lines. > Nobody implements any of that I think. I believe Victor gave it a try. > I would really like it if line wrapping were simply the domain of CSS and > that if we want some specific behavior we define it in terms of CSS. Someone > would then have to do the work of specifying balanced line wrapping in CSS :/ See bug 19458
(In reply to Silvia Pfeiffer from comment #2) > (In reply to Philip Jägenstedt from comment #1) > > Silvia, any idea why regions have word-wrap and overflow-wrap settings? > > The idea there was to make sure that the text is never going outside the > region's dimensions. Shouldn't whatever measures are needed for this also apply to individual cues, so that they don't overflow the video viewport? > > We say some silly things after "Text runs must be wrapped according to the > > CSS line-wrapping rules, with the following additional constraints:" > > That part is not for regions and was supposed to provide balanced lines. Yep. > > Nobody implements any of that I think. > > I believe Victor gave it a try. Interesting. I can see no trace of that in Blink now, maybe it didn't work out. > > I would really like it if line wrapping were simply the domain of CSS and > > that if we want some specific behavior we define it in terms of CSS. Someone > > would then have to do the work of specifying balanced line wrapping in CSS :/ > > See bug 19458 Ah, thanks.
(In reply to Philip Jägenstedt from comment #3) > (In reply to Silvia Pfeiffer from comment #2) > > (In reply to Philip Jägenstedt from comment #1) > > > Silvia, any idea why regions have word-wrap and overflow-wrap settings? > > > > The idea there was to make sure that the text is never going outside the > > region's dimensions. > > Shouldn't whatever measures are needed for this also apply to individual > cues, so that they don't overflow the video viewport? Right, so we should set that on the viewport (i.e. the initial containing block). I hadn't noticed that missing, but I think the video's rendering area lets nothing out anyway.
I think the original intention was that the rendering algorithm should guarantee that no cue ever ended up outside the video viewport, so that something like overflow:hidden would not be needed. Bug 17473 was about this. After the resolution of bug 17483 this is moot, as any cues that don't fit are removed. That being said, maybe we do want to tweak the default white-space property, but if so the same defaults probably makes sense for regions and cues alike.
(In reply to Philip Jägenstedt from comment #5) > I think the original intention was that the rendering algorithm should > guarantee that no cue ever ended up outside the video viewport, so that > something like overflow:hidden would not be needed. Bug 17473 was about this. > > After the resolution of bug 17483 this is moot, as any cues that don't fit > are removed. Bug 17483 has been resolved, but we have kept the line breaking descriptions. However, bug 28432 should resolve this when we use CSS's new 'text-wrap: balance' (maybe the I18N WG can make sure that this new property works for different scripts?). BTW: overflow hidden is being used on regions because they have a limited number of lines and we want lines that scroll up to disappear. Since normal cues don't have a limited number of lines, they won't need overflow hidden. > That being said, maybe we do want to tweak the default white-space property, > but if so the same defaults probably makes sense for regions and cues alike. To address the remaining issues of this bug, should we put default values on 'line-break:auto' and 'word-break:normal' and should we replace 'word-wrap:break-word' with 'word-wrap:break-word'?
(In reply to Silvia Pfeiffer from comment #6) > To address the remaining issues of this bug, should we put default values on > 'line-break:auto' and 'word-break:normal' and should we replace > 'word-wrap:break-word' with 'word-wrap:break-word'? I don't know, I actually think we should just use the default settings of all white space- and line breaking-related CSS properties and just make sure they're whitelisted for overriding if necessary. Not sure what good we're doing by changing the defaults.
(In reply to Philip Jägenstedt from comment #7) > (In reply to Silvia Pfeiffer from comment #6) > > To address the remaining issues of this bug, should we put default values on > > 'line-break:auto' and 'word-break:normal' and should we replace > > 'word-wrap:break-word' with 'word-wrap:break-word'? > > I don't know, I actually think we should just use the default settings of > all white space- and line breaking-related CSS properties and just make sure > they're whitelisted for overriding if necessary. Not sure what good we're > doing by changing the defaults. I believe the feedback was that there isn't a default unless we provide one.
(In reply to Silvia Pfeiffer from comment #8) > (In reply to Philip Jägenstedt from comment #7) > > (In reply to Silvia Pfeiffer from comment #6) > > > To address the remaining issues of this bug, should we put default values on > > > 'line-break:auto' and 'word-break:normal' and should we replace > > > 'word-wrap:break-word' with 'word-wrap:break-word'? > > > > I don't know, I actually think we should just use the default settings of > > all white space- and line breaking-related CSS properties and just make sure > > they're whitelisted for overriding if necessary. Not sure what good we're > > doing by changing the defaults. > > I believe the feedback was that there isn't a default unless we provide one. Perhaps I misunderstood something, surely getComputedStyle(cue).wordWrap would return *something* if cue were possible to access? Is it that we're integrating with CSS in some way which requires us to define this even in an implementation there would be no need to do anything corresponding?
(In reply to Philip Jägenstedt from comment #9) > > Perhaps I misunderstood something, surely getComputedStyle(cue).wordWrap > would return *something* if cue were possible to access? Is it that we're > integrating with CSS in some way which requires us to define this even in an > implementation there would be no need to do anything corresponding? Comment 1 says "No mention is made of default settings for the line-break and word-break properties." - that's what I thought we might want to fix. http://www.w3.org/TR/html5/rendering.html#the-css-user-agent-style-sheet-and-presentational-hints has no default settings for cues, so I don't know if there is a default.
It looks like the issue stemmed from "Text runs must be wrapped according to the CSS line-wrapping rules, with the following additional constraints" and I think we should remove that entire bullet point, using only plain CSS to get the result what we want.
(In reply to Philip Jägenstedt from comment #11) > It looks like the issue stemmed from "Text runs must be wrapped according to > the CSS line-wrapping rules, with the following additional constraints" and > I think we should remove that entire bullet point, using only plain CSS to > get the result what we want. OK, but that doesn't fix the second point about lack of default settings for the line-break and word-break properties, does it?
(In reply to Silvia Pfeiffer from comment #12) > (In reply to Philip Jägenstedt from comment #11) > > It looks like the issue stemmed from "Text runs must be wrapped according to > > the CSS line-wrapping rules, with the following additional constraints" and > > I think we should remove that entire bullet point, using only plain CSS to > > get the result what we want. > > OK, but that doesn't fix the second point about lack of default settings for > the line-break and word-break properties, does it? Doesn't CSS itself provide some initial value for these properties? It seems strange if every spec has to specify this.
(In reply to Philip Jägenstedt from comment #13) > > OK, but that doesn't fix the second point about lack of default settings for > > the line-break and word-break properties, does it? > > Doesn't CSS itself provide some initial value for these properties? It seems > strange if every spec has to specify this. The default UA style sheet is for HTML elements. A cue isn't a HTML element. So, I think we need to add this here.
(In reply to Silvia Pfeiffer from comment #14) > (In reply to Philip Jägenstedt from comment #13) > > > OK, but that doesn't fix the second point about lack of default settings for > > > the line-break and word-break properties, does it? > > > > Doesn't CSS itself provide some initial value for these properties? It seems > > strange if every spec has to specify this. > > The default UA style sheet is for HTML elements. A cue isn't a HTML element. > So, I think we need to add this here. I don't mean as part of the UA style sheet, I mean as part of CSS itself. The HTML UA style sheet doesn't override every CSS property, so there must be defaults outside of HTML.
(In reply to Philip Jägenstedt from comment #15) > > I don't mean as part of the UA style sheet, I mean as part of CSS itself. > The HTML UA style sheet doesn't override every CSS property, so there must > be defaults outside of HTML. IIUC, each CSS property has default values. E.g. see http://www.w3.org/TR/css3-values/ . However, the HTML UA style sheet overrides these for HTML elements as necessary. line-break's default value is 'auto' according to: http://dev.w3.org/csswg/css-text-3/#line-break-property which means "The UA determines the set of line-breaking restrictions to use, and it may vary the restrictions based on the length of the line; e.g., use a less restrictive set of line-break rules for short lines." Question to Addison: would a default setting of 'strict', 'normal' or 'loosel be better for our purposes? As for "word-wrap" http://dev.w3.org/csswg/css-text-3/#overflow-wrap-property it looks like we should replace that with "overflow-wrap".
I believe that auto (ie. user-defined default per script) would be the best setting.
So, we don't need to do anything for line-break - it's already 'auto'. What's left then is to replace 'word-wrap' with 'overflow-wrap'
I've created a patch at https://github.com/whatwg/webvtt/pull/215 as a proposed resolution for this issue.
https://github.com/w3c/webvtt/commit/43dd2f70eeb95ec7d9e551337ad81a5e0d7f0479
ishida please verify this bug or reopen
We defer to CSS for wrapping, and now use the correct overflow-wrap property (not 'word-wrap')
Richard, can you confirm that the resolution of this bug is ok so we can move the WebVTT spec to CR status?