[Webkit-unassigned] [Bug 177327] Implement overflow-wrap:break-spaces value

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=177327

--- Comment #5 from Myles C. Maxfield <mmaxfield at apple.com> ---
(In reply to Javier Fernandez from comment #4)
> (In reply to Myles C. Maxfield from comment #3)
> > (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?
> 
> Sorry for the very late reply. I've been waiting for the spec to stabilize
> and it seems that after the F2F in Berlin it's in a good state now. 
> 
> I'll start working on this now, but I still have to learn about this new
> codebase and the spec, which I'm not familiar with.

Okay. Please let me know how I can help. I'm very interested in this!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180503/f18c9616/attachment.html>