Repository navigation
[css-gaps-1] Computed value of column-rule-width with none|hidden style and lists of values #11494
Description
Per CSS Multicol 1, if column-rule-style is none or hidden, then the computed value of column-rule-width will be 0.
Gaps 1 extends the definitions of the column-rule-* properties to allow for lists of values. It also seeks to preserve the existing behavior noted above for backwards compatibility. But in what cases should the backward compatibility behavior apply? I can see a couple of reasonable possibilities:
- If
column-rule-stylecontains exactly one value and that value isnoneorhidden, then the computed value ofcolumn-rule-widthis0. - If
column-rule-stylecontains nothing other thannone,hidden, or repeaters containing nothing other thannoneorhidden, then the computed value ofcolumn-rule-widthis0.
My inclination is towards 1. Does the WG agree? Any options I might have missed?
Activity
Loirooriol commentedon Jan 13, 2025
I'm assuming that
repeat()is preserved at computed-value time, so it's not possible to just set to zero the width at the same index, right?kbabbitt commentedon Jan 13, 2025
Yes, and a similar consideration is that lists for different properties can repeat and have different lengths. For example:
Would give, in order from left to right: 1px solid, 2px dashed, (1px) none, 2px solid, 1px dashed, (2px) none.
[-][css-gaps-1] Computed value of [column|row]-rule-width with none|hidden style and lists of values[/-][+][css-gaps-1] Computed value of column-rule-width with none|hidden style and lists of values[/+]css-meeting-bot commentedon Jan 31, 2025
The CSS Working Group just discussed
[css-gaps-1] Computed value of column-rule-width with none|hidden style and lists of values, and agreed to the following:RESOLVED: Do the above.The full IRC log of that discussion
<TabAtkins> kbabbitt: now it's decorations<TabAtkins> kbabbitt: first, there's some behavior defined in multicol where if column-rule-style is none|hidden, column-rule-width is 0
<TabAtkins> kbabbitt: i'm extending those properties to allow multiple values to allow alternating/etc
<TabAtkins> kbabbitt: how do we accommodate the multicol behavior?
<TabAtkins> kbabbitt: two beahvior
<TabAtkins> kbabbitt: one is, if there's exactly one value and it's non/hidden, width is 0
<TabAtkins> kbabbitt: two is, if it contains multiple values and they're *all* none/hidden, width computes to 0
<TabAtkins> kbabbitt: lean toward first just to minimize beahvior needed for back compat
<TabAtkins> astearns: what do we lose if we don't do 2?
<fantasai> TabAtkins: Very minor concern (agree 1 is probably better) -- when we have behaviors that depend on list of values, can trip over it
<fantasai> TabAtkins: once you add more values
<fantasai> TabAtkins: ways to work around it, e.g. repeat your style and alternate
<astearns> ack fantasai
<TabAtkins> fantasai: is this a case wher eth eused value of the affected liens are still 0, right? so this is just about computed value of the width property?
<TabAtkins> kbabbitt: yeah
<TabAtkins> fantasai: this isn't inherited, so people probabyl won't care
<florian> q?
<TabAtkins> TabAtkins: good argument for the discontinuity not mattering
<emilio> q+
<TabAtkins> fantasai: maybe we could even just change the multicol rule behavior, seems less likely for it to be something people are depending on it
<TabAtkins> kbabbitt: could do a stud
<TabAtkins> fantasai: probably not that important, but maybe good
<astearns> s/stud/study/
<TabAtkins> fantasai: i could imagine not computing to 0 behind useful so you could inherit to children. maybe that's too weird
<astearns> ack emilio
<fantasai> s/could/could explicitly/
<TabAtkins> emilio: on the one hand, existing behavior is consistent with outline-width and border-width
<TabAtkins> emilio: on the other hand, i'm not a fan of that behavior
<TabAtkins> emilio: so i have a slight preference to try and get rid of the weird behavior if we can
<TabAtkins> fantasai: the used value is always 0 regardless, this is just computed value
<TabAtkins> emilio: 'border' i doubt we could change, without changing gCS()
<TabAtkins> emilio: border used to be a "used value" property
<fantasai> s/changing/special-casing/
<TabAtkins> emilio: so we'd probably still need to special-case it if we wanted to get rid of this in general
<TabAtkins> emilio: common for people to just fetch the border-width and padding from gCS(), so needs to stay 0
<TabAtkins> emilio: but maybe could change outline as well
<TabAtkins> fantasai: what if we said hidden/none no longer affect border/outline/column-rule
<TabAtkins> fantasai: but gCS() returns 0 on these properties if the style is hidden/none
<TabAtkins> emilio: i think we could get away with that
<fantasai> s/affect/affect computed value of/
<TabAtkins> florian: problem is gCS() isn't computed value, it's "resolved value". Proposal is computed value doesn't set to 0, only resolved value. So inheritance sitll gets the proper value.
<TabAtkins> kbabbitt: so still a question of how we do that for gap-rule
<TabAtkins> TabAtkins: emilio suggested we can do this resolved-value hack only for border, just fix outline and column-rule ot normal
<TabAtkins> emilio: [outlines that]
<TabAtkins> emilio: we could add it into outline/column-rule for single values *if needed*
<TabAtkins> emilio: if you inherit the whole border it does what you want, if you inherit border-width of 0 and then reset border style, uh, why?
<fantasai> TabAtkins: So we remove the current to-zero computation for all these properties. Instead do it in gCS only for border-width only.
<fantasai> TabAtkins: If we need to, go back and apply for outline/column-rule if needed for compat
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Do the above.
kbabbitt commentedon Feb 21, 2025
Summary of the resolution as I understand it:
column-rule-*,border-*, andoutline-*are all under consideration*-widthshould be independent of*-style, i.e. remove the none/hidden special behavior from this stageborder-widthshould continue to return 0 ifborder-styleis none/hidden, for compat reasonsoutline-widthandcolumn-rule-widthas wellcc @emilio @fantasai @tabatkins
tabatkins commentedon Feb 22, 2025
Yes, that's an accurate summary afaict.
[css-backgrounds-3][css-multicol-4][css-ui-4][css-gaps-1] Adjust *-wi…
43 remaining items
Update outline-width and outline-offset to match updated computed sty…
Update border-*-width to match updated computed style resolution rules
Update column-rule-width to match updated computed style resolution r…
raikiri-style: add TR/ED version marker to resolve_border's gate rati…