[css-writing-modes] content area of inline inside an absolutely positioned block is not precisely painted
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | affected |
People
(Reporter: bugzilla, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: testcase)
Tests
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/inline-content-area-abspos-vrl-001.html
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/inline-content-area-abspos-vrl-002.html
Actual result
2 vertical red lines inside big green filled square
Expected result
Notes
- original test that lead me to create these tests is
https://web-platform-tests.live/css/css-writing-modes/relpos-inline-overflowing-block-vrl.html - the 2 tests presume that tester will have either Liberation Mono font or Courier New font installed on his/her system
- Chromium 73.0.3683.75 and Chromium 76.0.3777.0 pass the 3 tests
- Firefox 60.6.1 ESR and Firefox 68.0a1 buildID=20190425220817 fail the 3 tests
- If you toggle ON and OFF the writing-mode declaration, you can see that Firefox 60 and 68 pass the 2 tests when 'writing-mode: vertical-rl' is turned OFF
- I think absolute positioning has nothing to do with this defect but rather with how content area of an inline is positioned and painted inside a line box in a VRL block
- I searched for duplicates and did not find any... although some of the bug reports I created before are close to this one.
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
I'm pretty sure there's another open bug about the same issue... And I think I remember jfkthame having a reasonable explanation for our behavior.
Reduced testcase, where we draw red stripes on my machine but Chrome does not:
data:text/html,<div style="writing-mode:vertical-rl; background:red;font:128px monospace"><span style="background:green">A
Actually, we draw smaller red stripes in a horizontal writing-mode version of this^^ reduced testcase, too (and Chrome does not):
data:text/html,<div style="float:left;background:red;font:128px monospace"><span style="background:green">A
jfkthame, do you recall what's going on here?
Comment 2•6 years ago
|
||
(FWIW, Chrome also draws red stripes if I use font-family "serif" in the original testcase & in my reduced testcases in comment 1.)
Comment 3•6 years ago
|
||
I've definitely seen this before. It's somehow related to font ascent/descent/line-gap metrics, I guess, together with baseline positioning, and maybe other stuff... there's a lot that's ill-defined in this area, partly because fonts may contain multiple conflicting versions of various metrics, and partly because of historical differences in how platforms handle them, and the tension between trying to follow platform conventions vs trying to provide cross-platform consistency.
Some observations:
-
Adding
text-orientation:sideways
alongside thewriting-mode
property will generally make the vertical-mode behavior more similar to horizontal, as it changes the default baseline alignment from ideographic-centered (which doesn't really suit the rotated-Latin text very well) to alphabetic-baseline. -
Results vary between platforms and between fonts, and if you use generics like
monospace
orserif
they may vary depending on local browser prefs and locale. -
On my macOS machine, at least, I can see similar red stripes even in a horizontal example with Chrome or Safari if I use some other fonts, e.g. Monaco:
data:text/html,<div style="float:left;background:red;font:128px Monaco"><span style="background:green">A
shows red stripes at top and bottom in all browsers. In general, it's not safe to assume that the block-size of the line will tightly wrap the block-size of the span within it.
-
In vertical mode:
data:text/html,<div style="float:left;background:red;font:128px Monaco;writing-mode:vertical-lr">
<span style="background:green">A
gives me substantially fatter red bars in Firefox, whereas in Chrome and Safari they're similar to the horizontal case. I think the difference in Firefox is somehow related to trying to apply a centered baseline.
-
Adding
text-orientation:sideways
makes the Firefox rendering more like the other browsers again:data:text/html,<div style="writing-mode:vertical-lr;text-orientation:sideways;float:left;background:red;
font:128px Monaco"><span style="background:green">A -
If we append another
<span>
with a different size:data:text/html,<div style="writing-mode:vertical-lr;float:left;background:red;font:128px Monaco">
<span style="background:green">A<span style="font-size:32px">B
it becomes clear that Safari is applying an alphabetic baseline, whereas Firefox and Chrome use a vertically-centered one. ISTR that Chrome used to use the alphabetic baseline in this case, and then changed; possibly the block-size extent of the span is still computed on that basis, however?
Anyhow, in summary I think there's certainly bugs and ill-defined behavior in this area, but I think it'll take some in-depth investigation to figure out all the factors, and to determine exactly what tests are valid and reliable. Given that the exact treatment of font metrics is not clearly specified, it may be difficult to construct font-based tests that can really be relied on universally.
Comment 4•6 years ago
|
||
Thanks, Jonathan!
(In reply to Jonathan Kew (:jfkthame) from comment #3)
In general, it's not safe to assume that the block-size of the line will tightly wrap the block-size of the span within it.
This ^^ seems to be the bottom line. These proposed web-platform-tests absolutely make this assumption (i.e. they assume that the block-size of the line will wrap the block-size of the span), and they rely heavily on it -- and it's apparently an unjustified assumption.
(Not sure what that means for this bug report; we could leave it open as a known interop issue I suppose, though I'm not sure what the next steps would be and I suspect it'd be pretty low-priority given the real-world impact.)
Reporter | ||
Comment 5•6 years ago
|
||
It's somehow related to font ascent/descent/line-gap metrics,
I guess, together with baseline positioning
It must be.
These proposed web-platform-tests
It was not clear in my mind if I was to submit my tests. But Morten Stenshorne has submitted relpos-inline-overflowing-block-vrl.html (admittedly a not-so-clear and not-much-reduced test) to WPT.
Daniel, If I take your first (and better!) reduced test and modify it a bit like this:
data:text/html,<div style="writing-mode:vertical-rl;background:red;font:128px 'Liberation Mono','Courier New',monospace;float:left;"><span style="background:green">Z
then Firefox 60 displays red when 'writing-mode:vertical-rl' declaration is toggled ON while Chrome 73 does not; this remains true if font size is increased or decreased. If 'writing-mode:vertical-rl' declaration is toggled OFF, then both Firefox 60 and Chrome 73 do not display red.
I do not know of a Linux equivalent font for Monaco font.
Comment 6•6 years ago
|
||
(In reply to Gérard Talbot from comment #5)
But Morten Stenshorne has submitted relpos-inline-overflowing-block-vrl.html (admittedly a not-so-clear and not-much-reduced test) to WPT.
Yeah -- we should perhaps push back on that test (or just ignore it).
data:text/html,<div style="writing-mode:vertical-rl;background:red;font:128px 'Liberation Mono','Courier New',monospace;float:left;"><span style="background:green">Z
then Firefox 60 displays red when 'writing-mode:vertical-rl' declaration is toggled ON while Chrome 73 does not; this remains true if font size is increased or decreased. If 'writing-mode:vertical-rl' declaration is toggled OFF, then both Firefox 60 and Chrome 73 do not display red.
Sure, but: if you add text-orientation:sideways
to that data URL, then Firefox (Nightly version 68) does not display red anymore, since that changes the baseline-alignment behavior, as jfkthame observed in his 1st and 5th bullet point in comment 3.
Anyway: given the underspecified-ness, the precise font dependencies, and the fact that other browsers (e.g. Chrome) show the exact same issue depending on the font: it's not obvious to me that there's a bug to be fixed here. (Though this does represent a minor interop issue at least, for sites that provide their own fonts & make very specific assumptions about font metrics.)
Updated•2 years ago
|
Description
•