The default bug view has changed. See this FAQ.

Counters not incrementing unless explicitly reset first

RESOLVED INVALID

Status

()

Core
CSS Parsing and Computation
RESOLVED INVALID
12 years ago
9 years ago

People

(Reporter: PikeUK, Assigned: dbaron)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
At http://www.w3.org/TR/CSS21/generate.html#propdef-counter-increment is the
following example CSS:

H1:before {
    content: "Chapter " counter(chapter) ". ";
    counter-increment: chapter;  /* Add 1 to chapter */
    counter-reset: section;      /* Set section to 0 */
}
H2:before {
    content: counter(chapter) "." counter(section) " ";
    counter-increment: section;
}

This doesn't appear to work as the text implies it should, every counter
generated number is a 1. If you add these reset rules then it appears to "work",
e.g.:

BODY {
    counter-reset: chapter;
}

H1 {
    counter-reset: section;
}

I'm not sure why the "counter-reset:section" declaration has a different effect
when attached to a :before pseudo element than to a "real" element, whether it
is a separate bug or part of this one (assuming this is really a bug and not
expected behaviour).

p.s. I'm filing this as unconfirmed since there's a lot of discussion on the
original bug that went way over my head and perhaps included an explanation or
justification for this (in which case, sorry for wasting your time).

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050403 Firefox/1.0+
(Reporter)

Comment 1

12 years ago
Created attachment 179562 [details]
Example CSS from section 12.4 of CSS 2.1 recommendation
(Reporter)

Comment 2

12 years ago
Created attachment 179565 [details]
Simple testcase

Comment 3

12 years ago
Note that the current CSS 2.1 specification has bugs in this area. If I remember
the discussion on IRC correctly 'counter-reset' could not be applied to
':before' because of some scope issue. When you put them on some parent element
or perhaps the element itself it would work (like you did).

So this is probably INVALID...
(Reporter)

Comment 4

12 years ago
(In reply to comment #3)
> Note that the current CSS 2.1 specification has bugs in this area. If I remember
> the discussion on IRC correctly 'counter-reset' could not be applied to
> ':before' because of some scope issue. When you put them on some parent element
> or perhaps the element itself it would work (like you did).

Ah OK, that would explain why counter-reset behaves differently when applied to
:before, though it doesn't explain why counters that aren't counter-reset don't
increment.

I did notice the following line in the recommendation which suggests that
counters don't need to be reset before using them:

"If 'counter-increment' refers to a counter that is not in the scope (see below)
of any 'counter-reset', the counter is assumed to have been reset to 0 by the
root element."

Comment 5

12 years ago
All is going to change. Mozilla's implementation matches the CSS WG consensus so
I guess only very strange rendering bugs should be filed. No bugs about counters
in general against CSS 2.1 as it stands today.
(Assignee)

Updated

12 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Assignee)

Comment 6

12 years ago
In particular, the sentence about causing an implied reset on the root should
change to a sentence about causing an implied reset at the location where the
counter is needed.  On a :before, this reset doesn't have enough scope to be
relevant.
(Reporter)

Comment 7

12 years ago
Created attachment 186462 [details]
Example CSS from section 12.4 of updated CSS 2.1 recommendation

The latest example code in the newly updated CSS2.1 draft also displays
differently. I'm guessing that comment 6 is still valid and the example code
wasn't correctly altered for the new behaviour (the updated spec doesn't seem
to spell-out how pseudo-elements fit into the scope so it's hard to tell)?
Attachment #179562 - Attachment is obsolete: true
(Assignee)

Comment 8

12 years ago
Yeah, that example needs counter-resets on the root element.
*** Bug 308012 has been marked as a duplicate of this bug. ***

Comment 10

11 years ago
*** Bug 320514 has been marked as a duplicate of this bug. ***

Comment 11

11 years ago
*** Bug 322321 has been marked as a duplicate of this bug. ***

Comment 12

11 years ago
*** Bug 324122 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

11 years ago
*** Bug 326590 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

10 years ago
Duplicate of this bug: 389927
(Assignee)

Updated

10 years ago
Duplicate of this bug: 356485

Updated

9 years ago
Duplicate of this bug: 429210

Comment 17

9 years ago
Can you give links to anything that reflects the "WG consensus"? The published CSS2.1 spec does not; neither does the latest draft of the CSS3 Generated and Replaced Content Module (which, admittedly, is 5 years old now):

http://www.w3.org/TR/css3-content/#counters

"If 'counter-increment' refers to a counter that is not in the scope (see below) of any 'counter-reset', the counter is assumed to have been reset to 0 by the root element."

If the WG consensus has not been strong enough to get CSS2.1 updated, or to influence CSS3, I'm not sure why it should convince you to break compliance with the published specs.

(Personally, I think such a change is a Bad Idea in the first place, since it breaks backward compatibility.  Maybe if you could link to the argument I'd understand why.)
(Reporter)

Updated

9 years ago
Duplicate of this bug: 453280
You need to log in before you can comment on or make changes to this bug.