[css-lists] Override reversed attribute of <ol> by counter-reset's value [chromium/src : main]
Minseong Kim (Gerrit)
Minseong Kim added 1 comment![]( "Open in Gerrit")
Hello. Would you review this CL, please?
Related details
- Daniil Sakhapov
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daniil Sakhapov (Gerrit)
Daniil Sakhapov added 1 comment![]( "Open in Gerrit")
I think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
Related details
- Minseong Kim
- Rune Lillesveen
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Rune Lillesveen (Gerrit)
Rune Lillesveen added 1 comment![]( "Open in Gerrit")
I think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
I don't know at which level of the CSS cascade things happen here. Would it make sense to do this as a CSS cascade thing that sets some value/flag on the ComputedStyle instead? That is, the `reversed` attribute causes some presentation style which is overridable by the CSS property?
And that computed CSS value is the source of truth for reversing instead of the attribute?
Related details
- Minseong Kim
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Daniil Sakhapov (Gerrit)
Daniil Sakhapov added 1 comment![]( "Open in Gerrit")
Rune LillesveenI think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
I don't know at which level of the CSS cascade things happen here. Would it make sense to do this as a CSS cascade thing that sets some value/flag on the ComputedStyle instead? That is, the `reversed` attribute causes some presentation style which is overridable by the CSS property?
And that computed CSS value is the source of truth for reversing instead of the attribute?
Yes, you got that right.
In this case, will a CSS cascade thing make sense?
If we detect this need to override, we need to call UpdateItems() for HTMLOListElement, which causes calls to SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation(), so doing it from RecalcOwnStyle should by fine?
Rune Lillesveen (Gerrit)
Rune Lillesveen added 1 comment![]( "Open in Gerrit")
Rune LillesveenI think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
Daniil SakhapovI don't know at which level of the CSS cascade things happen here. Would it make sense to do this as a CSS cascade thing that sets some value/flag on the ComputedStyle instead? That is, the `reversed` attribute causes some presentation style which is overridable by the CSS property?
And that computed CSS value is the source of truth for reversing instead of the attribute?
Yes, you got that right.
In this case, will a CSS cascade thing make sense?
If we detect this need to override, we need to call UpdateItems() for HTMLOListElement, which causes calls to SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation(), so doing it from RecalcOwnStyle should by fine?
When is UpdateItems() called (lifecycle-wise)?
Could you spell out all the cascade-dependencies here?
Daniil Sakhapov (Gerrit)
Daniil Sakhapov added 1 comment![]( "Open in Gerrit")
Rune LillesveenI think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
Daniil SakhapovI don't know at which level of the CSS cascade things happen here. Would it make sense to do this as a CSS cascade thing that sets some value/flag on the ComputedStyle instead? That is, the `reversed` attribute causes some presentation style which is overridable by the CSS property?
And that computed CSS value is the source of truth for reversing instead of the attribute?
Rune LillesveenYes, you got that right.
In this case, will a CSS cascade thing make sense?
If we detect this need to override, we need to call UpdateItems() for HTMLOListElement, which causes calls to SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation(), so doing it from RecalcOwnStyle should by fine?
When is UpdateItems() called (lifecycle-wise)?
Could you spell out all the cascade-dependencies here?
So `reversed` on <ol> is called from Element::ParseAttribute (so, html parsing time?) and it sets SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation() for <li>s via UpdateItems().
Then we have our `counter-reset`, which should override `reset` and call UpdateItems() for <ol>.
I guess that's it.
Rune Lillesveen (Gerrit)
Rune Lillesveen added 1 comment![]( "Open in Gerrit")
Rune LillesveenI think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
Daniil SakhapovI don't know at which level of the CSS cascade things happen here. Would it make sense to do this as a CSS cascade thing that sets some value/flag on the ComputedStyle instead? That is, the `reversed` attribute causes some presentation style which is overridable by the CSS property?
And that computed CSS value is the source of truth for reversing instead of the attribute?
Rune LillesveenYes, you got that right.
In this case, will a CSS cascade thing make sense?
If we detect this need to override, we need to call UpdateItems() for HTMLOListElement, which causes calls to SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation(), so doing it from RecalcOwnStyle should by fine?
Daniil SakhapovWhen is UpdateItems() called (lifecycle-wise)?
Could you spell out all the cascade-dependencies here?
So `reversed` on <ol> is called from Element::ParseAttribute (so, html parsing time?) and it sets SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation() for <li>s via UpdateItems().
Then we have our `counter-reset`, which should override `reset` and call UpdateItems() for <ol>.
I guess that's it.
That didn't answer my questions.
When, in the lifecycle, is UpdateItems called? Related to CSS counters?
And the cascade part:
Is it possible to express this behavior as presentation style for `reversed`, so that UpdateItems rely on computed styles instead of the attribute directly? (This is why I ask about when UpdateItems() is called).
Minseong Kim (Gerrit)
Minseong Kim added 1 comment![]( "Open in Gerrit")
Rune LillesveenI think the correct approach here would be to override the reversed attribute with style info during style recalc, e.g. in Element::RecalcOwnStyle. @fut...@chromium.org, wdyt?
Daniil SakhapovI don't know at which level of the CSS cascade things happen here. Would it make sense to do this as a CSS cascade thing that sets some value/flag on the ComputedStyle instead? That is, the `reversed` attribute causes some presentation style which is overridable by the CSS property?
And that computed CSS value is the source of truth for reversing instead of the attribute?
Rune LillesveenYes, you got that right.
In this case, will a CSS cascade thing make sense?
If we detect this need to override, we need to call UpdateItems() for HTMLOListElement, which causes calls to SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation(), so doing it from RecalcOwnStyle should by fine?
Daniil SakhapovWhen is UpdateItems() called (lifecycle-wise)?
Could you spell out all the cascade-dependencies here?
Rune LillesveenSo `reversed` on <ol> is called from Element::ParseAttribute (so, html parsing time?) and it sets SetNeedsLayoutAndIntrinsicWidthsRecalcAndFullPaintInvalidation() for <li>s via UpdateItems().
Then we have our `counter-reset`, which should override `reset` and call UpdateItems() for <ol>.
I guess that's it.
That didn't answer my questions.
When, in the lifecycle, is UpdateItems called? Related to CSS counters?
And the cascade part:
Is it possible to express this behavior as presentation style for `reversed`, so that UpdateItems rely on computed styles instead of the attribute directly? (This is why I ask about when UpdateItems() is called).
When, in the lifecycle, is UpdateItems called? Related to CSS counters?
IIUC, as @sakh...@chromium.org said, it's only called from `Element::ParseAttribute` when the element set/add/remove attributes. So, I think the call site of `UpdateItemValues()` has no relations with the CSS counters.. right?
And that computed CSS value is the source of truth for reversing instead of the attribute?
I totally agree with you. I'll test that it is possible to make `UpdateItemValues()` rely on computed styles instead of the attribute directly.
Related details
- Daniil Sakhapov
- Rune Lillesveen
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Minseong Kim (Gerrit)
FYI, `UpdateItemValues` is a method on `HTMLOListElement` that is called when the `start` or `reversed` attributes of an <ol> are modified. Its primary role is to invalidate the cached numerical values (ordinals) of the list items. This forces a recalculation during the next layout phase. The recalculation logic, found in `ListItemOrdinal` class (specifically the `CalcValue` method), directly considers CSS properties like counter-set and counter-increment alongside the HTML attributes.
Rune Lillesveen (Gerrit)
Rune Lillesveen added 1 comment![]( "Open in Gerrit")
FYI, `UpdateItemValues` is a method on `HTMLOListElement` that is called when the `start` or `reversed` attributes of an <ol> are modified. Its primary role is to invalidate the cached numerical values (ordinals) of the list items. This forces a recalculation during the next layout phase. The recalculation logic, found in `ListItemOrdinal` class (specifically the `CalcValue` method), directly considers CSS properties like counter-set and counter-increment alongside the HTML attributes.
Right. It's confusing that it's called UpdateItemValues(). It should probably be named InvalidateItemValues() instead.
Related details
- Daniil Sakhapov
- Minseong Kim
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |