Re: [VTT] continued discussion in the CSS WG

Is there a possibility to turn these feedbacks from the CSS group into
something as concise as what the i18n group provided, so we can
actually address the feedback?

For example: is this thread suggesting to replace the WebVTT line
balancing algorithm in section 6.1, step 11 with "text-wrap:balance"?
I'd be happy to register that as a bug on the VTT spec if that is the
actual recommendation by the CSS group.

Thanks for any clarification.

Regards,
Silvia.


On Wed, Apr 1, 2015 at 3:13 AM, David Singer <singer@apple.com> wrote:
>
>> Begin forwarded message:
>>
>> From: Alan Stearns <stearns@adobe.com>
>> To: Simon Pieters <simonp@opera.com>, David Singer <singer@apple.com>, Bert Bos <bert@w3.org>
>> Cc: "www-style@w3.org" <www-style@w3.org>, Randy Edmunds <redmunds@adobe.com>
>> Subject: Re: Agenda+ review 1st WD of WebVTT
>> Date: March 31, 2015 at 07:40:00 PDT
>>
>> On 3/31/15, 4:26 AM, "Simon Pieters" <simonp@opera.com> wrote:
>>
>>> (Again move technical discussion to the public list....)
>>>
>>> On Tue, 31 Mar 2015 13:19:30 +0200, Simon Pieters <simonp@opera.com>
>>> wrote:
>>>
>>>> On Mon, 30 Mar 2015 23:22:58 +0200, Alan Stearns <stearns@adobe.com>
>>>> wrote:
>>>>
>>>>>
>>>>> My comment for the collection is either on WebVTT or CSS Text level 4.
>>>>>
>>>>> The
>>>>> definitions for line balancing should be rationalized, and probably a
>>>>> note
>>>>> should be added to both that the definition may only hold for Latin
>>>>> text.
>>>>>
>>>>> In WebVTT section 6.1 [1], step 11 of the algorithm for obtaining CSS
>>>>> boxes says:
>>>>>
>>>>> -----
>>>>> any line breaks inserted by the user agent
>>>>> for the purposes of line wrapping must be
>>>>> placed so as to minimize Δ across each run of
>>>>> consecutive lines between preserved newlines
>>>>> in the source. Δ for a set of lines is defined
>>>>> as the sum over each line of the absolute of
>>>>> the difference between the line's length and
>>>>> the mean line length of the set.
>>>>>
>>>>> -----
>>>>>
>>>>> In Text level 4 section 5.1 [2], the definition of text-wrap:balance
>>>>> says:
>>>>>
>>>>> -----
>>>>>
>>>>> Line boxes are balanced when the standard deviation from
>>>>> the average inline-size consumed is reduced over the block
>>>>>
>>>>> (including lines that end in a forced break).
>>>>>
>>>>> -----
>>>>>
>>>>>
>>>>> I’d be happy to adopt WebVTT’s second sentence if that’s deemed better,
>>>>> but I’m not that happy about the first sentence. If you assume a forced
>>>>> break is always a paragraph boundary, then different line lengths
>>>>> before
>>>>> and after the break are fine. But if you consider a forced break to not
>>>>> break apart the paragraph, then different line lengths before and after
>>>>> the break are bad.
>>>>
>>>> I think it would be good if WebVTT used text-wrap:balance instead of
>>>> its
>>>> own prose to handle line balancing, so UAs can have a single
>>>> implementation for both WebVTT and CSS.
>>>>
>>>> I don't have a strong opinion on what the rule should be, but for CSS
>>>> it
>>>> would be good if it allows an implementation to balance many lines of
>>>> text with acceptable performance (e.g. O(n^2) is not acceptable).
>>>>
>>>> Also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=19458
>>
>> On performance, Randy Edmunds demonstrated a proposal a while back [1]
>> where the algorithm runs at most two layout passes. One of the reasons I
>> used the word “reduced” rather than “minimized” is to allow some variation
>> in the ways that different browsers can achieve the balanced effect.
>>
>> Browser interop does not (and I believe it can not) include identical line
>> breaks in the non-balanced case, so I don’t think it makes any sense to
>> require ideal breaks when balancing. The general result should merely show
>> more balance (when possible), and we can construct some obvious test cases
>> as a baseline for any algorithm to pass.
>>
>> Thanks,
>>
>> Alan
>>
>> [1] https://lists.w3.org/Archives/Public/www-style/2013Jan/0597.html
>>
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
>

Received on Tuesday, 31 March 2015 16:23:37 UTC