This is caused by the change in bug 1548753. That's an intentional change backed by a CSSWG [resolution](https://github.com/w3c/csswg-drafts/issues/5477) 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`](https://drafts.csswg.org/css-lists-3/#propdef-counter-set] instead, which will set the named counters on `<body>` to 1.
Bug 1679712 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is caused by the change in bug 1548753. That's an intentional change backed by a CSSWG [resolution](https://github.com/w3c/csswg-drafts/issues/5477) 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`](https://drafts.csswg.org/css-lists-3/#propdef-counter-set) instead, which will set the named counters on `<body>` to 1.
This is caused by the change in bug 1548753. That's an intentional change backed by a CSSWG [resolution](https://github.com/w3c/csswg-drafts/issues/5477) 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`](https://drafts.csswg.org/css-lists-3/#propdef-counter-set) instead, which will set the named counters on `<body>` to 0.
This is caused by the change in bug 1548753. That's an intentional change backed by a CSSWG [resolution](https://github.com/w3c/csswg-drafts/issues/5477) 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`](https://drafts.csswg.org/css-lists-3/#propdef-counter-set) instead, which will set the named counters on `<body>` to 0 (which will then be incremented to 1 as intended).