Counter-reset in headings (h2 following h1) doesn't work properly
Categories
(Core :: Layout: Generated Content, Lists, and Counters, defect)
Tracking
()
People
(Reporter: dominikus.herzberg, Unassigned)
References
(Regression)
Details
(Keywords: regression, testcase)
Attachments
(2 files)
Screenshot showing that numbering on h2 after h1 is not reset
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Steps to reproduce:
I use Markdeep for writing documents. You write Markdown syntax in an HTML document and an embedded Javascript takes care of the transformation to acutal HTML elements. Markdeep takes care of the numbering for h1, h2, ... headings.
Take the documentation of markdeep as an example : https://casual-effects.com/markdeep/features.md.html#diagramexamples; the h2-header should be 2.1 and not 2.17
Actual results:
The numbering gets continued on h2; the counter-reset shows no effect.
1
1.1
1.2
:
1.16
2
2.17
2.18
:
Expected results:
On Chrome and on previous Firefox versions, the following was shown
1
1.1
1.2
:
1.16
2
2.1
2.2
:
|
||
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
Here's a somewhat reduced testcase distilled from the given URL.
|
||
Comment 2•4 years ago
|
||
This looks like a regression from bug 1548753.
|
||
Updated•4 years ago
|
|
|
||
Comment 3•4 years ago
|
||
This is caused by the change in bug 1548753. That's an intentional change backed by a CSSWG resolution so it's not something we will change back.
The problem with the page at hand is the rule for <body> creates a counter for h1, h2 etc. The rule for <h1> then creates a new counter named h2 (scoped to its descendants). The <h1> and <h2> elements are siblings though, so the h2 counter <h2> prefers is that of its ancestor <body> not that of its sibling <h1>. There are two ways this could be fixed in the page: 1, change the body rule to body{counter-reset: h1} which will make the <h2>s use their closest <h1> sibling's counter instead, or 2, change the counter-reset in the other rules to counter-set instead, which will set the named counters on <body> to 0 (which will then be incremented to 1 as intended).
|
|
||
Comment 4•4 years ago
|
||
Given this example, as well as bug 1672569, it seems the change was less web-compatible than hoped.
Is there any indication other browsers are intending to follow this behavior? If not, maybe we (and the CSSWG) do need to reconsider it.
|
|
||
Comment 5•4 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #4)
Given this example, as well as bug 1672569, it seems the change was less web-compatible than hoped.
I'm not sure I agree with that description. I've seen very little reported breakage so far.
Is there any indication other browsers are intending to follow this behavior? If not, maybe we (and the CSSWG) do need to reconsider it.
Well, they participated in the discussion leading to the CSSWG resolution so I sure hope so. They are free to file spec issues to propose alternative solutions if they wish of course.
I think the new spec is a good compromise though. The new behavior for the last example we gave in the spec issue makes much more sense than the old behavior. And being compatible with HTML list ordinals is more important than maintaining 100% backwards compatibility with behavior that makes no sense in the first place (I think we made this point very clear in the spec issue and it seems the CSSWG agreed with that).
Description
•