Bug 74242

Summary: CSS 2.1 failure: counter-reset-increment-002.htm
Product: WebKit Reporter: Robert Hogan <robert>
Component: CSSAssignee: Robert Hogan <robert>
Status: NEW ---    
Severity: Normal CC: darin, robert
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 47141    

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.