Closed Bug 1808995 Opened 1 year ago Closed 1 year ago

@counter-style does not fall back when outside specified range

Categories

(Core :: Layout: Generated Content, Lists, and Counters, defect)

Firefox 109
defect

Tracking

()

RESOLVED FIXED
111 Branch
Tracking Status
firefox111 --- fixed

People

(Reporter: mozilla.bugzilla, Assigned: jfkthame)

References

Details

Attachments

(3 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

@counter-style ordinal-default {
    system: numeric;
    symbols: "0" "1" "2" "3" "4" "5" "6" "7" "8" "9";
    suffix: "th";
}

@counter-style ordinal-ones {
    system: extends ordinal-default;
    suffix: "st";
    fallback: ordinal-default;
    range: 1 2, 21 22, 31 32, 41 42, 51 52, 61 62, 71 72, 81 82, 91 92;
}

@counter-style ordinal-twos {
    system: extends ordinal-default;
    suffix: "nd";
    fallback: ordinal-ones;
    range: 2 3, 22 23, 32 33, 42 43, 52 53, 62 63, 72 73, 82 83, 92 93;
}

@counter-style ordinal-threes {
    system: extends ordinal-default;
    suffix: "rd";
    fallback: ordinal-twos;
    range: 3 4, 23 24, 33 34, 43 44, 53 54, 63 64, 73 74, 83 84, 93 94;
}

@counter-style ordinal {
    system: extends ordinal-default;
    suffix: "th";
    fallback: ordinal-threes;
    range: 4 20, 24 30, 34 40, 44 50, 54 60, 64 70, 74 80, 84 90, 94 100;
}

ol.ordinal { list-style: ordinal; } 
<ol class="ordinal">
        <li>Should say 1st</li>
        <li>Should say 2nd</li>
        <li>Should say 3rd</li>
        <li>Should say 4th</li>
        <li>Should say 5th</li>
</ol>

Actual results:

the list items are numbered: 1st 2st 3st 4st 5st

Expected results:

the list items should be numbered: 1st 2nd 3rd 4th 5th

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Generated Content, Lists, and Counters' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Layout: Generated Content, Lists, and Counters
Product: Firefox → Core

Sorry the observed results are with the "th" suffix not "st".

I see the same result in Chrome as in Firefox, which makes me wonder if there's something wrong with the testcase, but I don't see it at the moment; it looks like it ought to work as intended.

(One detail: the ranges in the range descriptor are inclusive of both start and end values, so for the intended effect, the end values of each range should be reduced by 1. But that doesn't explain why the whole fallback thing doesn't seem to be working.)

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true

I know the ranges are inclusive, however I thought that a range of one number might not work, so I made the ranges overlap in such a way that the fallback would only happen on the values I wanted. If single index ranges are fine then I could simplify the styles a bit.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED

Per spec, "If a counter style is used to represent a counter value outside of its ranges,
the counter style instead drops down to its fallback counter style."

https://www.w3.org/TR/css-counter-styles-3/#counter-style-range
https://www.w3.org/TR/css-counter-styles-3/#counter-style-fallback

Some existing tests incorrectly assumed that a prefix or suffix from a custom rule will still apply
even when the counter value is not in range. That would mean "fallback" is only partial, using
the symbols/system from the fallback style mixed with the prefix/suffix of the originally-specified
style, which prevents use-cases like that in bug 1808995 working as expected.

Depends on D167409

The patch above should make examples like this one behave as expected, and I've added a new testcase based on this example.

I believe there will still be some remaining issues with other descriptors like pad and negative, which will be subject to the same kind of behavior, though it's probably less likely anyone will really need to work with them in this way. To fix them all consistently, I think we should consider a more extensive refactoring of the fallback mechanism, to avoid having to walk the fallback chain multiple times, but I'm leaving that for a possible followup.

Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3fab430c4e7c
Handle @counter-style fallback behavior for the prefix and suffix descriptors. r=emilio
https://hg.mozilla.org/integration/autoland/rev/c2a49ee389d9
Fix WPT testcases that do not properly account for counter-style fallback behavior of prefix/suffix descriptors. r=emilio
https://hg.mozilla.org/integration/autoland/rev/808aee125bc5
Add a testcase for counter-style suffix fallback when outside the custom style's range. r=emilio
https://hg.mozilla.org/integration/autoland/rev/d3ff45038932
Add counter-style prefix/suffix testcase including a cyclical fallback chain. r=emilio
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/38219 for changes under testing/web-platform/tests

Backed out for causing Wr failures on CounterStyleManager.cpp

Backout link

Push with failures

Failure log

Flags: needinfo?(jfkthame)
Upstream PR was closed without merging
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/63b04ce7cf57
Handle @counter-style fallback behavior for the prefix and suffix descriptors. r=emilio
https://hg.mozilla.org/integration/autoland/rev/ed181fad3934
Fix WPT testcases that do not properly account for counter-style fallback behavior of prefix/suffix descriptors. r=emilio
https://hg.mozilla.org/integration/autoland/rev/f43c5a2967b4
Add a testcase for counter-style suffix fallback when outside the custom style's range. r=emilio
https://hg.mozilla.org/integration/autoland/rev/809ead030779
Add counter-style prefix/suffix testcase including a cyclical fallback chain. r=emilio
Flags: needinfo?(jfkthame)
Upstream PR merged by moz-wptsync-bot
Blocks: 1830127

It turns out the Counter Styles spec actually requires the old behavior here, where prefix and suffix do not follow the fallback; see the "Note" at https://www.w3.org/TR/css-counter-styles-3/#counter-styles, and discussion in the CSSWG issue.

So in bug 1830127, we will be reverting to the previous, spec-compliant behavior. (Sorry, Cam! There's talk of designing a new feature that would enable the kind of thing you're trying to do here, but the current spec doesn't support it.)

Attachment #9313303 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: