Closed Bug 4522 Opened 25 years ago Closed 5 years ago

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

Categories

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

Product:
Core
Component:
Layout: Block and Inline
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 288704

People

(Reporter: jce2, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

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

Attachments

(5 files, 1 obsolete file)

a test case showing use of "counter-reset" attribute
544 bytes, text/html
Details
testcase showing 0.0.0.0.
230 bytes, text/html
Details
Rendering in Internet Explorer 8
16.66 KB, image/png
Details
Updated test case
968 bytes, application/xhtml+xml
Details
WIP
1.33 KB, patch
Details | Diff | Splinter Review 
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...
Assignee: troy → kipp
Priority: P1
P1 bugs are for crashers.
Severity: minor → normal
Status: NEW → ASSIGNED
Priority: P1 → P3
Target Milestone: M6
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>
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>
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. ***
[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.
*** Bug 7384 has been marked as a duplicate of this bug. ***
*** 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.
*** Bug 9543 has been marked as a duplicate of this bug. ***
Target Milestone: M15 → M9
QA Contact: petersen → chrisd
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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 → ---
Just fixed the tools page on www.mozilla.org. The web page was fixed,
not the bug.
Target Milestone: M9 → M10
Moved target milestone to M10, after Kipp's return.
Status: REOPENED → ASSIGNED
Severity: major → normal
Priority: P2 → P3
Target Milestone: M10 → M11
Target Milestone: M11 → M12
Target Milestone: M12 → M15
Updating to default Layout Assignee...kipp no longer with us :-(
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.]
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.
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?
URL: http://www.mozilla.org/tools.html → http://www.bath.ac.uk/%7Epy8ieh/inter...
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
Whiteboard: [TESTCASE]
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]
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster
Adding nsbeta2 keyword since there are a lot of duplicates.
Keywords: nsbeta2
[nsbeta2-]
Whiteboard: [nsbeta2-]
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
'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)
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)
QA Contact: chrisd → py8ieh=bugzilla
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 
*** 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)
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?
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
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.
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.
magic counters, cool -- I stand corrected
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'.)
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
Target Milestone: mozilla0.9.9 → mozilla1.1
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.
*** Bug 185713 has been marked as a duplicate of this bug. ***
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. ***
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.
URL: http://www.bath.ac.uk/%7Epy8ieh/inter... → http://www.damowmow.com/playground/bu...
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
Blocks: 272547
Attachment #772 - Attachment is obsolete: true
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.
*** Bug 245635 has been marked as a duplicate of this bug. ***
WFM with the attachment from comment 57.
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.
(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.
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...
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
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 :)
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
Attached file 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).
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.
A bug, but not the bug in this report.
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).
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.
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.
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.
Attached patch WIP — — Splinter Review 
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.
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?
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]

I believe this is fixed by bug 288704 being fixed.

Yes.

Status: NEW → RESOLVED
Closed: 25 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: