PikeUK Reporter
	Description • 19 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+

	Anne (:annevk)
	Comment 3 • 19 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...

	PikeUK Reporter
	Comment 4 • 19 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."

	Anne (:annevk)
	Comment 5 • 19 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.

	David Baron :dbaron: Assignee
	Comment 6 • 19 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.

	PikeUK Reporter
	Comment 7 • 19 years ago

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

	David Baron :dbaron: Assignee
	Comment 8 • 19 years ago

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

	Dave Townsend [:mossop]
	Comment 9 • 19 years ago

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

	Santtu Lakkala
	Comment 10 • 19 years ago

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

	Anne (:annevk)
	Comment 11 • 19 years ago

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

	Adam Guthrie
	Comment 12 • 19 years ago

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

	David Baron :dbaron: Assignee
	Comment 13 • 19 years ago

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

	John Stracke
	Comment 17 • 16 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.)