UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Example URL:
http://output.jsbin.com/jawubik
Steps to reproduce the problem:
1. visit http://output.jsbin.com/jawubik
2. Make the window small so that the "foo" text on the right gets near to the "lorem ipsum dolor sit amet" text on the center, on the same line, but not small enough to have the two text touch. It should look like in screenshot 1.
3. click on the text that reads "foo" on the right
What is the expected behavior?
Additional text, previously hidden, appears on the right. There is not enough space in the line for both the text on the right and the centered text on the left, so this causes the text on the left to wrap. Since the text in the left is all within a non-wrappable span (within the div), the whole span will move to a new line
What went wrong?
The additional text on the right shows up and it overlaps with the text on the left!
This is wrong no matter what: a float never overlaps content in a div that follows it; it should cause it to wrap (which in this case means moving the whole unwrappable span to a new line).
Note that if you test the same page on Android (you may need to adjust the fiddle to the width of your mobile's screen), it behaves as expected. On Firefox (desktop) too.
Also, you can repeat the text with a wider window, wide enough to fit both texts. In this case, when you click on the text on the right and the additional text is shown, the centered text on the left should just move to the left. Instead, it doesn't.
On mobile Chrome, it does (you need a wider screen, I get a suitable width by putting it in landscape orientation). On
Firefox (desktop) too.
Note that the text on the left is in a div that has "display:table" and "margin: 0 auto". So, the width of the div is determined by its content, and the margin is auto hence centering the box (rather than the text itself). Now, the margin is computed to the left border of the floating element on the right (as opposed to the right border of the page), but it is not updated when the width of the floating object on the right changes: that certainly does not make sense. And obviously, if the behavior on desktop and on mobile is different, one of them is wrong.
It seems pretty obvious that the desktop behavior is the wrong one because it's intrinsically inconsistent (if the margin is supposed to take into account the float on the right, as it does, then it must be updated when that float's width changes; if the margin were to be computed with respect to the container regardless of the float, well, it isn't).
NOTE: if you emulate mobile on Desktop with Developer Tools, unsurprisingly you'll observe the same (broken) behavior as on Desktop, not an accurate emulation of the behavior on mobile which is as expected.
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? N/A
Does this work in other browsers? Yes
Chrome version: 51.0.2704.106 Channel: stable
OS Version:
Flash Version: Shockwave Flash 22.0 r0
As usual, we web authors have to rewrite our code with shitty hacky workarounds for buggy browser behavior, and even accomodate for inconsistencies between mobile and desktop. Great. F*** the standards.
Attached screenshots:
1. on desktop before clicking on "foo". As expected.
2. on desktop after clicking on "foo". Broken.
3,4: same as 1,2 but with a wider window: it's still broken but the text doesn't overlap, just the text on the left doesn't move.
FF: on Firefox (Desktop) after clicking: expected behavior.
AND: on Chrome/Android after clicking: expected behavior.
|
Deleted:
1.png
5.2 KB
|
|
|
Deleted:
2.png
8.4 KB
|
|
|
Deleted:
3.png
5.0 KB
|
|
|
Deleted:
4.png
6.8 KB
|
|
|
Deleted:
FF.png
5.5 KB
|
|
|
Deleted:
AND.png
42.7 KB
|
Comment 1 by dtapu...@chromium.org
, Jul 18 2016