Bug 74242 - CSS 2.1 failure: counter-reset-increment-002.htm
Summary: CSS 2.1 failure: counter-reset-increment-002.htm
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Robert Hogan
URL:
Keywords: InRadar
Depends on:
Blocks: 47141
  Show dependency treegraph
 
Reported: 2011-12-10 15:17 PST by Robert Hogan
Modified: 2022-06-21 16:44 PDT (History)
9 users (show)

See Also:


Attachments
Safari 15.5 differs from other browsers (542.71 KB, image/png)
2022-06-17 09:40 PDT, Ahmad Saleem
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Hogan 2011-12-10 15:17:35 PST
This fails because of this section in RenderCounter:

    if (identifier == "list-item") {
        if (object->isListItem()) {
            if (toRenderListItem(object)->hasExplicitValue()) {
                value = toRenderListItem(object)->explicitValue();
                isReset = true;
                return true;
            }
            value = 1;
            isReset = false;
            return true;
        }
        if (Node* e = object->node()) {
            if (e->hasTagName(olTag)) {
                value = static_cast<HTMLOListElement*>(e)->start();
                isReset = true;
                return true;
            }
            if (e->hasTagName(ulTag) || e->hasTagName(menuTag) || e->hasTagName(dirTag)) {
                value = 0;
                isReset = true;
                return true;
            }
        }
    }

Darin, do you know why 'counter(list-item)' is given such special treatment, i.e. incrementing by 1 even if no counter-increment exists? Is this a defunct requirement maybe?
Comment 1 Robert Hogan 2012-01-25 11:08:35 PST
Hi Darin,

Should this behaviour be special-cased as a quirk?

Thanks,
Robert
Comment 2 Darin Adler 2012-01-26 10:18:36 PST
(In reply to comment #0)
> Darin, do you know why 'counter(list-item)' is given such special treatment, i.e. incrementing by 1 even if no counter-increment exists? Is this a defunct requirement maybe?

You can see a list-item example in the CSS lists and counters module draft. According to the CSS specification, the list-item counter is affected list items. More specifically, items with 'display' values which generate a list marker.

I don’t think the existing code is entirely consistent with what's specified, but generally speaking the list-item counter gets set based on list items. Part of the rule is that if an element doesn't otherwise have a ‘counter-increment’ declaration, it must act as if ‘counter-increment: list-item’ were specified.

The current implementation that you quoted doesn’t match what’s in the specification. For example, it’s based directly on the DOM rather than on rendering. Removing it entirely would leave counter(list-item) even farther off.

There are other special counters (5 in all in the current specification) and I am not sure we have implemented them.
Comment 3 Darin Adler 2012-01-26 10:19:06 PST
And no, I can’t see why we’d want to add a quirk for this. It’s good to be cautious about content that already relies on our behavior, but I don’t think that’s the top concern here.
Comment 4 Ahmad Saleem 2022-06-17 09:40:29 PDT
Created attachment 460301 [details]
Safari 15.5 differs from other browsers

I am able to reproduce this bug where Safari 15.5 on macOS 12.4 output is not matching with expected result:

http://test.csswg.org/suites/css21_dev/20110323/html4/counter-reset-increment-002.htm

But when I try to run it on other browser, it does not match on them either. Although, Firefox Nightly 103 and Chrome Nightly 103 do match with each other. So Safari 15.5 is outlier here.

Please refer to attached screenshot.

If I am testing incorrectly, please retest accordingly. In case, if there is spec issue, appreciate if this can be raised separately or clarified. Thanks!
Comment 5 Radar WebKit Bug Importer 2022-06-21 16:44:34 PDT
<rdar://problem/95646054>