Last Comment Bug 288946 - Counters not incrementing unless explicitly reset first
: Counters not incrementing unless explicitly reset first
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: x86 Windows 98
: -- normal (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
: Hixie (not reading bugmail)
Mentors:
: 308012 320514 322321 324122 326590 356485 389927 429210 453280 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-04 03:25 PDT by PikeUK
Modified: 2008-09-02 09:22 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Example CSS from section 12.4 of CSS 2.1 recommendation (791 bytes, text/html)
2005-04-04 03:26 PDT, PikeUK
no flags Details
Simple testcase (892 bytes, text/html)
2005-04-04 03:35 PDT, PikeUK
no flags Details
Example CSS from section 12.4 of updated CSS 2.1 recommendation (796 bytes, text/html)
2005-06-16 02:55 PDT, PikeUK
no flags Details

Description PikeUK 2005-04-04 03:25:29 PDT
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 2005-04-04 03:26:57 PDT
Created attachment 179562 [details]
Example CSS from section 12.4 of CSS 2.1 recommendation
Comment 2 PikeUK 2005-04-04 03:35:17 PDT
Created attachment 179565 [details]
Simple testcase
Comment 3 Anne (:annevk) 2005-04-04 06:14:56 PDT
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 2005-04-04 06:50:15 PDT
(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) 2005-04-04 07:57:36 PDT
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-7 (review requests must explain patch) 2005-04-04 09:25:23 PDT
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 2005-06-16 02:55:18 PDT
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)?
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-06-16 10:36:25 PDT
Yeah, that example needs counter-resets on the root element.
Comment 9 Dave Townsend [:mossop] 2005-09-11 06:44:38 PDT
*** Bug 308012 has been marked as a duplicate of this bug. ***
Comment 10 Santtu Lakkala 2005-12-16 04:14:44 PST
*** Bug 320514 has been marked as a duplicate of this bug. ***
Comment 11 Anne (:annevk) 2006-01-16 04:54:49 PST
*** Bug 322321 has been marked as a duplicate of this bug. ***
Comment 12 Adam Guthrie 2006-01-20 12:43:53 PST
*** Bug 324122 has been marked as a duplicate of this bug. ***
Comment 13 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2006-02-09 15:25:21 PST
*** Bug 326590 has been marked as a duplicate of this bug. ***
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-07-28 00:46:57 PDT
*** Bug 389927 has been marked as a duplicate of this bug. ***
Comment 15 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-07-28 00:47:22 PDT
*** Bug 356485 has been marked as a duplicate of this bug. ***
Comment 16 philippe (part-time) 2008-04-15 21:17:13 PDT
*** Bug 429210 has been marked as a duplicate of this bug. ***
Comment 17 John Stracke 2008-04-16 05:15:41 PDT
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.)
Comment 18 PikeUK 2008-09-02 09:22:04 PDT
*** Bug 453280 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.