Intent to Ship: CSS Hyphens property

[Koji Ishii]

Contact emails

ko...@chromium.org, e...@chromium.org

Spec

CSS Text level 3, Hyphenation Control: the hyphens property

Summary

This CSS property controls automatic hyphenations.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: CSS hyphens property at blink-dev

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

No. Soft hyphens control by ‘none’ and ‘manual’ is supported on all platforms, but the automatic hyphenation requires hyphenation dictionaries for the specified locale.

• Android: Blink uses dictionaries built into OS. M MR1 has 7, N has 33 dictionaries.

• Mac: Blink uses dictionaries built into OS through Core Foundation API. OS X 10.11.6 has 23 dictionaries.

• Win/Linux/Chrome OS: Windows, Linux, and Chrome OS do not provide system hyphenation dictionaries accessible to Chrome. For these platforms the plan is to download the dictionaries on demand, similarly to how we download spell checker dictionaries today.

Automatic hyphenation works only if the dictionary for the specified locale is available. Authors can specify the locale by the lang attribute, or the fallback rules as defined in language of a node if the lang attribute is not specified, or the system locale if the language of a node is unknown.

Interoperability and Compatibility Risk

No compatibility risks are expected.

• Gecko ships today without prefix.

• Edge/Trident/WebKit ships today with prefix.

• Blink had -webkit-hyphens, until we removed as not having an owner.

OWP launch tracking bug

crbug.com/605840

Entry on the feature dashboard

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

[Dominik Röttsches]

Hi Koji,

thanks for sending the intent, good to see this work progressing so well.

On Mon, Sep 12, 2016 at 8:23 AM, Koji Ishii <ko...@chromium.org> wrote:

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

No. Soft hyphens control by ‘none’ and ‘manual’ is supported on all platforms, but the automatic hyphenation requires hyphenation dictionaries for the specified locale.

• Android: Blink uses dictionaries built into OS. M MR1 has 7, N has 33 dictionaries.

• Mac: Blink uses dictionaries built into OS through Core Foundation API. OS X 10.11.6 has 23 dictionaries.

• Win/Linux/Chrome OS: Windows, Linux, and Chrome OS do not provide system hyphenation dictionaries accessible to Chrome. For these platforms the plan is to download the dictionaries on demand, similarly to how we download spell checker dictionaries today.

Automatic hyphenation works only if the dictionary for the specified locale is available. Authors can specify the locale by the lang attribute, or the fallback rules as defined in language of a node if the lang attribute is not specified, or the system locale if the language of a node is unknown.

This sounds more like a "Yes, but limited to available language dictionaries" to me, is that right?

Just to clarify, does this Intent to Ship include the implementation of the automatic downloading for Windows, Linux and CrOS?

Dominik

[Koji Ishii]

​Yes, thanks for saying it in the sample way. There was a discussion at CSS WG to make available dictionaries detectable from CSS, but it hasn't got enough discussions yet.​

Just to clarify, does this Intent to Ship include the implementation of the automatic downloading for Windows, Linux and CrOS?

​This intent does not, we plan to send the intent for those platforms separately.​

/koji

[Philip Jägenstedt]

Will CSS.supports('hyphens:auto') return false on Win/Linux/MacOS in this initial revision? In other words, will there be some feature detection available for this? I presume there are JS libraries for hyphenation that should only run if it's not supported.

[Koji Ishii]

s/MacOS/Chrome OS/, correct?

The spec defines @supports be true if the property:value pair is supported, it can't be false by the content language or by the availability of dictionaries. There was a discussion in CSS WG to query the dictionary availability for a language, but that hasn't been made into the spec yet. So authors need to rely on JS if they want it, on any browsers today.

It is an open question though that whether it should be true or false when there are no dictionaries on Win/Linux/Chrome OS. It is also arguable when M MR1 has only 7 and don't support German for instance, authors may want false.

I'm leaning to return true for these cases because any languages could be missing spec-wise, but I'm ok to return false when there are no dictionaries (Linux/Win/Chrome OS) if it is preferred here. Do you mind to share your opinion?

'hyphens: none' is still useful for those platforms though, and it's 16% of the 'hyphens' property.

/koji

[Philip Jägenstedt]

Yes, I meant Chrome OS, any platform where no dictionaries at all will be supported at this time. Assuming the hyphens property never does anything at all on those platforms, maybe it can be runtime_flag=Something until there's support?

But, if you can come up with a solution for querying language support and some platforms just support no languages, I think that would work as well.

[Koji Ishii]

Thank you for the feedback. Since I'd like 'hyphens: none' to work on all platforms, I'll make 'auto' not a valid value on those platforms, unless someone else think otherwise.

/koji

[Philip Jägenstedt]

That seems reasonable to me. If you go down that path, can you make sure that feature detection is any explainer the spec has, and maybe Modernizr too? (This assumes it would work in other engines, if that's not true then it could be too late for a sane story here.)

[Philip Jägenstedt]

Forgot to say LGTM1. Getting the feature detection right is important, but it's perhaps more appropriate in a code review.

[PhistucK]

I am not sure CSS.supports('hyphens: auto') can be dependent on the available dictionary for a specific language, because it has to have context (the language). Every element can set its language and the dictionary will be picked accordingly, right?

It is a some or nothing situation...

☆PhistucK

--
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+unsubscribe@chromium.org.

[Philip Jägenstedt]

Right, it's not an answer to the dictionary detection issue.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Koji Ishii]

Thank you for checking about the feature detection, learned about it a bit more.

• CSS.supports() works good on platforms with dictionaries.
• CSS.supports() can detect 'auto' is not supported with the CL to disable 'auto' on Win/Linux/CrOS. I'll wait a bit more to land it to see if there were any other opinions.
• Modernizr has two flags, one for auto-hyphenation and another for soft-hyphenation. The code inserts an element to test, probably so that it can detect the language of the body. Both auto- and soft-hyphenation detection works good with or without the CL above.

So the modernizr can detect using the lang of <body>, though it looks like its support is Latin only from the source code.

/koji

[Jochen Eisinger]

lgtm2

I assume we already have the UMA in place to measure the impact of mapping the hyphen dictionaries?

[Koji Ishii]

On Wed, Sep 14, 2016 at 11:14 PM, Jochen Eisinger <joc...@chromium.org> wrote:

I assume we already have the UMA in place to measure the impact of mapping the hyphen dictionaries?

​Yes. UMA for IPC+file is already in place, I'm adding another UMA for file only.

/koji​

[Chris Harrelson]

LGTM3

--

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+unsubscribe@chromium.org.

[Joe Medley]

Koji,

Do you have a best guess as to which version this will ship in?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Koji Ishii]

Hi Joe,

Given 3 LGTM, I'll enable this for M55.

/koji

[Elliott Sprehn]

I'm still concerned about the sync IPC here. I think it's probably better to do this like we do web fonts and layout without the text until the hyphen dictionaries are loaded. That said this spec exists already, and I guess other browsers are implementing it, so we can move forward here.

In the future we should make sure we don't add any new CSS features that would require sync IPC.

[Rick Byers]

This API design doesn't require sync IPC, does it?  I.e. if we discover the sync IPC is adding measurable jank (as I personally suspect it would), then can't we move to a model where the browser proactively maps the dictionaries into the renderer's address space?

Regardless, as long as the particular API design doesn't force us into an implementation corner here, I think we can decouple that debate from this intent (i.e. leave it as an issue for codereview / arch-team to discuss, like other implementation issues).  But if I've missed something and the API design is fundamentally bad in this regard, then that would certainly give cause for concern in the intent.

[Elliott Sprehn]

On Thu, Sep 15, 2016 at 2:13 PM, Rick Byers <rby...@chromium.org> wrote:

This API design doesn't require sync IPC, does it?  I.e. if we discover the sync IPC is adding measurable jank (as I personally suspect it would), then can't we move to a model where the browser proactively maps the dictionaries into the renderer's address space?

That trades startup time of the render process. I think the API does require a sync IPC because mapping a large number of dictionaries (23-33) at startup would have a high cost, I also wonder how much address space this uses on a 32bit machine? If it's as easy as mapping every dictionary at startup we should just do that now. :)

[Rick Byers]

Elliott, if you think there's a real risk that once we understand the fundamental performance cost of this API we may regret shipping it (prefer to leave the feature unsupported than take the perf hit), then I'd support blocking shipping on gathering that data.  Those sorts of concerns are definitely supposed to factor into the ship decision.

Rick

[Koji Ishii]

I gathered some data on dev channel, here's the summary doc. In short, mean was 3-5ms so this was good, but there were some bad data like UINT_MAX ms. I don't have a good explanation of what happened to this user.

Elliott, I'll wait for a bit more before I enable, please tell me if you changed your mind, or we can talk next week.

/koji

[Elliott Sprehn]

My understanding is that UMA is susceptible to all kinds of data corruption issues, for example bad ram, fast shutdown, various other things. I think we usually ignore the nonsense data. :)

I think we should go ahead with shipping this for now, but be mindful of the cost and watch the numbers.

[Rick Byers]

Sounds good, thank you!