[css-ui-4] Align canonical order of `outline` sub-properties with `border`

[cdoublev]

Name: outline
Value: [<'outline-color'> || <'outline-style'> || <'outline-width'>]
[...]
Canonical order: per grammar

https://drafts.csswg.org/css-ui-4/#propdef-outline

Could you please tell me if there is a reason why the canonical order of outline is different from that of border and border-<side>, or if they can be aligned?

Name: border
Value: <line-width> || <line-style> || <color>
[...]
Canonical order: per grammar

https://drafts.csswg.org/css-backgrounds-3/#propdef-border

[Loirooriol]

This goes back to CSS2:
https://www.w3.org/TR/CSS2/box.html#border-shorthand-properties
https://www.w3.org/TR/CSS2/ui.html#dynamic-outlines

[fantasai]

@Loirooriol CSS2 didn't define a canonical order. That was a concept introduced much more recently, and I don't think anyone audited the various property grammars to make sure they were in an appropriate canonical order.

I agree it would be nice to align these it's Web-compatible.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui-4] Align canonical order of `outline` sub-properties with `border` .

The full IRC log of that discussion

<dbaron> TabAtkins: Guillaume noted that despite similar value spaces, the outline and border have a different order of the value definition grammar, and since we generally follow value definition order when serializing.
<dbaron> TabAtkins: fantasai notes that in CSS2 the grammar order wasn't implied to have a meaning.
<dbaron> TabAtkins: since we do rely on the grammar order for things it would make sense to align them
<dbaron> TabAtkins: Aside from that possibility, I think it's reasonable to align the 2, more likely to follow what border does.
<dbaron> TabAtkins: I think we should resolve to make outline's component order match border's component order.
<fantasai> Note that at least two people filed this issue, since we have a dup
<astearns> ack dbaron
<TabAtkins> dbaron: In the past I was always concerned about the model of defaulting to the syntax in the value definition
<TabAtkins> dbaron: I think in general it is worth explicitlyt esting impls to see what they do and then coming back
<emilio> +1 dbaron
<TabAtkins> dbaron: Partaly I'm guessing impls dont' formally follow the spec right now
<TabAtkins> dbaron: They wer eimplemented before we created this rule, and probably haven't udpated
<TabAtkins> dbaron: So probably tests might show some accidental compliance anyway
<TabAtkins> astearns: Would you like to test then resolve? Or okay to resolve first and use tests to verify?
<TabAtkins> dbaron: Probably good to get tests first, but should be fine to resolve async once we do.
<tantek> +1 on getting tests first, this has been implemented long enough ago that it's worth gathering that data first
<TabAtkins> astearns: Sounds good, let's see if we can resolve async once we ahve the data

[emilio]

From a quick look at the code, I'm 99% sure @dbaron is right, and Gecko at least should be internally consistent (color, then style, then width).

[fantasai]

See testcase.

Results: all browsers follow the current (inconsistent) spec consistently.

[dbaron]

Here's a testcase with both specified and computed styles. It does largely agree that browsers follow the (inconsistent) spec, modulo a missing result for WebKit.

[dbaron]

(Also, for one previous discussion about the rule on inferring canonical order from the value lines, see this pair of related threads: part 1, part 2.)

[dbaron]

For what it's worth, Firefox 4.0.1 produced:

border, specified: 3px dotted orange
outline, specified: 2px solid blue
border, computed:
outline, computed: 

So the outline behavior changed sometime between then and now (most likely in the rewrite of the style engine).

[dbaron]

The Chromium and WebKit code for outline was changed in March 2012 to match the spec.

[dbaron]

I couldn't find the prior minutes referenced in the above threads, though I did find these minutes that reference them:

   sylvaing: One thing that's controversial was following the property
             definitions in terms of property order
   sylvaing: I remember dbaron was uncomfortable with that

[dbaron]

In any case, I'm personally fine with trying to change the order for outline back to match border. It would match what implementations did before the spec told them to do otherwise.

I also think we should either:

1. change the cssom spec to no longer specify that the Value line should be used as a default canonicalization order, but instead we should say that specs without a canonical order line are buggy and should be fixed after appropriate testing, or
2. audit all the value lines to check against current implementation behavior.