Closed
Bug 357718
Opened 18 years ago
Closed 18 years ago
counter-reset appears to be order-dependent and dependent on unclosed <a> tag
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: whatever, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
<head>
<title>
subtle CSS counter reset bug demonstration
</title>
<style type="text/css">
body {
/*
the order of these two must
be swtiched to have 1,2,3 in maincount
-- how inexplicable! --
*/
counter-reset: maincount 0;
counter-reset: appendix 0;
}
h2 {
counter-reset: h3 0;
}
h2.maincount {
counter-increment: maincount 1;
}
h2.maincount:before {
content: counter(maincount, decimal) ") ";
}
h2.appendix {
counter-increment: appendix 1;
}
h2.appendix:before {
content: counter(appendix, upper-latin) ") ";
}
h3.maincount {
counter-increment: h3 1;
}
h3.maincount:before {
content: counter(appendix, upper-latin) "." counter(h3, decimal) ") ";
}
</style>
</head>
<body>
<h1>Bug Demonstration Page</h1>
<a name="uris">
<h2 class="maincount">ONE</h2>
</a> <!-- removing the closing tag on the anchor will cause normality -->
<a name="mappings">
<h2 class="maincount">TWO</h2>
</a>
<a name="transfer">
<h2 class="maincount">THREE</h2>
</a>
<a name="examples" id="examples">
<h2 class="appendix">Examples</h2>
</a>
</body>
</html>
Reproducible: Always
Steps to Reproduce:
create a page with a multiple CSS counters as seen in the example.
Actual Results:
the counters are 1, 1, 1
Expected Results:
1, 2, 3
our working theory is that the </a> tag is somehow returning the interpreter
to "body context" and running the reset --- but how that interacts with
the order of the reset statements is beyond us
|
||
Comment 1•18 years ago
|
||
body {
counter-reset: maincount 0;
counter-reset: appendix 0;
}
Only the last declaration of the same property in the same rule is being
used for further cascading (as for all properties).
You should use the following to reset both your counters:
counter-reset: appendix 0 maincount 0;
See http://www.w3.org/TR/CSS21/generate.html#counters
In your example, the 'maincount' counter has not been reset.
The CSS 2.1 spec says that:
"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."
http://www.w3.org/TR/CSS21/generate.html#scope
This causes "counter-increment: maincount 1;" to do an automatic
counter reset *at that scope* which is the H2 and its later siblings.
This is why it works when you remove the </a> since the remaining
content are siblings and thus now have a 'maincount' counter that
is reset. On the other hand, if you wrap the <h2> in <a> you'll get
three separate 'maincount' counters, on for each <h2>.
The current behaviour is correct per CSS 2.1.
-> INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
So the behaviour should change based on the order of the counter-reset fields? If this is correct behaviour, I'd expect that reversing the order would have the opposite effect-- the second counter would be repetitive.
|
|
||
Comment 3•18 years ago
|
||
(In reply to comment #2)
> ... the second counter would be repetitive.
Yes, but there is only one element using it in the example as far as I can see.
Indeed, but the example was just a test case. Our actual page has both lists populated, and the problem only occurs the one way.
|
|
||
Comment 5•18 years ago
|
||
(In reply to comment #4)
> Our actual page has both lists populated, and the problem only occurs the one
> way.
It's hard to say without seeing an example, I'm guessing some ancestor element
must have affected the 'appendix' counter, otherwise it shouldn't be incrementing
with the body style you suggest.
You need to log in
before you can comment on or make changes to this bug.
Description
•