Last Comment Bug 4522 - lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not ul, ol, menu, or dir block)
: lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not ul, ol, m...
Status: NEW
[bae:20011119][Hixie-P2] (high profil...
: css1, css2, DevAdvocacy, testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- major with 30 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.damowmow.com/playground/bu...
: 6093 6126 7384 8485 9543 45768 185713 187268 190995 219714 245635 293174 309188 436662 918103 1161825 (view as bug list)
Depends on: 288704
Blocks: css2.1-tests 1171419 272547
  Show dependency treegraph
 
Reported: 1999-04-03 23:13 PST by Jason Eager
Modified: 2016-07-20 12:57 PDT (History)
49 users (show)
dbaron: blocking1.6b-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Very small testcase I made for a dupe of this. (265 bytes, text/html)
1999-07-09 15:48 PDT, Jeremy Browne (no email)
no flags Details
a test case showing use of "counter-reset" attribute (544 bytes, text/html)
2000-05-22 16:14 PDT, buster
no flags Details
testcase showing 0.0.0.0. (230 bytes, text/html)
2002-12-21 14:00 PST, David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch)
no flags Details
Rendering in Internet Explorer 8 (16.66 KB, image/png)
2009-05-25 08:40 PDT, Helder "Lthere" Magalhães
no flags Details
Updated test case (968 bytes, application/xhtml+xml)
2009-08-06 21:09 PDT, Daniel Upstone
no flags Details
WIP (1.33 KB, patch)
2013-04-19 08:50 PDT, Daniel Glazman (:glazou)
no flags Details | Diff | Splinter Review

Description Jason Eager 1999-04-03 23:13:30 PST
Instead of tools listing

1. bugzilla,
2. bonzi
3. etc..

the M3 version does

1. bugzilla
1. bonzi.
1. etc...

this should be rather easy to fix...
Comment 1 kipp 1999-04-05 07:33:59 PDT
P1 bugs are for crashers.
Comment 2 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-04-06 09:43:59 PDT
Changed URL from http://www.mozilla.org/tools to
http://www.mozilla.org/tools.html since the former doesn't exist and the latter
shows the bug.

The HTML here is so massively invalid that I'm not sure what to think.  I guess
very generous error handling should somehow yield 1, 2, 3, etc., but I can't
say this is the highest priority.  The offending code isolated below, though it
could likely be simplified more.

<P><OL>
 <P><B><LI> <A HREF="cvs.html">CVS.</A></B><BR>

  text

 <P><B><LI> <A HREF="http://lxr.mozilla.org/">LXR.</A></B><BR>

  text

 <P><B><LI> <A HREF="bonsai.html">Bonsai.</A></B><BR>

  text

 <P><B><LI> <A HREF="tinderbox.html">Tinderbox.</A></B><BR>

  text

 <P><B><LI> <A HREF="bugs/">Bugzilla.</A></B><BR>

  text

</OL>
Comment 3 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-04-06 09:49:59 PDT
Here's a further simplification.  In the first case, you're numbering the list
1, 1, 1, 1.  In the second, you're not showing any bold.  (You can stick a <P>
in the second before the first LI and it won't change things.)

I think this is related to handling of inlines within blocks.

<OL>
 <B><LI> CVS</B>
 <B><LI> LXR</B>
 <B><LI> Bonsai</B>
 <B><LI> Tinderbox</B>
 <B><LI> Bugzilla</B>
</OL>

<OL>
 <LI> CVS
 <B><LI> LXR</B>
 <B><LI> Bonsai</B>
 <B><LI> Tinderbox</B>
 <B><LI> Bugzilla</B>
</OL>
Comment 4 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-04-06 09:50:59 PDT
I mean blocks within inlines.
Comment 5 kipp 1999-04-06 20:15:59 PDT
Here is another test case, without the block-in-inline issue (which is still
valid) that also demonstrates the same numbering problem:

<html>
 <head>
  <style>
   .ol { display: block; margin-left: 40px; }
   .p { display: block; margin: 1em 0; }
   .li { display: list-item; list-style-type: decimal; }
  </style>
 </head>
 <body>
  This demonstrates how nglayout doesn't count list items quite right...
  <div class=ol>
   <div class=p>
    <div class=li>
     This is a list item
    </div>
    <div class=li>
     This is a list item
    </div>
   </div>
   <div class=p>
    <div class=li>
     This is a list item
    </div>
    <div class=li>
     This is a list item
    </div>
   </div>
  </div>
 </body>
</html>
Comment 6 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-05-15 09:01:59 PDT
*** Bug 6126 has been marked as a duplicate of this bug. ***
Comment 7 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-05-17 19:15:59 PDT
*** Bug 6093 has been marked as a duplicate of this bug. ***
Comment 8 Hixie (not reading bugmail) 1999-05-18 07:50:59 PDT
See also bug 3499.
Comment 9 Hixie (not reading bugmail) 1999-05-19 14:03:59 PDT
[ccing dbaron for his opinion]

Hmm. How do we work out when to reset the counter?
i.e., if you think of display:list-item as an anonymous generated counter
as per CSS2's counters, where do you assume the "counter-reset" takes place?

I would suggest that we use one counter for the real lists (ol, ul, menu, dir),
and one counter for all other instances. We would of course have to use internal
versions of the counter properties, otherwise the counter-increment and counter-
reset properties would clash with our own internal counting. Below I have
prefixed these internal eqivalents with "-moz-".

Thus,
   UL, OL, MENU, DIR { -moz-counter-reset: proper-list-item; }
   LI { -moz-counter-increment: proper-list-item ! important; }
   :-moz-list-item { -moz-counter-increment: anonymous-list-item; }

...where ":-moz-list-item" matches anything with display:list-item. The cascade
will mean that normal LIs do not increment the anonymous counter (if they did,
all hell would break loose). The scoping of counters (see CSS2, section 15.5.1)
would mean that nesting lists would automatically work, even if they are nested
with <b> and <p> in stupid places.

This would mean that one could number headers, for example, by saying

   H2 { display: list-item; }

There would be a single counter for all uses of this, so the list that kipp
gives above would work. At the same time, it would not conflict with normal
use of list-item with LI.

Comments? (Note that we don't have to fully implement the counting stuff for
this to work -- the above only explains what the effect would be like in terms
of the CSS2 spec.)
Comment 10 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 1999-05-20 16:51:59 PDT
This doesn't quite sound like it will work (think nested lists, or something),
but I can't quite explain exactly why I think that.  Nor can I think of what
will.  I have to review the counters section anyway.  And will they even
be implemented?
Comment 11 Hixie (not reading bugmail) 1999-05-20 17:10:59 PDT
The scoping of counters (see CSS2, section 15.5.1) would mean that nesting
lists would automatically work.

The counting stuff doesn't _have_ to be implemented to use the suggestion above.
The suggestion only explain how things would appear to work, not how they would
actually be coded.

Of course, once the CSS2 numbering stuff is implemented, fixing this bug as
described above becomes negligably easy...
Comment 12 Hixie (not reading bugmail) 1999-05-26 06:47:59 PDT
Note. The CSS2 numbering stuff is covered by bug 3247.
Comment 13 John Morrison 1999-06-02 20:38:59 PDT
*** Bug 7384 has been marked as a duplicate of this bug. ***
Comment 14 Patrick C. Beard 1999-06-18 13:28:59 PDT
*** Bug 8485 has been marked as a duplicate of this bug. ***
Comment 15 Jeremy Browne (no email) 1999-07-09 15:42:59 PDT
*** Bug 9543 has been marked as a duplicate of this bug. ***
Comment 16 Jeremy Browne (no email) 1999-07-09 15:48:59 PDT
Created attachment 772 [details]
Very small testcase I made for a dupe of this.
Comment 17 kipp 1999-07-14 10:53:59 PDT
What an icky bug, and what icky html. Anyway, its fixed - I reworked the way we
scope lists in html and (for now) have a temporary hack to deal with malformed
content tree so that it numbers properly.
Comment 18 Hixie (not reading bugmail) 1999-07-17 09:56:59 PDT
The case of malformed HTML around <li> elements works now. However, the test
case you (Kipp) wrote which uses list-item to demonstrate the problem with well
formed HTML now generates lists numbered 0,0,0,0. It is as if only list-item
elements nested in <ol> elements increment the counter, instead of _any_ case
of a list-item element incrementing the counter.

Also, when display:list-item elements are nested in <li> elements, the
numbering interacts. That is, the numbering of <li>s and other list-items
are using the same counter (and are both being reset by <ol>). I strongly
suggest that they should use _different_ counters, as described above in
my comment dated 05/19/99.

I have created a test case based on the test HTML you give above. It is
available at:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/listitem.html
The test case carefully states which numbers should appear where, so it should
be immediately apparent where the problems lie.
Comment 19 Dawn Endico 1999-07-19 18:43:59 PDT
Just fixed the tools page on www.mozilla.org. The web page was fixed,
not the bug.
Comment 20 hamerly 1999-08-05 14:37:59 PDT
Moved target milestone to M10, after Kipp's return.
Comment 21 leger 1999-12-14 13:53:59 PST
Updating to default Layout Assignee...kipp no longer with us :-(
Comment 22 troy 1999-12-14 14:14:59 PST
Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.
Comment 23 Hixie (not reading bugmail) 1999-12-16 19:26:59 PST
[This is now blocking some of my XML work, as this bug renders list-item useless
in XML documents. I'm using CSS of the form:

   item:before { content: '1.'; }
   item + item:before { content: '2.'; }
   item + item + item:before { content: '3.'; }
   item + item + item + item:before { content: '4.'; }

...as a workaround for now, but this is obviously not very scalable.]
Comment 24 buster 1999-12-29 16:07:59 PST
This bug has been prioritized into the M17 bucket, meaning it won't be addressed
until after beta.  Could whoever marked this "BLOCKER"
(py8ieh=bugzilla@bath.ac.uk ?) please describe how serious a blocker this is,
and what exactly it is blocking?  For example, is it blocking development in the
code in some way, or is it blocking your particular application?
Comment 25 Hixie (not reading bugmail) 2000-01-07 16:59:59 PST
buster: This is not blocking code. It is blocking the authoring of any XML
documents which contain ordered lists (like <OL> <LI> in HTML). IOW if we do
not have this in by beta, then it will have to be an important release-notes
item as it will immediately surface whenever someone tries to use
   display: list-item
...with an XML document.

It is certainly not a dogfood item.

Note: As the original URL quoted no longer exhibits this problem, I am updating
it from:
   http://www.mozilla.org/tools.html
...to:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/listitem.html
...which is my test case for this bug.
Comment 26 Hixie (not reading bugmail) 2000-01-13 15:59:59 PST Comment hidden (spam)
Comment 27 ekrock's old account (dead) 2000-01-21 13:51:26 PST Comment hidden (spam)
Comment 28 buster 2000-03-03 16:08:53 PST
mine! mine mine mine!  all mine!  whoo-hoo!
Comment 29 karnaze (gone) 2000-05-17 14:59:28 PDT
Adding nsbeta2 keyword since there are a lot of duplicates.
Comment 30 Peter Trudelle 2000-05-22 15:25:34 PDT
[nsbeta2-]
Comment 31 buster 2000-05-22 16:13:27 PDT
Ian:  your xml test case would work if you included the sytle attribute:
counter-reset: some-counter-name 0;

I'll attach a test case that shows how this works, based on Kipp's original 
example in this bug.

So, the question becomes:  to get auto-generated list decoration to appear, 
should it be necessary for an author to specify *both* "display: list-item;" on 
the individual items, and "counter-reset: some-counter-name 0;" on the 
container?  Or, should we do something special when we see "display: list-item;" 
to cause default numbering of some sort to appear?
Comment 32 buster 2000-05-22 16:14:01 PDT
Created attachment 9009 [details]
a test case showing use of "counter-reset" attribute
Comment 33 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-05-22 16:52:29 PDT
'display: list-item' should be sufficient.  'display: list-item' is CSS1, while
'counter-reset' is a property added in CSS2, which has a more powerful counter
model.

Then, the interesting question is, what resets the counter?  A new parent?
Comment 34 Hixie (not reading bugmail) 2000-05-23 03:57:15 PDT
For display: list-item I would say that only :root and certain HTML elements 
reset the counter. See my comments dated 1999-05-19 14:03.

Note: There should not be a need to explicitly state counter-reset, since a
counter-reset is implied for every counter on :root.

Also, how do we know what counter name list-item is using??

I'm a little worried about how the counter-* properties are interacting with
list-item -- I thought we were not going to implement counter-* at all (see 
bug 3247) this release.
Comment 35 buster 2000-06-07 14:53:09 PDT
There were 2 separate issues in this bug.
1) an {ib} issue, where putting list-items inside of inline content confused the 
line numbering code.  that has been fixed separately by waterson's {ib} work.
2) forcing counter-reset on arbitrary tags based on display type.  currently, we 
only support lists when given "counter-reset: -html-counter", as on OL in 
HTML.CSS.  This needs to be extended to arbitrary styled tags.  That won't 
happen until after the first release.
Comment 36 Hixie (not reading bugmail) 2000-07-01 13:59:54 PDT
buster: What difference does the value passed to "counter-reset" make???

We can get the test case given above:

   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/listitem.html

...to work correctly just by including

   :root { counter-reset: some-counter-that-should-not-be-used; }

...in the stylesheet! This is very wrong per CSS2!!!

I don't mind having magical keywords to counter-reset that make list-item work,
but if we do that then we need to make it work sensibly -- for example, only
the "-moz-list-item" keyword should be recognised.

At the moment, the counter-reset property is working in a completely wrong way.
Comment 37 Jason Eager 2000-07-16 16:09:16 PDT Comment hidden (offtopic)
Comment 38 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2000-07-27 07:58:44 PDT Comment hidden (offtopic)
Comment 39 Jason Eager 2000-08-30 22:36:48 PDT
And now this type of problem is listed in bug 45768.

This was the first bug I ever submitted to mozilla, and it STILL hasn't been
fixed. :p 
Comment 40 Chris Waterson 2001-02-22 12:12:38 PST
*** Bug 45768 has been marked as a duplicate of this bug. ***
Comment 41 Hixie (not reading bugmail) 2001-02-22 17:25:04 PST
To recap: the bug is visible on this self-explanatory test case:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/listitem.html
The behaviour should be as I describe in my 1999-05-19 14:03 comment.
Comment 42 Sampo Syreeni 2001-04-06 03:36:15 PDT
I seem to be hitting a bit of a problem with the current implementation of list
numbering with li {counter-reset: -html-counter 0;}. I'm aiming for a
comprehensive CSS2 stylesheet on my site, so I end up with aggressive init
values for CSS2 properties: *|* {counter-reset:none; counter-increment:none}.
Since the CSS1 display:list-item mechanics should, as per the CSS2 spec, have no
interaction with CSS2 counters (i.e. in my reading they are not just anonymous
counters, but altogether invisible to the counter mechanism), this default
should not affect list numbering. Now it does. If CSS2 counters are not going to
be implemented anytime soon, it would seem sensible to hardcode the numbering
for display:list-item and disable the counter-* properties. Is this possible?
Comment 43 Chris Donica 2001-06-14 12:57:40 PDT
Could the target milestone on the bug be say, 0.9.2? Enumerated lists are CSS1,
and the XML implementation is not working at all. This a high profile bug with
regard to marking up XML, and it seems to have been around for quite some time
now. You can see in Ian 'Hixie' Hickson's example that it is still broken
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/listitem.html. In any
case, the target milestone should surely be earlier than 'future.'
Comment 44 Kevin McCluskey (gone) 2001-10-04 16:29:22 PDT
Build reassigning Buster's bugs to Marc.
Comment 45 rubydoo123 2001-11-20 17:28:48 PST
I did some testing with Ian's test case and it looks like Ian neglected to put a 
counter in for the li's, it also looks like there are some other oddities in the 
test case. As a quick and dirty test, try this:

<style>
.ol, ol { display: block; list-style-type: decimal; margin: 1em 0; padding-left: 
40px; counter-reset: -html-counter 0;}
.li, li { display: list-item; -moz-float-edge: margin-box; }
</style>

<div class=ol>
<div class=li>This is a list item (should be 1)</div>
<div class=li>This is a list item (should be 2)</div>
</div>

and you'll see the counter work

Ian, do you want to rework the test case?
Comment 46 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-11-20 17:40:23 PST
Ian's test case is perfectly valid and counter stuff should not be needed.  This
bug should definitely be more important than a P5.
Comment 47 rubydoo123 2001-11-20 17:46:48 PST
so, if a counter isn't there, how does the UA know to increment a counter?
Comment 48 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-11-20 17:48:49 PST
display: list-item is just supposed to work.  The counters stuff may even be
removed in future versions of CSS since nobody has implemented it.
Comment 49 rubydoo123 2001-11-20 17:54:07 PST
magic counters, cool -- I stand corrected
Comment 50 rubydoo123 2001-11-20 18:29:23 PST
but, I have a question for you -- why in our html.css do we use the counter:

ol {
  display: block;
  list-style-type: decimal;
  margin: 1em 0;
  padding-left: 40px;
  counter-reset: -html-counter 0;
}

and when I remove the counter-reset property it does not work for ol lists?
Comment 51 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2001-11-20 19:43:32 PST
Because there's something really wacky in our implementation.  That's what this
bug is a request to fix.  (Also note that nothing ever has 'counter-reset:
-html-counter'.)
Comment 52 rubydoo123 2001-11-21 07:40:57 PST
I get it! I just had a long talk with Daniel and we went over this bug. Now that 
I get it, I understand the severity of the issue.

this is bad! bumping this way up
Comment 53 Nicholas Riley 2002-04-27 18:36:10 PDT Comment hidden (offtopic)
Comment 54 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-04-27 19:20:43 PDT Comment hidden (offtopic)
Comment 55 Jonathan Bartlett 2002-06-21 17:09:55 PDT
Is this being worked on?  If you need another test case, you can look at
http://www.eskimo.com/~johnnyb/spiritual/UndirectedSystemicEvil.xml

I'd like to see this fixed, so if there's anything I can help on, let me know.
Comment 56 Daniel Cazzulino 2002-12-17 02:29:36 PST
*** Bug 185713 has been marked as a duplicate of this bug. ***
Comment 57 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2002-12-21 14:00:08 PST
Created attachment 109913 [details]
testcase showing 0.0.0.0.

This testcase shows a 0.0.0.0. case.  Is the problem that the list item's
parents are 'display:inline'?  (The problem also occurs if I add 'float: left'
to the rule matching LI.)
Comment 58 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-01-03 06:18:54 PST
*** Bug 187268 has been marked as a duplicate of this bug. ***
Comment 59 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2003-01-28 12:21:37 PST
*** Bug 190995 has been marked as a duplicate of this bug. ***
Comment 60 Boris Zbarsky [:bz] 2003-05-01 22:51:09 PDT
.
Comment 61 Mats Palmgren (vacation) 2003-09-19 11:56:17 PDT
*** Bug 219714 has been marked as a duplicate of this bug. ***
Comment 62 Mats Palmgren (vacation) 2003-09-19 16:15:35 PDT
*** Bug 219716 has been marked as a duplicate of this bug. ***
Comment 63 Boris Zbarsky [:bz] 2004-02-08 21:31:38 PST
> Is the problem that the list item's parents are 'display:inline'?

Yes.  All the numbering is handled by nsBlockFrame; start with
nsBlockFrame::RenumberLists and drill down (to the point where it calls
SetListItemOrdinal on the individual bullet frames.
Comment 64 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-05-08 11:41:43 PDT
*** Bug 293174 has been marked as a duplicate of this bug. ***
Comment 65 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-09-19 12:41:34 PDT
*** Bug 309188 has been marked as a duplicate of this bug. ***
Comment 66 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-09-19 14:06:01 PDT
FWIW, this should be fixed by bug 288704, which I'd like to do for 1.9, time
permitting.
Comment 67 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2005-09-25 11:12:00 PDT
*** Bug 245635 has been marked as a duplicate of this bug. ***
Comment 68 Jesse Ruderman 2007-02-03 21:32:38 PST
WFM with the attachment from comment 57.
Comment 69 Dag-Erling Smørgrav 2007-08-25 16:24:50 PDT
Still not fixed in 2.0.0.6, trivial to reproduce with e.g. the following XML + CSS combination:

http://www.des.no/mozilla/list-item.xml
http://www.des.no/mozilla/list-item.css

This should render as

1 One
2 Two
3 Three

but renders as

0. One
0. Two
0. Three

which is doubly wrong: the numbers shouldn't be zero, and they should not be followed by a period.
Comment 70 Dag-Erling Smørgrav 2007-08-25 16:26:05 PDT
(In reply to comment #69)
> Still not fixed in 2.0.0.6,

by which I meant Firefox 2.0.0.6, i.e. Mozilla 1.8.1.6.
Comment 71 u554791 2008-01-29 03:22:05 PST
Still not fixed in Firefox 3b2 (and nightlies), Mozilla 1.9b2. It's been nearly 9 years now, any update on this bug? 
Comment 72 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2008-01-29 09:52:38 PST
No.  If there were, you'd see it here.  It's too late for Firefox 3 at this point; hopefully next major release...
Comment 73 Daniel.S 2008-05-31 09:38:29 PDT
*** Bug 436662 has been marked as a duplicate of this bug. ***
Comment 74 u554791 2009-03-19 15:38:38 PDT
Still not fixed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3

Happy 10th birthday to this bug, slightly early :)
Comment 75 Helder "Lthere" Magalhães 2009-05-25 08:40:32 PDT
Created attachment 379568 [details]
Rendering in Internet Explorer 8 

Small status update:
 * IE8 renders attachment 9009 [details] as (intuitively) expected.
 * Opera 10 (Preview) and Safari 4 (Preview) don't but seem to be closer (both display "1. Third")...

Checked stable [1] and nightly [2] versions for sure: both (still) display zero'ed numbering.

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
[2] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090524 Minefield/3.6a1pre
Comment 76 Daniel Upstone 2009-08-06 21:09:31 PDT
Created attachment 393121 [details]
Updated test case

I've provided an updated test case which uses cleaner xhtml instead.

It now shows how this issue is because no counter is created on the parent element of elements with display: list-item. This means it will also use an existing list counter that is in scope (such as a parent ul/ol/dl) without creating a new scope for itself.

I haven't looked to see if this is actually a bug or just a lack of user expected handling (ie. something that is not defined/required for implementation).
Comment 77 Daniel Upstone 2009-08-06 21:25:29 PDT
I should point out attachment 109913 [details] (3rd test case) is so poorly marked up that it wouldn't be expected to be handled at all. It causing a similar result but has no relevance to this bug as it lacks any of the triggers and is unreliable.
Comment 78 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-08-06 22:47:01 PDT
This is actually a bug.
Comment 79 Daniel Upstone 2009-08-07 06:34:35 PDT
A bug, but not the bug in this report.
Comment 80 Daniel Upstone 2009-08-07 06:45:59 PDT
After checking through the css 2.1 spec, i can't find anything related to how to handle list-style-type numbering on elements with display: list-item.

The closest related handling is "If 'counter-increment' or 'content' on an element or pseudo-element refers to a counter that is not in the scope of any 'counter-reset', implementations should behave as though a 'counter-reset' had reset the counter to 0 on that element or pseudo-element."

Threfore this is an undefined situation, but could probably do with being handled more elegantly like other browsers and automaticlaly creating a counter-reset scope.
Comment 81 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-08-07 06:59:31 PDT
We don't implement display:list-item numbering in terms of counters (doing so is not specified in CSS 2.1), but doing that would be one of the possible ways of fixing this bug (see dependencies).
Comment 82 Daniel Upstone 2009-08-07 08:19:47 PDT
I imagined an internal counter not based on CSS counters was used and wasn't trying to suggest otherwise. I was only explaining how CSS 2.1 defines auto-matic numbering and custom counters to show what is expected from the UA.

What i'm pointing out is that the list-style-type behavoir of display: list-item on an element that isn't defined as such in the HTML spec by default (li, dt, dd) is not defined in CSS2.1. So the UA is not in error if it doesn't supply a counter for use or create a new scope, it's just not a very elegant solution if it doesn't.

By that reasoning, i don't believe this is that important a "bug" by itself, but if the dependency is fixed (which is more important) then this will be fixed anyway.
Comment 83 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-08-07 08:25:33 PDT
No, CSS 2.1 doesn't care at all about the HTML tag of the parent of something that's display:list-item; it has no distinct concept of parent-of-list-item, and list items should work in any parent.
Comment 84 Daniel Upstone 2009-08-07 16:33:08 PDT
display: list-item does work within custom parents, that's not an issue. A counter (internal or CSS) is not required to be supported on elements with display: list-item (defualt or explicitly defined) for automatic numbering by CSS.

Essentially, no where is support for auto-numbering on custom list items defined and that is what is being attempted here. It's only the pre-CSS behavior, defined by HTML, that causes the default list items to support auto-numbering internally.
Comment 85 Helder "Lthere" Magalhães 2009-08-08 02:37:08 PDT
(In reply to comment #76)
[...]
> It now shows how this issue is because no counter is created on the parent
> element of elements with display: list-item.
[...] 
> I haven't looked to see if this is actually a bug or just a lack of user
> expected handling (ie. something that is not defined/required for
> implementation).

I'd say this (the counter reset behavior) could be (related to) bug 288946 [1] (see its third comment and follow ups).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=288946#c3
Comment 86 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2009-08-08 07:23:09 PDT
It's not.  The code for counters and the code for list-items are currently unrelated.
Comment 88 Daniel Glazman (:glazou) 2013-04-18 02:01:09 PDT
Confirming this bug still stands. Plagues numbering of footnotes in
web documents and ebooks. From my tests, Gecko is the only desktop rendering
engine NOK on this. Safari, Chrome, Presto and IE10 all OK.
Comment 89 Daniel Glazman (:glazou) 2013-04-19 08:50:23 PDT
Created attachment 739623 [details] [diff] [review]
WIP

Ok, so apparently, everything in nsBlockFrame.cpp is ready to deal with
an arbitrary block hosting 'display: list-item' elements if you except the
fact nsBlockFrame::FrameStartsCounterScope() deals only with ul/ol/dir/menu.

In first approximation, and without looking at the performance impact, I would
say that adding code to FrameStartsCounterScope() looking if one of the child frames
have StyleDisplay()->mDisplay equal to NS_STYLE_DISPLAY_LIST_ITEM should do the
trick. Of course, that's a perf hit, not sure it's an acceptable one.
Maybe we need to set something on the parent when we resolve a list-item value
for the display property. That way we can easily avoid the perf hit.

I tested the attached patch. Works fine, as expected. Also works if you change
dynamically the display property from list-item to something else and vice-
versa. Numbering starts with the container and I think this is consistent with
what other rendering engines currently do.

Comments?
Comment 90 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2013-04-19 09:28:55 PDT
Comment on attachment 739623 [details] [diff] [review]
WIP

First, I'm worried about the performance implications of doing this.

Second, this is going to make nsBlockFrame::RenumberLists crash in some cases; see the comment there.


The long-term plan here was to switch list numbering to use counters.  I still think that's the right long term plan; the counters code is much more robust.  I think doing this requires implementing the 'counter-set' proposal which may not be written up yet, though.
Comment 91 Daniel Glazman (:glazou) 2013-04-19 09:51:28 PDT
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #90)
> Comment on attachment 739623 [details] [diff] [review]
> WIP
> 
> First, I'm worried about the performance implications of doing this.

Yes, absolutely, I said it immediately.

> Second, this is going to make nsBlockFrame::RenumberLists crash in some
> cases; see the comment there.

I don't really see where it could crash, I see no such comment there. Can you explain?

> The long-term plan here was to switch list numbering to use counters.  I
> still think that's the right long term plan; the counters code is much more
> robust.  I think doing this requires implementing the 'counter-set' proposal
> which may not be written up yet, though.

Sure. But Gecko being currently the only rendering engines not showing 1 2 3
for three consecutive 'display: list-item' arbitrary elements, I thought we
could do something more near-term until the long-term plan is implemented...
Comment 92 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2013-04-19 09:55:47 PDT
(In reply to Daniel Glazman (:glazou) from comment #91)
> > Second, this is going to make nsBlockFrame::RenumberLists crash in some
> > cases; see the comment there.
> 
> I don't really see where it could crash, I see no such comment there. Can
> you explain?

  nsGenericHTMLElement *hc = nsGenericHTMLElement::FromContent(mContent);
  // Must be non-null, since FrameStartsCounterScope only returns true
  // for HTML elements.
  MOZ_ASSERT(hc, "How is mContent not HTML?");
  const nsAttrValue* attr = hc->GetParsedAttr(nsGkAtoms::start);
Comment 93 Daniel Glazman (:glazou) 2013-04-19 10:07:27 PDT
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #92)

>   nsGenericHTMLElement *hc = nsGenericHTMLElement::FromContent(mContent);
>   // Must be non-null, since FrameStartsCounterScope only returns true
>   // for HTML elements.
>   MOZ_ASSERT(hc, "How is mContent not HTML?");
>   const nsAttrValue* attr = hc->GetParsedAttr(nsGkAtoms::start);

Ah I see. But we could always look for the element-generated blockframe ancestor, right?
There's the perf hit anyway. Acceptable for BlueGriffon, not for Firefox.
Comment 94 Daniel Glazman (:glazou) 2013-04-19 23:15:01 PDT
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #92)
> (In reply to Daniel Glazman (:glazou) from comment #91)
> > > Second, this is going to make nsBlockFrame::RenumberLists crash in some
> > > cases; see the comment there.
> > 
> > I don't really see where it could crash, I see no such comment there. Can
> > you explain?
> 
>   nsGenericHTMLElement *hc = nsGenericHTMLElement::FromContent(mContent);
>   // Must be non-null, since FrameStartsCounterScope only returns true
>   // for HTML elements.
>   MOZ_ASSERT(hc, "How is mContent not HTML?");
>   const nsAttrValue* attr = hc->GetParsedAttr(nsGkAtoms::start);

Ok, I still don't get how this can crash with my change since this code
will be executed only if FrameStartsCounterScope returns true and that
happens only for a HTML element; that is not modified, my change happening
only after the HTML test in FrameStartsCounterScope.
Comment 95 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2013-09-18 16:42:08 PDT
*** Bug 918103 has been marked as a duplicate of this bug. ***
Comment 96 Alex G 2013-10-04 13:47:35 PDT
I created an account purely for the sake of this bug. I don't understand why this bug is not a priority, it clearly has a reasonably broad scope of use-cases where it will cause misrepresentation of listed information, and there has clearly been enough time for someone to find a workaround. Please help me understand, why has this bug gone unfixed for 14 years while other browsers handle it easily?
Comment 97 Daniel Holbert [:dholbert] 2015-02-05 13:57:59 PST
*** Bug 1129490 has been marked as a duplicate of this bug. ***
Comment 98 javier 2015-05-04 13:06:35 PDT Comment hidden (offtopic)
Comment 99 Daniel Holbert [:dholbert] 2015-05-06 18:24:21 PDT
*** Bug 1161825 has been marked as a duplicate of this bug. ***
Comment 100 Boris Zbarsky [:bz] 2015-10-19 06:30:53 PDT
*** Bug 1216045 has been marked as a duplicate of this bug. ***
Comment 101 kenny 2015-11-02 14:47:04 PST Comment hidden (offtopic)
Comment 102 Jen Simmons [:jensimmons] 2016-07-19 13:55:26 PDT
I'm creating demos of CSS Grid, and the ordered-list numbers are all 0. This is bad.

Here's a test case: http://labs.jensimmons.com/examples/image-gallery-grid-1-bug-demo.html

When display; block ruled the layout kingdom, we might have been able to get away with this. But now that display: grid is set to take over a lot of the layout territory, I expect this bug to come up much more often. Let's fix it as soon as we can.
Comment 103 David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) 2016-07-19 19:05:13 PDT
I think the best way to fix this is to fix bug 288704, i.e., to reimplement list numbering using our counters implementation, at least in the long term.

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