288946 - Counters not incrementing unless explicitly reset first

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[PikeUK]

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+

Comment 1

[PikeUK]

Attachment: Example CSS from section 12.4 of CSS 2.1 recommendation

Comment 2

[PikeUK]

Attachment: Simple testcase

Comment 3

[Anne (:annevk)]

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...

Comment 4

[PikeUK]

(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

[Anne (:annevk)]

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.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 7

[PikeUK]

Attachment: 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)?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Yeah, that example needs counter-resets on the root element.

Comment 9

[Dave Townsend [:mossop]]

*** Bug 308012 has been marked as a duplicate of this bug. ***

Comment 10

[Santtu Lakkala]

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

Comment 11

[Anne (:annevk)]

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

Comment 12

[Adam Guthrie]

*** Bug 324122 has been marked as a duplicate of this bug. ***

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 326590 has been marked as a duplicate of this bug. ***

Comment 17

[John Stracke]

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.)