[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 #4 from Javier Fernandez <jfernandez at igalia.com> ---
(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.

-- 
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/20180502/96306427/attachment.html>