Closed
Bug 4522
Opened 26 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)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
DUPLICATE
of bug 288704
People
(Reporter: jce2, Unassigned)
References
(Blocks 1 open bug, )
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)
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...
P1 bugs are for crashers.
Severity: minor → normal
Status: NEW → ASSIGNED
Priority: P1 → P3
Target Milestone: M6
Updated•26 years ago
|
Comment 2•26 years ago
|
||
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•26 years ago
|
||
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•26 years ago
|
||
I mean blocks within inlines.
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•25 years ago
|
Summary: ummm..lists have 1. 1. 1. 1. → {css1} ummm..lists have 1. 1. 1. 1.
Comment 9•25 years ago
|
||
[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•25 years ago
|
||
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•25 years ago
|
||
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•25 years ago
|
||
Note. The CSS2 numbering stuff is covered by bug 3247.
Comment 13•25 years ago
|
||
*** Bug 7384 has been marked as a duplicate of this bug. ***
Comment 14•25 years ago
|
||
*** Bug 8485 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Summary: {css1} ummm..lists have 1. 1. 1. 1. → {list} {css1} ummm..lists have 1. 1. 1. 1.
Updated•25 years ago
|
Whiteboard: [TESTCASE]
Comment 15•25 years ago
|
||
*** Bug 9543 has been marked as a duplicate of this bug. ***
Comment 16•25 years ago
|
||
Updated•25 years ago
|
QA Contact: petersen → chrisd
Comment 17•25 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.
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Summary: {list} {css1} ummm..lists have 1. 1. 1. 1. → {list} {css1} ummm..lists have 0. 0. 0. 0.
Comment 18•25 years ago
|
||
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.
Updated•25 years ago
|
Resolution: FIXED → ---
Comment 19•25 years ago
|
||
Just fixed the tools page on www.mozilla.org. The web page was fixed,
not the bug.
Comment 20•25 years ago
|
||
Moved target milestone to M10, after Kipp's return.
Comment 21•25 years ago
|
||
Updating to default Layout Assignee...kipp no longer with us :-(
Comment 22•25 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.
Updated•25 years ago
|
Summary: {list} {css1} ummm..lists have 0. 0. 0. 0. → {list} {css1} ummm.. display:list-item lists have 0. 0. 0. 0.
Updated•25 years ago
|
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]
Comment 23•25 years ago
|
||
[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.
Comment 24•25 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?
Updated•25 years ago
|
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]
Comment 25•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [TESTCASE]
Updated•25 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}
Updated•25 years ago
|
Summary: Display:list-item lists have 0. 0. 0. 0. {list} → Display:list-item lists have 0. 0. 0. 0. {list} [BLOCK]
Comment 29•24 years ago
|
||
Adding nsbeta2 keyword since there are a lot of duplicates.
Keywords: nsbeta2
Comment 31•24 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•24 years ago
|
||
Comment 33•24 years ago
|
||
'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•24 years ago
|
||
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•24 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
Updated•24 years ago
|
Summary: Display:list-item lists have 0. 0. 0. 0. {list} [BLOCK] → [LIST]Display:list-item lists have 0. 0. 0. 0.
Comment 36•24 years ago
|
||
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) |
Updated•24 years ago
|
QA Contact: chrisd → py8ieh=bugzilla
Comment hidden (offtopic) |
Reporter | ||
Comment 39•24 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•24 years ago
|
||
*** Bug 45768 has been marked as a duplicate of this bug. ***
Comment 41•24 years ago
|
||
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•24 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•23 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.'
Updated•23 years ago
|
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)
Comment 44•23 years ago
|
||
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
Status: ASSIGNED → NEW
Comment 45•23 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)
Comment 46•23 years ago
|
||
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•23 years ago
|
||
so, if a counter isn't there, how does the UA know to increment a counter?
Comment 48•23 years ago
|
||
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•23 years ago
|
||
magic counters, cool -- I stand corrected
Comment 50•23 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?
Comment 51•23 years ago
|
||
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•23 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•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 55•22 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•22 years ago
|
||
*** Bug 185713 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
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•22 years ago
|
||
*** Bug 187268 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
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
Comment 59•22 years ago
|
||
*** Bug 190995 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
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)
Comment 60•21 years ago
|
||
.
Assignee: attinasi → block-and-inline
Component: Layout → Layout: Block & Inline
Priority: P2 → --
Target Milestone: mozilla1.1alpha → ---
Comment 61•21 years ago
|
||
*** Bug 219714 has been marked as a duplicate of this bug. ***
Comment 62•21 years ago
|
||
*** Bug 219716 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Flags: blocking1.6b+
Updated•21 years ago
|
Flags: blocking1.6b+
Updated•21 years ago
|
Flags: blocking1.6b-
Comment 63•21 years ago
|
||
> 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•21 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)
Attachment #772 -
Attachment is obsolete: true
Updated•19 years ago
|
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)
Comment 64•19 years ago
|
||
*** Bug 293174 has been marked as a duplicate of this bug. ***
Comment 65•19 years ago
|
||
*** Bug 309188 has been marked as a duplicate of this bug. ***
Comment 66•19 years ago
|
||
FWIW, this should be fixed by bug 288704, which I'd like to do for 1.9, time
permitting.
Comment 67•19 years ago
|
||
*** Bug 245635 has been marked as a duplicate of this bug. ***
Comment 68•18 years ago
|
||
WFM with the attachment from comment 57.
Comment 69•17 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•17 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•17 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?
Comment 72•17 years ago
|
||
No. If there were, you'd see it here. It's too late for Firefox 3 at this point; hopefully next major release...
Updated•16 years ago
|
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
Comment 74•16 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 :)
Comment 75•15 years ago
|
||
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•15 years ago
|
||
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•15 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.
Comment 78•15 years ago
|
||
This is actually a bug.
Comment 79•15 years ago
|
||
A bug, but not the bug in this report.
Comment 80•15 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.
Comment 81•15 years ago
|
||
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•15 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.
Comment 83•15 years ago
|
||
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•15 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.
Comment 85•15 years ago
|
||
(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•15 years ago
|
||
It's not. The code for counters and the code for list-items are currently unrelated.
Updated•14 years ago
|
Blocks: css2.1-tests
Comment 87•12 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
Comment 88•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
(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•11 years ago
|
||
(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 96•11 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?
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 102•8 years ago
|
||
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]
Comment 103•8 years ago
|
||
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.
Updated•8 years ago
|
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]
Comment 104•5 years ago
|
||
I believe this is fixed by bug 288704 being fixed.
Comment hidden (offtopic) |
Comment 106•5 years ago
|
||
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.
Description
•