CSS 2.1 failure: counter-reset-increment-002.htm

[Robert Hogan]

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?

[Robert Hogan]

Hi Darin,

Should this behaviour be special-cased as a quirk?

Thanks,
Robert

[Darin Adler]

(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.

[Darin Adler]

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.

[Ahmad Saleem]

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!

[Radar WebKit Bug Importer]

<rdar://problem/95646054>