CSS column-count cuts off overflow beyond column bound
Reported by
paulnikl...@gmail.com,
Oct 18 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. have a <div> or <ul> with a column-count > 1 2. Fill it with <div>s or <li>s, that overflow horizontally. optional: 3. adding "-webkit-transform: translateZ(0)" makes them appear, but only visually (no response to mouse). What is the expected behavior? The horizontally overflowing parts in the left columns should be fully displayed (even without "-webkit-transform: translateZ(0)") and be clickable. What went wrong? Beyond a column-bound everything seems to be cut of, no matter what. When adding "-webkit-transform: translateZ(0)" hardware acceleration is used and everything renders above the content, but interaction using the mouse is still not possible. Did this work before? No Does this work in other browsers? No Firefox: works fine. IE & Edge: Same behavior on first list, second list is same as first, since -webkit is unknown. I couldn't find bug reports on other browsers. Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version: There were similar issues in the past with shadows, like Issue 269061, Issue 84030 or Bug 14137 (https://bugs.webkit.org/show_bug.cgi?id=14137). This works properly in Firefox 55.0.3 (32-Bit), but since "break-inside: avoid;" doesn't work it messes with positioning. To see the proper behavior you need to add an item 6 to the lists.
,
Oct 18 2017
,
Oct 19 2017
@bugsnash@chromium.org: But the interaction (click, mouseover) also doesn't work (see item 2 & 3), even when everything is painted. (But I don't know, whether chrome handles painting and interacting separately and the core problem is the painting.)
,
Oct 19 2017
IIRC we draw columns using clips on the column content. So this behavior is not surprising. Sound right? Does SPv2 fix it?
,
Oct 20 2017
@chrishtr@chromium.org I opened test_3.html in Chrome 62.0.3202.62 (stable) (x64) with --enable-slimming-paint-v2. The result: The items are displayed as if column-count is 1, overflowing the lists end. The hitboxes are still the same, as the are without --enable-slimming-paint-v2 (hovering to right of the list, where the text in "Item 4" should be, makes it appear green, although it is somewhere completely different). In the screenshot I changed the spacers height to 200px and the background to gray. I also drew the mouse position into the screenshot.
,
Nov 7 2017
This is a layout issue. In this case the column clip omits the overflow content from the first column, which would otherwise overlay the second column. The output looks quite bad in this example in Firefox, but not sure if it's according to spec regardless. The effect of translateZ(0) is just a temporary compositing limitation of SPv1.
,
Nov 8 2017
,
Nov 12 2017
@chrishtr@chromium.org I don't know what spec you are referring to, but according to this one: https://www.w3.org/TR/css-multicol-1/#overflow-inside-multicol-elements, Firefox is right.
,
Nov 13 2017
The CR version of the multicol spec [1] says to clip columns at the middle of their adjacent column gaps. This is what Blink attempts to implement. So, in that sense, what's going on when setting translateZ(0) is a bug. Contents should still be clipped, according to that version of the spec. However, the working draft has removed this clipping requirement [2]. Firefox implements it that way. I guess it's time for Blink to follow up and implement it like this as well. Especially if Edge does it too. I have no access to a Windows machine right now, so I cannot test. [1] https://www.w3.org/TR/2011/CR-css3-multicol-20110412/#overflow-inside-multicol-elements (although this one has even been marked as "outdated" since last time I checked) [2] https://www.w3.org/TR/css-multicol-1/#overflow-inside-multicol-elements
,
Dec 6 2017
Issue 498730 has been merged into this issue.
,
Dec 6 2017
Issue 677641 has been merged into this issue.
,
Dec 6 2017
,
Dec 6 2017
,
Dec 6 2017
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c22925f307e891ac5184b3258a56b9347098d810 commit c22925f307e891ac5184b3258a56b9347098d810 Author: Morten Stenshorne <mstensho@chromium.org> Date: Tue Dec 12 13:18:42 2017 Associate remaining wpt multicol tests with dedicated bug reports. Bug: 788337 , 776051 ,792435,792437,636055,792446, 794136 Change-Id: I933ece936b79323bfcdf16cc96fd3475f42349f6 Reviewed-on: https://chromium-review.googlesource.com/822254 Reviewed-by: Philip Jägenstedt <foolip@chromium.org> Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Cr-Commit-Position: refs/heads/master@{#523416} [modify] https://crrev.com/c22925f307e891ac5184b3258a56b9347098d810/third_party/WebKit/LayoutTests/TestExpectations
,
Dec 12
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by bugsnash@chromium.org
, Oct 18 2017