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.
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'
That's a line layout problem. Reassigned to Kipp's list.
Assignee: pierre → kipp
Component: Style System → Layout
CSS-1, but relatively obscure. So it can wait until after beta to fix.
Target Milestone: M16
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
if this stays in my list, it won't make beta2
Status: NEW → ASSIGNED
Target Milestone: M16 → M18
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19
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.
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
Status: ASSIGNED → NEW
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
Encountered on css-discuss mailing list : http://css.2040035.n2.nabble.com/Background-image-not-displaying-in-correct-position-tp7333830p7335461.html
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
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?
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 .
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.
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
Corrected link (Reference file): http://test.csswg.org/suites/css21_dev/nightly-unstable/html4/reference/list-style-position-018-ref.htm
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: >_____•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.
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.
You need to log in before you can comment on or make changes to this bug.