Add WPT testcase for text-indent not affecting tab-stop positions [was: Collapsing tab spaces in text with negative indentation]
Categories
(Core :: Layout: Text and Fonts, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox69 | --- | fixed |
People
(Reporter: notlmn, Assigned: jfkthame)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Steps to reproduce:
Applying negative text indentation to text with leading white-spaces collapses tab characters.
Visit https://jsbin.com/jelomov/edit?html,css,output.
Actual results:
The second line in the bin above should be indented to the same level as the lines before and after it. But the tab characters in the leading spaces for line 2 are collapsed possibly because of mixed tab and space characters at the start of the line.
Expected results:
The computed values for padding-left and text-indent are exactly equal and opposite in values, from which one would expect that the text would stay where it is intended to be.
Relevant GitHub issue: https://github.com/sindresorhus/refined-github/issues/2085.
Specific comment with more info: https://github.com/sindresorhus/refined-github/issues/2085#issuecomment-496445296.
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
|
||
Comment 1•5 years ago
|
||
Yeah, it looks like text-indent and -moz-tab-size are interacting in peculiar ways. Just play with the text-indent value in this test-case to see that it only jumps in multiples of the tab size, which is really weird.
|
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 2•5 years ago
|
||
Actually, I think it's Chrome (and Safari) that has weird behavior here. It looks like they're measuring tab-stop positions from the end of the text-indent, rather than from the starting edge of the block as required by the spec.
See https://codepen.io/anon/pen/VOgapd: here we can see that Firefox maintains the same tab-stop positions in all lines of the paragraph, regardless of whether the first line has a text-indent, whereas Chrome shifts the tab-stops in the first line because it is measuring from the end of the indent. I think that's wrong.
could you make sure there's a chromium bug on file for that if there isn't one already?
|
|
||
Comment 4•5 years ago
|
||
As an author I'd expect WebKit's behavior, but yeah, that clearly goes against the spec...
|
|
Assignee | |
Comment 5•5 years ago
|
||
As an author, I'd think webkit's behavior very strange. If I set tab positions for a paragraph of text in a page layout applications, and then give the paragraph a first-line indent, I don't expect the tab stops in the first line to shift in response; I expect them to stay aligned with the tab stops throughout the block.
(I checked in both LibreOffice and Pages, and confirmed they behave as I would expect: tab stops are unaffected by indents.)
I couldn't find a chromium bug, so filed https://bugs.chromium.org/p/chromium/issues/detail?id=969616.
|
|
Assignee | |
Comment 6•5 years ago
|
||
I don't see any WPT coverage for the issue of (non-)interaction of text-indent and tab stop positions, so I suggest we add a testcase. This will highlight the non-interoperability between Firefox and Chrome here, with Firefox (IMO) being correct.
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
|
Assignee | |
Comment 8•5 years ago
|
||
So I think the bug as originally filed here was invalid. Altering the text-indent will not affect where tabbed text appears, unless the indent is so great that it moves the text past a tab stop -- at which point it'll jump to the next tab stop. And if you use a tab to indent a line of text, but then use a negative text-indent to shift the start of the text before the block's start edge, the first tab will now advance to the original start edge (the "zeroth" tab stop, measured from that origin).
Morphing the bug title to indicate that all we're doing here is adding a testcase, not "fixing" Gecko behavior as AFAICT it's not broken.
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c79daa14e311 Add WPT reftest for interaction of text-indent and tab stop positions. r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/17136 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
|
||
Comment 12•5 years ago
|
||
| bugherder | ||
Upstream PR merged
|
||
Updated•5 years ago
|
|
Reporter | |
Comment 14•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #2)
Actually, I think it's Chrome (and Safari) that has weird behavior here. It looks like they're measuring tab-stop positions from the end of the text-indent, rather than from the starting edge of the block as required by the spec.
See https://codepen.io/anon/pen/VOgapd: here we can see that Firefox maintains the same tab-stop positions in all lines of the paragraph, regardless of whether the first line has a text-indent, whereas Chrome shifts the tab-stops in the first line because it is measuring from the end of the indent. I think that's wrong.
I see now.
But If that were the case, how do I specify to the browser to ignore tab-stops and always render tab characters at the specified tab-size width. If the user-agent by default aligns text based on tab-stops, do I have a way to disable that behavior!?
Just a question, for fixing https://github.com/sindresorhus/refined-github/issues/2085.
|
|
Assignee | |
Comment 15•5 years ago
|
||
(In reply to notlmn from comment #14)
But If that were the case, how do I specify to the browser to ignore tab-stops and always render tab characters at the specified
tab-sizewidth. If the user-agent by default aligns text based on tab-stops, do I have a way to disable that behavior!?
That's simply not how tabs work; if you want a specific width, regardless of where the tab occurs in the line, I think you'd need to expand it to a fixed number of or convert it to an inline-block span with a specified width, or something like that.
Description
•