25291 - Text-align: right/center aligns list marker incorrectly when list-style-position is 'outside'

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect, P3)

Description

[Christine Hoffman]

Testing on the following:

Windows: 01-25-20-m13
Mac: 01-26-03-m13
Linux: 01-25-20-m13

Behavior is across platform. Steps to reproduce:

Open attached file. Testcase provided by Pierre (I added center alignment). The 
testcase tests the effect of list markers when text-align is applied to a list 
item. 

Expected result:
(1) List-style-position: outside; text-align: right/left/center
The outside markers should remain on the left side with text aligned to the 
right/left/center
(2) List-style-position: inside; text-align: right/left/center
The inside markers should align to the right/left/center

Actual results:
When list-style-position is 'outside', right and center text alignment 
incorrectly 
aligns markers as well.

Comment 1

[Christine Hoffman]

Attachment: testcase to demonstrate problem

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Changing keyword from css2 to css1.

Comment 3

[Pierre Saslawsky]

That's a line layout problem. Reassigned to Kipp's list.

Comment 4

[buster]

CSS-1, but relatively obscure.  So it can wait until after beta to fix.

Comment 5

[buster]

kipp is very unlikely to fix these, since he's not working ont he project any 
longer.  so I'll take a look.

Comment 6

[buster]

if this stays in my list, it won't make beta2

Comment 7

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 8

[buster]

This bug has been marked "future" because we have determined that it is not 
critical for netscape6.0. 
If you feel this is an error, or if it blocks your work in some way -- please 
attach your concern to the bug for reconsideration.

Comment 9

[Hixie (not reading bugmail)]

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.

Comment 10

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 11

[Kevin McCluskey (gone)]

Build reassigning Buster's bugs to Marc.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Note that CSS2 does not specify the rendering well, but we're violating the
proposed CSS3...

Comment 13

[Boris Zbarsky [:bzbarsky]]

.

Comment 14

[Ghodmode]

Encountered on css-discuss mailing list : http://css.2040035.n2.nabble.com/Background-image-not-displaying-in-correct-position-tp7333830p7335461.html

Comment 15

[Gérard Talbot]

I submitted

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/list-style-position-018.html

which was removed, retracted from the CSS 2.1 test suite because of Erratum 61 which states

"the constraints on the position of 'outside' markers are relaxed for some values of 'text-align'"

More info:

http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0191.html

http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0197.html

So, I think this bug report should be resolved somehow, otherwise css1 keyword should be removed and css3 keyword should be added.

Gérard Talbot

Comment 16

[Rick Byers]

I just hit this here: https://github.com/GoogleChrome/chromium-dashboard/issues/306

Eg. if you have a list with padding:0 and text-align:center, Firefox shows markers but Chrome, Safari, and Edge do not.  http://jsbin.com/xejepez

The above erratum does not appear to be in the current version of the spec (https://drafts.csswg.org/css-lists-3/#list-style-position-property), so perhaps the test case should be added back to the test suite, with Firefox failing?

Comment 17

[Rick Byers]

There are a bunch of spec bugs that are making it a little hard for me to interpret the exact spec behavior:

https://github.com/w3c/csswg-drafts/issues/311
https://github.com/w3c/csswg-drafts/pull/312

Nonetheless, firefox dev tools says the element's computed style is "display: list-item" (not display: inline-list-item) and so I believe the Edge/Chrome/Safari behavior is correct and this is indeed a Gecko bug .

Comment 18

[Sam Sneddon [:gsnedders]]

The 2.1 REC is clear on this (though this wasn't intentional, it had been meant to be undefined far as anyone can remember!), but the WG has now resolved on outside bullets being outside the box. As such, this is a 2.1 compliance bug. Gérard's test case is now back in the 2.1 testsuite, FWIW.

Comment 19

[Gérard Talbot]

Test
http://test.csswg.org/suites/css2.1/nightly-unstable/html4/list-style-position-018.htm

Reference file
http://test.csswg.org/suites/css2.1/nightly-unstable/html4/list-style-position-018-ref.htm

Blocking 605520

Comment 20

[Gérard Talbot]

Corrected link (Reference file):
http://test.csswg.org/suites/css21_dev/nightly-unstable/html4/reference/list-style-position-018-ref.htm

Comment 21

[Manuel Rego Casasnovas]

Just for your information, the test from Gérard Talbot passes in Chrome, Safari, Edge and IE (since version 9, not in version 8).
Firefox seems to be the only one failing.

Comment 22

[Michal Čaplygin [:myf]]

Quickly summarized, for input `<ul><li style="text-align: right">a</ul>`

Firefox still renders:
>_____•a
(item marker bullet is stuck to the right aligned text),
whereas "All Other Browsers™" renders:
>•_____a
(item marker bullet is placed on the left edge).

Authoritative statement telling that All Other Browsers™ are right in this case is most probably seen in
https://lists.w3.org/Archives/Public/www-style/2016Jul/0051.html :

> Testcase for text-align: right + list-style: outside
>  - RESOLVED: Outside bullets are outside the box.

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

One interesting piece is figuring out how to differentiate this case from the case of list items flowing around floats, where I believe the bullets somewhat interoperably do move.

Comment 24

[Daniel Holbert [:dholbert]]

wpt.fyi showing the WPT testcase here (with all browsers but Firefox passing):
https://wpt.fyi/results/css/CSS2/lists/list-style-position-018.xht

Comment 25

[Gérard Talbot]

Test
http://wpt.live/css/CSS2/lists/list-style-position-018.xht

Reference file
http://wpt.live/css/CSS2/lists/list-style-position-018-ref.xht

Comment 26

[Gérard Talbot]

Firefox 112.0a1 buildID=20230312211644 passes this test. Firefox 113's test success is also noticed in

https://wpt.fyi/results/css/CSS2/lists/list-style-position-018.xht

Comment 27

[Gérard Talbot]

Firefox 112.0a1 buildID=20230312211644 passes all the tests I have.

Resolving as WORKSFORME

Comment 28

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/86df8974c5e5
[fenix] For https://github.com/mozilla-mobile/fenix/issues/25291 - Create a TextButton composable component
https://hg.mozilla.org/releases/mozilla-beta/rev/0309452230d6
[fenix] For https://github.com/mozilla-mobile/fenix/issues/25291 - Swap the new TextButton composable into WallpaperSettings