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




20 years ago
3 months ago


(Reporter: christinehoff4, Unassigned)


(Blocks 2 bugs, 4 keywords)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [CSS1-5.4.6][CSS1-5.6.5])


(1 attachment)



20 years ago
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 

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 
(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 
aligns markers as well.

Comment 1

20 years ago


20 years ago
Keywords: css2
Summary: Text-align: right/center aligns list marker incorrectly when list-style-position is 'outside' → Text-align: right/center aligns list marker incorrectly when list-style-position is 'outside'
Changing keyword from css2 to css1.
Keywords: css2css1

Comment 3

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

Assignee: pierre → kipp
Component: Style System → Layout

Comment 4

20 years ago
CSS-1, but relatively obscure.  So it can wait until after beta to fix.
Target Milestone: M16

Comment 5

20 years ago
kipp is very unlikely to fix these, since he's not working ont he project any 
longer.  so I'll take a look.
Assignee: kipp → buster

Comment 6

19 years ago
if this stays in my list, it won't make beta2
Target Milestone: M16 → M18

Comment 7

19 years ago
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19

Comment 8

19 years ago
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.
Target Milestone: M19 → Future
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.
Keywords: testcase
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...
QA Contact: chrisd → ian
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Whiteboard: [CSS1-5.4.6][CSS1-5.6.5]
Note that CSS2 does not specify the rendering well, but we're violating the
proposed CSS3...
Component: Layout → Layout: Block & Inline
Assignee: attinasi → block-and-inline
Priority: P3 → --
Target Milestone: Future → ---
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline

Comment 15

7 years ago
I submitted


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:



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

3 years ago
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

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


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 .
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.
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.
Quickly summarized, for input `<ul><li style="text-align: right">a</ul>`

Firefox still renders:
(item marker bullet is stuck to the right aligned text),
whereas "All Other Browsers™" renders:
(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.
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.

wpt.fyi showing the WPT testcase here (with all browsers but Firefox passing):

You need to log in before you can comment on or make changes to this bug.