Closed Bug 288946 Opened 20 years ago Closed 20 years ago

Counters not incrementing unless explicitly reset first

Categories

(Core :: CSS Parsing and Computation, defect)

x86
Windows 98
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: me, Assigned: dbaron)

References

Details

Attachments

(2 files, 1 obsolete file)

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+
Attached file Simple testcase (deleted) —
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...
(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."
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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
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.
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
Yeah, that example needs counter-resets on the root element.
*** Bug 308012 has been marked as a duplicate of this bug. ***
*** Bug 320514 has been marked as a duplicate of this bug. ***
*** Bug 322321 has been marked as a duplicate of this bug. ***
*** Bug 324122 has been marked as a duplicate of this bug. ***
*** Bug 326590 has been marked as a duplicate of this bug. ***
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.)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: