lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not ul, ol, menu, or dir block)

NEW
Unassigned

Status

()

Core
Layout: Block and Inline
--
major
19 years ago
6 months ago

People

(Reporter: Jason Eager, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, 4 keywords)

Trunk
css1, css2, DevAdvocacy, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.6b -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bae:20011119][Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases), [DevRel:P3], URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

19 years ago
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...

Updated

19 years ago
Assignee: troy → kipp
Priority: P1

Comment 1

19 years ago
P1 bugs are for crashers.
Severity: minor → normal
Status: NEW → ASSIGNED
Priority: P1 → P3
Target Milestone: M6

Updated

19 years ago
Severity: normal → critical
Priority: P3 → P2
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>
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>
I mean blocks within inlines.

Comment 5

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

Updated

18 years ago
Severity: critical → major
*** Bug 6126 has been marked as a duplicate of this bug. ***
Summary: ummm..lists have 1. 1. 1. 1. → {css1} ummm..lists have 1. 1. 1. 1.
*** Bug 6093 has been marked as a duplicate of this bug. ***
See also bug 3499.
[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.)
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?
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...
Note. The CSS2 numbering stuff is covered by bug 3247.

Comment 13

18 years ago
*** Bug 7384 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
*** Bug 8485 has been marked as a duplicate of this bug. ***
Summary: {css1} ummm..lists have 1. 1. 1. 1. → {list} {css1} ummm..lists have 1. 1. 1. 1.
Whiteboard: [TESTCASE]
*** Bug 9543 has been marked as a duplicate of this bug. ***
Created attachment 772 [details]
Very small testcase I made for a dupe of this.

Updated

18 years ago
Target Milestone: M15 → M9

Updated

18 years ago
QA Contact: petersen → chrisd

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 17

18 years ago
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.
Status: RESOLVED → REOPENED
Summary: {list} {css1} ummm..lists have 1. 1. 1. 1. → {list} {css1} ummm..lists have 0. 0. 0. 0.
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.
Resolution: FIXED → ---

Comment 19

18 years ago
Just fixed the tools page on www.mozilla.org. The web page was fixed,
not the bug.

Updated

18 years ago
Target Milestone: M9 → M10

Comment 20

18 years ago
Moved target milestone to M10, after Kipp's return.

Updated

18 years ago
Status: REOPENED → ASSIGNED

Updated

18 years ago
Severity: major → normal
Priority: P2 → P3

Updated

18 years ago
Target Milestone: M10 → M11

Updated

18 years ago
Target Milestone: M11 → M12

Updated

18 years ago
Target Milestone: M12 → M15

Comment 21

18 years ago
Updating to default Layout Assignee...kipp no longer with us :-(

Comment 22

18 years ago
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.
Summary: {list} {css1} ummm..lists have 0. 0. 0. 0. → {list} {css1} ummm.. display:list-item lists have 0. 0. 0. 0.
Summary: {list} {css1} ummm.. display:list-item lists have 0. 0. 0. 0. → {list} {css1} ummm.. display:list-item lists have 0. 0. 0. 0. [BLOCKER]
[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.]

Updated

18 years ago
Summary: {list} {css1} ummm.. display:list-item lists have 0. 0. 0. 0. [BLOCKER] → {list} {css1} [BLOCK] [BLOCKER] Display:list-item lists have 0. 0. 0. 0.

Comment 24

18 years ago
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?
Summary: {list} {css1} [BLOCK] [BLOCKER] Display:list-item lists have 0. 0. 0. 0. → [BLOCK] Display:list-item lists have 0. 0. 0. 0. {list} {css1} [BLOCKER]
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.
Keywords: css1
Comment hidden (spam)
Comment hidden (spam)

Updated

18 years ago
Whiteboard: [TESTCASE]

Updated

18 years ago
Summary: [BLOCK] Display:list-item lists have 0. 0. 0. 0. {list} {css1} [BLOCKER] → Display:list-item lists have 0. 0. 0. 0. {list}
Summary: Display:list-item lists have 0. 0. 0. 0. {list} → Display:list-item lists have 0. 0. 0. 0. {list} [BLOCK]

Comment 28

18 years ago
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster

Comment 29

17 years ago
Adding nsbeta2 keyword since there are a lot of duplicates.
Keywords: nsbeta2

Comment 30

17 years ago
[nsbeta2-]
Whiteboard: [nsbeta2-]

Comment 31

17 years ago
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?
Status: NEW → ASSIGNED

Comment 32

17 years ago
Created attachment 9009 [details]
a test case showing use of "counter-reset" attribute
'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?
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.
Whiteboard: [nsbeta2-] → [nsbeta2-] (py8ieh:delve into code)

Comment 35

17 years ago
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.
Target Milestone: M17 → Future
Summary: Display:list-item lists have 0. 0. 0. 0. {list} [BLOCK] → [LIST]Display:list-item lists have 0. 0. 0. 0.
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.
Keywords: css2
Whiteboard: [nsbeta2-] (py8ieh:delve into code) → [nsbeta2-] (py8ieh:delve into code, look further, make css2 test cases)
Comment hidden (offtopic)
QA Contact: chrisd → py8ieh=bugzilla
Comment hidden (offtopic)
(Reporter)

Comment 39

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

17 years ago
*** Bug 45768 has been marked as a duplicate of this bug. ***
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.
Keywords: nsbeta2 → mozilla1.0
OS: Windows NT → All
Hardware: PC → All
Summary: [LIST]Display:list-item lists have 0. 0. 0. 0. → [LIST] Display:list-item lists have 0. 0. 0. 0.
Whiteboard: [nsbeta2-] (py8ieh:delve into code, look further, make css2 test cases) → [Hixie-P3] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases)

Comment 42

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

16 years ago
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.'
Keywords: mozilla0.9.3
Whiteboard: [Hixie-P3] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases) → [Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases)
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW

Comment 45

16 years ago
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?
Priority: P3 → P5
Whiteboard: [Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases) → [bae:20011119][Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases)
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

16 years ago
so, if a counter isn't there, how does the UA know to increment a counter?
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

16 years ago
magic counters, cool -- I stand corrected

Comment 50

16 years ago
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?
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

16 years ago
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
Severity: normal → major
Priority: P5 → P2
Target Milestone: Future → mozilla0.9.9

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment hidden (offtopic)
Comment hidden (offtopic)

Comment 55

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

15 years ago
*** Bug 185713 has been marked as a duplicate of this bug. ***
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.)
*** Bug 187268 has been marked as a duplicate of this bug. ***
Summary: [LIST] Display:list-item lists have 0. 0. 0. 0. → [LIST] lists have 0. 0. 0. 0. when 'display: list-item's parent not block
*** Bug 190995 has been marked as a duplicate of this bug. ***
Summary: [LIST] lists have 0. 0. 0. 0. when 'display: list-item's parent not block → [LIST] lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not block)
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P2 → --
Target Milestone: mozilla1.1alpha → ---
*** Bug 219714 has been marked as a duplicate of this bug. ***
*** Bug 219716 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking1.6b+
Flags: blocking1.6b+
Flags: blocking1.6b-
> 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.

Updated

14 years ago
Keywords: mozilla1.0
Summary: [LIST] lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not block) → lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not block)
Blocks: 245635

Updated

13 years ago
Blocks: 272547

Updated

13 years ago
Attachment #772 - Attachment is obsolete: true
Depends on: 288704
Summary: lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not block) → lists have 0. 0. 0. 0. (e.g., when 'display: list-item's parent not ul, ol, menu, or dir block)
*** Bug 293174 has been marked as a duplicate of this bug. ***
*** Bug 309188 has been marked as a duplicate of this bug. ***
FWIW, this should be fixed by bug 288704, which I'd like to do for 1.9, time
permitting.
No longer blocks: 245635
*** Bug 245635 has been marked as a duplicate of this bug. ***

Comment 68

11 years ago
WFM with the attachment from comment 57.

Comment 69

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

10 years ago
(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

10 years ago
Still not fixed in Firefox 3b2 (and nightlies), Mozilla 1.9b2. It's been nearly 9 years now, any update on this bug? 
No.  If there were, you'd see it here.  It's too late for Firefox 3 at this point; hopefully next major release...

Updated

9 years ago
Duplicate of this bug: 436662
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline

Comment 74

8 years ago
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 :)
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

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

8 years ago
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.
This is actually a bug.

Comment 79

8 years ago
A bug, but not the bug in this report.

Comment 80

8 years ago
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.
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

8 years ago
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.
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

8 years ago
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.
(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
It's not.  The code for counters and the code for list-items are currently unrelated.
Blocks: 605520

Comment 87

5 years ago
Correspondent tests in CSS 2.1 test suite for this bug report
-------------------------------------------------------------

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-004.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-005.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-006.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-007.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-008.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-009.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-010.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-011.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-012.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-013.htm

http://test.csswg.org/suites/css2.1/latest/html4/list-style-type-014.htm
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.
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 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.
(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...
(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);
(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.
(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.
Duplicate of this bug: 918103

Comment 96

4 years ago
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?
Duplicate of this bug: 1129490
Comment hidden (offtopic)
Duplicate of this bug: 1161825
Blocks: 1171419
Duplicate of this bug: 1216045
Comment hidden (offtopic)
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.
Keywords: DevAdvocacy
Whiteboard: [bae:20011119][Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases) → [bae:20011119][Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases), [DevRel:P1]
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.
Whiteboard: [bae:20011119][Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases), [DevRel:P1] → [bae:20011119][Hixie-P2] (high profile: css1-in-xml blocker) (py8ieh:delve into code, look further, make css2 test cases), [DevRel:P3]
You need to log in before you can comment on or make changes to this bug.