Bug 177327

Summary: Implement overflow-wrap:break-spaces value
Product: WebKit Reporter: Javier Fernandez <jfernandez>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: darin, hyatt, jfernandez, mmaxfield, rniwa
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.chromium.org/p/chromium/issues/detail?id=767634
https://bugzilla.mozilla.org/show_bug.cgi?id=1351432

Description Javier Fernandez 2017-09-21 15:39:20 PDT
The CSS Text 3 spec defines the 'overflow-wrap' property as property:

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

"Value: 	normal | break-word || break-spaces"
Comment 1 Javier Fernandez 2017-09-27 04:21:02 PDT
I'm asking Blink and Gecko engineers about the plans to implement this feature. It'd be great to have an idea about the WebKit position and its level of support to implement this.
Comment 2 Myles C. Maxfield 2017-10-03 12:44:38 PDT
(In reply to Javier Fernandez from comment #1)
> I'm asking Blink and Gecko engineers about the plans to implement this
> feature. It'd be great to have an idea about the WebKit position and its
> level of support to implement this.

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.

Regardless of what ICU's stance or current support level is, we should start on the task of deleting more of WebKit's line breaking code in favor of using ICU. This involves a few different tasks:
1) Discovering which parts of CSS-Text ICU already supports
2) Measuring the performance of their line breaking algorithms, and, if necessary implement some system (caching?) to try to speed it up.

This project is something I'd like to do in the coming years.
Comment 3 Myles C. Maxfield 2017-11-20 13:36:02 PST
(In reply to Myles C. Maxfield from comment #2)
> (In reply to Javier Fernandez from comment #1)
> > I'm asking Blink and Gecko engineers about the plans to implement this
> > feature. It'd be great to have an idea about the WebKit position and its
> > level of support to implement this.
> 
> 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.
> 
> Regardless of what ICU's stance or current support level is, we should start
> on the task of deleting more of WebKit's line breaking code in favor of
> using ICU. This involves a few different tasks:
> 1) Discovering which parts of CSS-Text ICU already supports
> 2) Measuring the performance of their line breaking algorithms, and, if
> necessary implement some system (caching?) to try to speed it up.
> 
> This project is something I'd like to do in the coming years.

I started looking at this more deeply, and I realized you are talking about a different property than the one I thought you were talking about. overflow-wrap doesn't create a new pattern of line-breaking opportunities; instead it says "if you didn't find any opportunities using one kind of iterator, use another kind of iterator." The novel piece here is the handoff from one iterator to another iterator; ICU already implements both kinds of iterators correctly. Therefore, we don't need to get involved with ICU for this feature. Sorry for the misdirection.

The break-spaces value of overflow-wrap only interacts with whitespace, and because there are only a few whitespace characters, handling this logic directly inside WebKit seems fine. You could probably do this quickly by hacking on BreakingContext::handleText() (and either opting out of simple line layout or implementing it there too). However, this function is probably the least maintainable function relating to text in the entire codebase, so rather than implementing support directly here, a better approach would be to put the implementation behind the TextBreakIterator API, and to try to implement the kind of handoff structure that we could use for overflow-wrap: break-word. Eventually, overflow-wrap: break-word and word-break: break-all should use the same grapheme-cluster-based iterator (and overflow-wrap: break-word would hand-off between this and a regular iterator, where word-break: break-all wouldn't).

This would be a fantastic first step toward the long-term plan to make BreakingContext::handleText() more understandable and maintainable.

Does this sound okay? What do you think about it?