{inc} Inconsistent layout (skinny vs. wide) at https://jeancharlot.org/20191119_stylesheet.css.html#css_set (fixed when you zoom in/out)
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
()
Details
Attachments
(3 files)
[originally reported as https://github.com/webcompat/web-bugs/issues/55625 ]
STR:
- Use a fresh profile (I needed to do so in order to trigger the bug, at least)
- Visit https://jeancharlot.org/20191119_stylesheet.css.html#css_set (specifically the part of the page pointed to by that anchor, near the text
Minimally markup a set of CSS rules - Zoom in, and then zoom out.
ACTUAL RESULTS:
After step 2 (at pageload), the Sample code block is sized to be ~1 character wide.
After I zoom in, it snaps to be a reasonable size, and it stays that size after I zoom out again.
In other words, our layout is inconsistent/unstable - we have a bug where incremental reflow differs from the initial reflow, it seems.
EXPECTED RESULTS:
Stable results. Users and the site author probably expect the content to be wide, but I'm not sure whether the wide rendering or the skinny rendering are correct.
For what it's worth, Chrome/Blink seems to match the broken-looking "skinny" rendering, while Safari/WebKit seems to match the better-looking "wide" rendering. Neither of them change behavior on zoom-in/out (but we do, hence this bug).
| Reporter | ||
Comment 1•5 years ago
|
||
| Reporter | ||
Comment 2•5 years ago
|
||
Comment 3•5 years ago
|
||
This is ::first-line intrinsic sizes again, I think. The page has:
.css > code::first-line, .css-list pre > code::first-line { font-size: 0 }
So we end up with an intrinsic size of zero even for the non-first-line things.
Comment 4•5 years ago
|
||
Yeah, bingo.
| Reporter | ||
Comment 5•5 years ago
|
||
Thanks! Seems like a dependency or even a dupe -- upgrading "see-also" to dupe to avoid having multiple bugs on the same platform issue.
Description
•