Intent to Implement: overflow-wrap: break-spaces

[Javier Fernandez]

Contact emails

jfern...@igalia.com

Spec

CSS Text Module Level 3

https://drafts.csswg.org/css-text-3/#overflow-wrap-property

Summary

This overflow-wrap:break-spaces value allows authors to specify that any sequence of preserved white space that would otherwise overflow the line and hang as per Trimming and Positioning must be broken.

Motivation

With 'white-space: pre-wrap' it's possible to wrap and preserve white-space sequences in the middle of a text line. However, if there is a sequence at the end of the line, it's either collapsed or hang, maybe overflowing its box area. The new value 'overflow-wrap: break-spaces' allows authors to wrap and preserve these white space sequences. This can be also useful for textarea or contenteditable elements, so that white space sequences added by space-bar press events are handled properly and generate break lines if needed. Finally, there is an ongoing effort to enhance interoperability of the line breaking CSS properties (white-space, word-break and overflow-wrap) and this new value was defined precisely to achieve that.

Interoperability and Compatibility Risk

Low compatibility risk.

• Since overflow-wrap:break-spaces is new value it won’t break existing web.

Low interoperability risk

• The spec is still level 3, not as mature as we'd like.

• Testing suite under the Web Platform Tests
• http://wpt.fyi/css/css-text-3/white-space
• New value agreed by the CSSWG with contributions of most of the main browsers; apparently, no public disagreement.
• https://lists.w3.org/Archives/Public/www-style/2016Jun/0019.html

WebKit: https://webkit.org/b/177327 but still no public support

Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1351432 but still no public development activity

Edge: No public signals

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/767634

Link to entry on the feature dashboard

https://www.chromestatus.com/features/4842781306519552

Requesting approval to ship?

No.

[Rick Byers]

/cc the spec editors to make sure they're aware of implementation activity (in case this becomes an intent-to-ship before the spec reaches CR).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3236dfeb-76d9-831b-8d49-7557db748a30%40igalia.com.

[Koji Ishii]

IIUC, this property value defines a new behavior no browsers have implemented yet, correct?

Could we get at least another implementer's signal to implement? If no other browsers follow, this will be a Blink-only feature, and the spec needs to defer it to future levels as it moves REC track forward.

[Javier Fernandez]

Hi,

On 27/09/17 06:08, Koji Ishii wrote:

IIUC, this property value defines a new behavior no browsers have implemented yet, correct?

Could we get at least another implementer's signal to implement? If no other browsers follow, this will be a Blink-only feature, and the spec needs to defer it to future levels as it moves REC track forward.

Mi intention is to do the WebKit implementation as well, but I'm waiting for feedback from reviewers willing to support the feature.

I'll ask about Firefox plans on this feature as well. I agree that we should proceed only if there is enough support from the other browser vendors.

[fri...@gmail.com]

No a spec editor, but chiming in as a contributor to this topic in this spec.

This addition to the spec was made at the same time as a number of interop fixes on related properties, clarifying which of the various space and line breaking properties affected line breaking of preserved white space, and how.

Part of why we managed to agree on the behavior to standardize on was that we also agreed to keep some of the considered-useful alternative behavior left as an option, and this property/value is how to turn that on.

So, replying to Koji:

> IIUC, this property value defines a new behavior no browsers have implemented yet, correct?

Not quite right. No browser implements this property/value pair, but some browsers implement that behavior under different combinations of properties and values.

For instance, Chrome supports wrapping the preserved spaces at the end of the line under the following combination:
  white-space: pre-wrap;
  word-break: break-all;

This is not allowed by the spec, but is useful behavior.

The exact combination of properties to activate the various behaviors in the various browsers have evolved overtime, so I don't have the current full list at hand (I did have it when the csswg resolved), but even though various implementations have changed, there still isn't interop.

The current spec is worded so that:
1) All browsers can behave the same
2) The behaviors people though were worth defending are preserved under some combination of property / values.

I suppose we could relitigate the whole thing, and change what behavior is the default one, which is opt in, and white gets shown the door, but the spec as it is is the result of many hours of coming up with something everyone was OK with, so I'd much prefer if we could get implementations to align on that.

So I am very much in favor of Javier doing this work, and I'd recommend fixing up handling of the white-space property and its interactions at the same time, to pass more (hopefully all) of the relevant part of the css-text-3 test suite, and possibly write a few more. Doing the same in Safari at the same time as he proposed would be great: not only would to key browsers be finally interoperable about that, with a bit of luck (and of bugzilla activism) it may also push other browsers to action.

I would not recommend merely fixing the white-space property implementation without implementing this new value, since that would remove existing useful behavior.

[Javier Fernandez]

Hi,

Signals from other implementers

- WebKit: https://bugs.webkit.org/show_bug.cgi?id=177327#c2

"It would be really great if we could rely on ICU more to handle more cases of line breaking. As I understand it, ICU aspires to handle all the line-breaking situations that are describable in CSS. Given this, I think we'd be happy to pass more information to ICU to describe the environment about how to do line breaking. If ICU doesn't currently support overflow-wrap:break-spaces behavior, we shouldn't implement it in WebKit; we should instead either wait for ICU or specifically ask ICU to support it. If ICU thinks that they will never support overflow-wrap:break-spaces behavior, we should push against it in the W3C."

- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1351432#c3

"This specification is currently under consideration. We agree that it enables valid use cases, as described in bug 1343567."

On 27/09/17 06:08, Koji Ishii wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACQRE%2BSsDY49OZickT%3DydZvUPRfbfRC2T6u2rZ%2BawPuf7_gdCg%40mail.gmail.com.

[Javier Fernandez]

Hi,

I've put this task on hold, waiting for the spec to stabilize a bit more. It seems that after the CSS F2F meeting in Berlin the status of the spec, and specially the new value and CSS syntax I'd like to implement, is much more clear now. So, I'm planning to work on this from now on, if there are no objections.

Back when I submitted the intent-to-implement request I was discussing with both Blink and WebKit engineers about following an ICU approach to implement these line-breaking logic. Apparently, WebKit engineers think that this specific value can be better implemented in by the engine instead; I think Blink can/should follow the same approach.

Another doubt that I've got now is whether to focus on layout-ng or not. It seems that this inline-text and line-braking logic has good support in the new layout engine; even several Web Platform Tests of the css-text suite pass in layout-ng while failing in the old layout engine. I'm more familiar with the old/current layout codebase and considering this wont be a big change, I think it'd better to ship it in the current layout codebase first, and  eventually port it to layout-ng. 

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3236dfeb-76d9-831b-8d49-7557db748a30%40igalia.com.

[Ian Kilpatrick]

Please work with kojii@ to implement in the new engine as well. (This will be a good opportunity to learn the new engine, and to determine if this spec is compatible with the new line breaker before shipping).

Ian

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d23cbf4-5350-9276-04f9-d50685ed4c2d%40igalia.com.

[flo...@rivoal.net]

Hi,

Just to mention that on the CSSWG side, I am happy to support this effort with tests, both for this specific feature, and for the various variants and interactions of line breaking properties in general.

[Koji Ishii]

Hi Javier, sorry for the delay, Japan was in a holiday season.

First, thank you very much for keep working on this. There is no objects of course.

Regarding where to implement, we have 3 layers; the line breaker in layout/, break opportunity functions in platform/text/, and ICU functions used by platform/text/. I prefer we implement these line breaking options in either platform/text/ or in ICU as much as possible. It'd be great if you could consider doing so.

For LayoutNG, the plan to enable it by default is slightly delaying than we originally hoped, but I'm hoping it's not too far; we'll re-evaluate this in Q3. In wpt, 3 of wpt/css/css-text fail in NG but pass in current engine, while 8 pass in NG but fail in current engine. In terms of wpt test suites, NG is already better.

If you want to implement in the current engine too, I'd be happy to review, but please make sure NG is also supported at the same time. We're tracking NG test failures that pass on the current engine. Implementing only in the current engine makes us a little harder.

2018年5月3日(木) 20:11 Javier Fernandez <jfern...@igalia.com>:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d23cbf4-5350-9276-04f9-d50685ed4c2d%40igalia.com.