Re: [csswg-drafts] [css-text-4] Allow for paragraph-level line breaking

On Tue, 2016-11-29 at 17:23 -0800, Florian Rivoal wrote:
> > 
> > One was to say whether you expect text to be editable in the
> > future.
> If we want to follow through with this, we either need to define the
> initial value (`wrap`) to be that value, or to have 3 values:
> - one that's guaranteed stable and fast (`wrap`?)
> - one that promises nice layout (`multi-line?`)
> - an initial value that lets the browser pick where it wants to be 
on
> the stability-performance-niceness spectrum (`auto`?)

I think that future-editability should probably not be conflated with
wrapping. An alternate approach might be for HTML to offer values for
content-editable that included "never" (read-only DOM subtree),
"scripted" to mean it could happen, and "yesbaby". But that makes it
harder to write an application for editing arbitrary documents. So
previously I'd proposed a separate property for it.

But yes, all I really care about here is that browsers can improve
paragraph layout without screwing up Web editing applications.

My original proposal:
https://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html

As adopted:
https://lists.w3.org/Archives/Public/www-style/2013Apr/0246.html

I didn't do this in the end mostly because of Houdini (and talking to
people) but looks like it's time.

What's important seems to be
(1) authors can demand a stable algorithm for an element/subtree so
that starting to edit doesn't cause a reflow;

(2) page authors/designers can express that good line-breaking is
important

(3) people can experiment with algorithms (e.g. polyfills, prefixed
values) until we learn better what works. There's been a lot of
research in the past on this stuff, but the area of automatic layout
(i.e. the page author isn't there to make changes and try again)
combined with interactive screen display makes line-breaking very
different than for paper, and very different from e.g. TeX's
environment.

> > [...] modified first-fit that operates on an n-line window.

> That's for the `multi-line` case where we're trying to get the 
nicest
> result, right?
Yes. It's almost as fast as simple wrapping, slightly worse than 
linear
on the number of words in the paragraph, but also slightly harder to
code :-) as you need to handle n previous lines (an n of as small or 2
or 3 makes a huge improvement over "ifrst fit/greedy", though).

> For the fast-and-stable case, should we just leave it up to 
browsers,
> or require a particular approach, or or leave it up to browsers 
*and*
> suggest particular approach?

I think the latter. As Fantasai said when it was discussed before,
authors should not have to opt in to higher quality.

I suggest an n-line optimization. It's fast and does a good job, *but*
it is not monatonic: adding a word at the end (or anywhere) can in 
some
cases reduce the number of lines in a paragraph. That means the
insertion point can jump backwards as you're editing.

That's only mildly disruptive on a graphic designer's 30" page layout
display but no good on a mobile device or in a Web app where there
might be limited display space for the text, hence wanting for authors
to be able to opt out. Another approach that's been tried is to add a
delay, so you don't reflow the paragraph while it's being edited, but
that's a nightmare for copy-fitting and also has accessibility 
problems
for people who lose their place when it does finally reflow.

Note that the TeX Knuth-Plass algorithm is worse than polynomial (they
say it's NP-complete) on the number of words in the paragraph, which
might be risky for a Web browser.

[...]

>   - the algorithm is UA defined. It should bias towards nice layout,
> if necessary at the expense of speed and stability. Liam's favorite
> suggestion is offered in a note as one reasonable approach to do
> that.
OK.

Liam




-- 
GitHub Notification of comment by liamquin
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/672#issuecomment-264016117 
using your GitHub account

Received on Wednesday, 30 November 2016 22:25:42 UTC