Re: text-wrap balance

The use case for text-wrap: balance is particularly nice for captions where
best practice in caption authoring requires the author to balence the
rendered lines for better readability.

I wonder if this would also be relevant to TTML? Would it make sense to
lobby the CSS group for it?

Kind regards,
Silvia.


On Sat., 15 Jun. 2019, 3:39 am Philippe Le Hégaret, <plh@w3.org> wrote:

> Forwarding here with permission:
>
> -------- Forwarded Message --------
> Subject: Re: Fwd: Re: text-wrap balance
> Date: Fri, 14 Jun 2019 09:45:37 -0400
> From: Chris Lilley <chris@w3.org>
> To: Philippe Le Hégaret <plh@w3.org>, Fuqiao Xue <xfq@w3.org>
>
>
> On 2019-06-13 16:55, Philippe Le Hégaret wrote:
>  > Chris, Fuqiao,
>  >
>  > the Timed Text Group/WebVTT is wondering what to do with text-wrap:
>  > balance. Do you know or can you find the story behind it? WebVTT
>  > relies on that value but if no one implements it, there isn't much
>  > point...
>
>
> text-wrap: balance (and no-wrap) was proposed for CSS by Adobe. There
> used to be a proposal on their site [1] but that has disappeared.
>
> It is not in CSS Text 3 but was added to CSS Text 4 [2][3] and Adobe
> also maintains a JQuery plugin [4] which implements it. There are no wpt
> tests for the text-wrap property [5]
>
> I have seen other implementations of line-balancing in JS. Other plugins
> or polyfils will be easier once Houdini provides the ability to measure
> the length of a line.
>
> There are a couple of open issues: [6][7][8][9]. From [7], Apple seems
> to be slightly against due to the iterative algorithm (number of passes
> is unknown, and interaction with text fragmentation is unclear).
>
> Current status seems to be a bunch of web developer interest, no
> implementer interest. The spec might be improved by a couple of good,
> visual examples. Needs evangelism to demonstrate need, I suspect.
>
> [1] https://adobe-webplatform.github.io/balance-text/proposal/index.html
> [2] https://www.w3.org/TR/css-text-4/#text-wrap Sept 2018
> [3] https://drafts.csswg.org/css-text-4/#text-wrap
> [4] https://github.com/adobe/balance-text
> [5] https://github.com/web-platform-tests/wpt/tree/master/css/css-text
> [6] https://github.com/w3c/csswg-drafts/issues/3047 (from frivoal
> <https://github.com/frivoal>)
> [7] https://github.com/w3c/csswg-drafts/issues/2528 (from tobireif)
> <https://github.com/tobireif>
> [8] https://github.com/w3c/csswg-drafts/issues/1975 (from palemieux
> <https://github.com/palemieux>)
> [9] https://github.com/w3c/csswg-drafts/issues/803 (from frivoal
> <https://github.com/frivoal>)
>
>
> On 6/13/2019 4:33 PM, Silvia Pfeiffer wrote:
> > FWIW, I think asking a status update from the CSS group on this
> particular
> > feature would be great.
> >
> > Cheers,
> > Silvia.
> >
> >
> > On Thu., 13 Jun. 2019, 9:09 pm Philippe Le Hégaret, <plh@w3.org> wrote:
> >
> >>
> >>
> >> On 6/12/2019 10:43 PM, Pierre-Anthony Lemieux wrote:
> >>> Hi Gary et al.,
> >>>
> >>> In recent publications the group has gone to great lengths to make
> >>> sure that at least two implementations passed each test, whether for
> >>> exotic or trivial features.
> >>   >> Why would it be different here? Have the criteria changed? Should
> >>> future versions of TTML and WebVTT have to meet a lower threshold of
> >>> "proof-of-concept"?
> >>>
> >>> I think the group needs to be consistent, one way or another.
> >>
> >> I thought the exit criteria was 2 implementations of each feature. There
> >> is a difference between tests and features.
> >>
> >> However, I'm not suggesting that the difference matters in this
> >> particular test, given that the spec is clear on this particular test.
> >> If the value balance isn't supported today, what are the implementations
> >> doing instead of balance? Chromium doesn't seem to have a bug report on
> >> balance for example. Should we ask the CSS Working Group on the status
> >> and stability of balance? (Gary, I'm happy to go on fact findings if
> >> you'd like)
> >>
> >> Philippe
> >>
> >>
> >
>

Received on Saturday, 15 June 2019 13:26:40 UTC