New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 671341 link

Starred by 1 user
Status: Fixed
Owner:
kojii@chromium.org
Closed: Dec 2016
Cc:
█ meade@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Hyphenation should take precedence when both hyphens: auto and break-word are applied

Reported by tburn...@hubspot.com, Dec 5 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36

Steps to reproduce the problem:
I've set up some examples at http://codepen.io/TrevorBurnham/pen/NbYvVZ

You'll need to view that page in a version of Chrome that supports `hyphens: auto` (Chrome 55+).

What is the expected behavior?
* In Table 1 and Table 2, the content of a cell overflows when it has `hyphens: auto`. I would expect that either the cell would grow wider (as when `hyphens: auto` is not set) or that auto-hyphenation would occur (as in Table 3).
* In Table 4, I would expect the two cells to have more aggressive hyphenation in order to reduce their width further.
* In Table 5, I would expect `overflow-wrap: break-word` to cause a line break to be inserted in the word.
* In Table 6, I would expect the line break inserted to be accompanied by a hyphen.

What went wrong?
A table cell with `hyphens: auto` can experience content overflow rather than growing with its content (Table 2 in the CodePen linked above). See the attached GIF.

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 55.0.2883.75  Channel: stable
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 23.0 r0
hyphen-overflow.gif
149 KB View Download

Comment 1 by meade@chromium.org, Dec 5 2016

Cc: meade@chromium.org
Components: -Blink>CSS Blink>Layout
Owner: kojii@chromium.org
Status: Untriaged (was: Unconfirmed)
Interestingly, this seems to behave differently on Chrome on different platforms too.

Koji, is this similar to  issue 671125 ?

Comment 2 by kojii@chromium.org, Dec 6 2016

Status: Assigned (was: Untriaged)
Yeah, looks like so. I'll take a look.

Comment 3 by kojii@chromium.org, Dec 6 2016 

Thank you for the detailed analysis.

* In Table 1 and Table 2, the content of a cell overflows when it has `hyphens: auto`. I would expect that either the cell would grow wider (as when `hyphens: auto` is not set) or that auto-hyphenation would occur (as in Table 3).

This is the same as  issue 671125 , I'll work on it.

* In Table 4, I would expect the two cells to have more aggressive hyphenation in order to reduce their width further.

This is the same as  issue 671125 , I'll work on it.

* In Table 5, I would expect `overflow-wrap: break-word` to cause a line break to be inserted in the word.

This is by design; CSS defines "overflow-wrap: break-word" to expand its container. If you don't want to expand the container, you should use "word-break: break-word". Please refer to  issue 155767  and  issue 492202 .

* In Table 6, I would expect the line break inserted to be accompanied by a hyphen.

Huh, good point. The order of hyphenation/break-word/break-all isn't defined in the spec. A quick test:

http://output.jsbin.com/bivori
Edge, Gecko: break-all > hyphens > break-word
WebKit: hyphens > break-all/break-word

Though not defined, hyphens to win over break-word in 3 browsers, we should probably follow the same order.

Comment 4 by kojii@chromium.org, Dec 6 2016

Summary: Hyphenation should take precedence when both hyphens: auto and break-word are applied (was: Content can overflow table cells with hyphens: auto)

Comment 5 by tburn...@hubspot.com, Dec 6 2016 

Thanks, I appreciate the quick response! I'll keep an eye on  issue 671125 .
Project Member

Comment 6 by bugdroid1@chromium.org, Dec 7 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0922f146b8701a3609d57e0fb11b3eb9d35ceb47

commit 0922f146b8701a3609d57e0fb11b3eb9d35ceb47
Author: kojii <kojii@chromium.org>
Date: Wed Dec 07 16:40:27 2016

Prioritize hyphenations over break-word/break-all

When these mid-word break properties are used together, this patch
tries to hyphenate first.

This behavior matches to WebKit, and to Gecko/Edge for break-word. The
priority isn't defined in the spec, currently an open issue[1]. But for
break-word, 4 browsers are interoperable with this change.

Also fixes one of failing cases in fast/text/basic/015.html that is
related with additionalWidthFromAncestors when break-word.

[1] https://github.com/w3c/csswg-drafts/issues/791

BUG= 671341 

Review-Url: https://codereview.chromium.org/2560453002
Cr-Commit-Position: refs/heads/master@{#436979}

[modify] https://crrev.com/0922f146b8701a3609d57e0fb11b3eb9d35ceb47/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/0922f146b8701a3609d57e0fb11b3eb9d35ceb47/third_party/WebKit/LayoutTests/fast/text/hyphens/midword-break-priority-expected.html
[add] https://crrev.com/0922f146b8701a3609d57e0fb11b3eb9d35ceb47/third_party/WebKit/LayoutTests/fast/text/hyphens/midword-break-priority.html
[modify] https://crrev.com/0922f146b8701a3609d57e0fb11b3eb9d35ceb47/third_party/WebKit/Source/core/layout/line/BreakingContextInlineHeaders.h

Comment 7 by kojii@chromium.org, Dec 10 2016

Labels: OS-Android
Status: Fixed (was: Assigned)
This is fixed in today's Canary, it'd be great if you could try your pages with Canary. Thank you for taking time to investigate this issue and report to us.

Comment 8 by tburn...@hubspot.com, Dec 11 2016 

Aye, everything looks A-OK! Thanks again.
Project Member

Comment 9 by bugdroid1@chromium.org, Dec 21 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6f8143d0f8714ef06bfc23130e9163c646de6e0f

commit 6f8143d0f8714ef06bfc23130e9163c646de6e0f
Author: Xianzhu Wang <wangxianzhu@chromium.org>
Date: Wed Dec 21 05:23:05 2016

Auto-rebaseline for r436979

https://chromium.googlesource.com/chromium/src/+/0922f146b8

BUG= 671341 
TBR=kojii@chromium.org

Review-Url: https://codereview.chromium.org/2592803003 .
Cr-Commit-Position: refs/heads/master@{#440027}

[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/linux/fast/text/basic/015-expected.png
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/linux/fast/text/basic/015-expected.txt
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/mac-mac10.10/fast/text/basic/015-expected.png
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/mac-mac10.9/fast/text/basic/015-expected.png
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/mac/fast/text/basic/015-expected.png
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/mac/fast/text/basic/015-expected.txt
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/win/fast/text/basic/015-expected.png
[modify] https://crrev.com/6f8143d0f8714ef06bfc23130e9163c646de6e0f/third_party/WebKit/LayoutTests/platform/win/fast/text/basic/015-expected.txt
►

Sign in to add a comment