[css-gaps-1] Computed value of column-rule-width with none|hidden style and lists of values

[kbabbitt]

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:

1. If column-rule-style contains exactly one value and that value is none or hidden, then the computed value of column-rule-width is 0.
2. If column-rule-style contains nothing other than none, hidden, or repeaters containing nothing other than none or hidden, then the computed value of column-rule-width is 0.

My inclination is towards 1. Does the WG agree? Any options I might have missed?

[Loirooriol]

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]

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?

Yes, and a similar consideration is that lists for different properties can repeat and have different lengths. For example:

column-rule-style: solid dashed none;
column-rule-width: 1px 2px;

Would give, in order from left to right: 1px solid, 2px dashed, (1px) none, 2px solid, 1px dashed, (2px) none.

[css-meeting-bot]

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]

Summary of the resolution as I understand it:

1. column-rule-*, border-*, and outline-* are all under consideration
2. Computed value for *-width should be independent of *-style, i.e. remove the none/hidden special behavior from this stage
3. Resolved value (i.e. getComputedStyle) for border-width should continue to return 0 if border-style is none/hidden, for compat reasons
4. If also needed for compat, apply 3 to outline-width and column-rule-width as well

cc @emilio @fantasai @tabatkins

[tabatkins]

Yes, that's an accurate summary afaict.