1604327 - text-combine-upright breaks up between counter() function and text in pseudo-element

Status: RESOLVED FIXED

(Core :: Layout: Generated Content, Lists, and Counters, defect)

Description

[Xidorn Quan [:xidorn] UTC+10]

Attachment: testcase

See the attached testcase. It uses text-combine-upright on a ::before with content being a concatenation of counter() and string.

Expected result:
The number and dot should be displayed together taking only one character space.

Actual result:
The number and dot are displayed separately taking space of two characters.

Comment 1

[Jonathan Kew [:jfkthame]]

This is an aspect of the issue described at https://www.w3.org/International/jlreq/gap-analysis/#issue170_lists. We handle such list markers OK in simpler cases, but still fail with examples like the testcase here.

Comment 2

[Jonathan Kew [:jfkthame]]

This happens because the content of the text-combine-upright-formatted pseudo contains multiple generated content nodes (for the counter value and the literal string); these result in multipe textframes (even though they share the same style); and our text-combine-upright layout support deals only with a single frame.

Even a content property that just has multiple literal string items will suffer the same issue:

data:text/html,<style>p{writing-mode:vertical-lr} p::before{text-combine-upright:all;content:'a' 'b' 'c'}</style><p>hello

would be expected to render the same as:

data:text/html,<style>p{writing-mode:vertical-lr} p::before{text-combine-upright:all;content:'abc'}</style><p>hello

but it fails: we get 'a', 'b', and 'c' stacked up as three separate "upright" items, instead of combined into a single upright cell.

This works as expected in Chrome.

Comment 3

[Jonathan Kew [:jfkthame]]

I guess there are two possible approaches to fixing this:

(a) rework our layout support for text-combine-upright frames so that multiple adjacent textframes that all share the same style are treated as a single combined unit; or

(b) rework the frame generation for generated-content items so that successive items that all generate text are collected into a single node and hence textframe.

Comment 4

[Jonathan Kew [:jfkthame]]

After looking into what would be involved in each of the approaches in comment 3, I concluded that enhancing the textframe layout support will be substantially easier and less invasive/risky than attempting to merge generated-content nodes at frame-construction time. So I'll put up a patch that implements it this way.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1604327 - Handle text-combine-upright when the text comes from multiple generated-content items (e.g. a counter value plus literal text). r=#layout-jp-market-reviewers

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a39015ecd86c
https://hg.mozilla.org/integration/autoland/rev/14d286a84263
Handle text-combine-upright when the text comes from multiple generated-content items (e.g. a counter value plus literal text). r=TYLin

Comment 7

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/14d286a84263