[css-text-3] Don't mince words about aliasing/shorthands with word-wrap

[Manishearth]

https://drafts.csswg.org/css-text-3/#propdef-word-wrap

The spec says:

For legacy reasons, UAs must treat word-wrap as an alternate name for the overflow-wrap property, as if it were a shorthand of overflow-wrap.

The "as if it were a shorthand" is a bit hand-wavy, especially since "as an alternate name" can mean something else.

In particular, we have two different ways of "aliasing" properties. One is by making them shorthands of the aliasee. The other is by making them redirect to the other property at parse time.

The difference crops up when doing things like serializing property declaration blocks. For example, the following CSS:

    #foo {
        word-wrap: break-word;
        overflow-wrap: break-word;
        align-items: flex-end;
        -webkit-align-items: baseline;
        foobar: baz;
    }

when serialized via document.styleSheets[0].cssRules[0].cssText in Firefox produces "#foo { overflow-wrap: break-word; align-items: baseline; }", whereas in Chrome/Safari it produces "#foo { word-wrap: break-word; overflow-wrap: break-word; align-items: baseline; }". This means that Firefox implements it as a "redirect alias", but Chrome/Safari implement it as a shorthand alias. All of them handle -webkit-align-items as a "redirect alias".

Browsers already use "redirect aliases" consistently for aliasing legacy prefixed properties. This concept of an alias is not defined in the spec, but is consistently implemented in browsers as something akin to:

If foo is an alias for property bar:

• At parse time, if you encounter a property of name foo, treat it as if it were the name you encountered was of property bar
• In CSSStyleDeclaration add accessors for the alias foo that under the hood work with property bar
• Nowhere else should there be traces of the name foo (including during serialization of a declaration block)

The compat spec uses this concept of "aliasing", but does not define it.

We should either explicitly spec word-wrap to be a shorthand, or define this other concept of property alias in the spec and use it here (and also use it in the compat spec). I personally prefer the latter solution since aliasing is currently unspecced but imo shouldn't be, and because this is the only case where a shorthand is used for aliasing.

cc @dholbert @dbaron @fantasai

[dholbert]

For reference, here's a link to where Firefox implemented this property as an alias (rather than a shorthand). I think we could just as easily implement it as a shorthand if it were clearly specced as such, though I agree with @Manishearth that an alias seems strictly simpler & more appropriate for legacy stuff (if aliases are a speccable concept).

[dbaron]

I'd also note that the normal rules for shorthands would produce a third result that is both (a) undesirable and (b) neither the Firefox nor the Chrome result, i.e., serializing the above rule to: "#foo { word-wrap: break-word; align-items: baseline; }", since it's possible to "condense" the declaration into a shorthand.

This is by the same principle that:

document.body.style.borderLeftColor = "green";
document.body.style.borderLeftWidth = "medium";
document.body.style.borderLeftStyle = "dotted";
console.log(document.body.getAttribute('style'));

produces:

border-left: medium dotted green;

in both Firefox and Chrome.

I think that also suggests that we need to specify the concept of aliases.

[dholbert]

FWIW, the spec-text for word-wrap used to be as follows:

For legacy reasons, UAs may also accept ‘word-wrap’ as an alternate name for the ‘overflow-wrap’ property. However this syntax non-conforming in author style sheets.

https://www.w3.org/TR/2012/WD-css3-text-20120119/#overflow-wrap

The language was changed to its current form ("as an alternate name...as if it were a shorthand") in this commit in 2012: 0532714

[dholbert]

(For the record, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=679068 and https://bugs.webkit.org/show_bug.cgi?id=166782 on the odd Blink/WebKit behavior here. It doesn't seem like they're actually treating it as a shorthand -- they're doing some special alternate form of aliasing, distinct from their regular legacy-alias behavior.)

[Manishearth]

cc @miketaylr since the compat spec references this concept of aliasing without defining it (and we should take input from them if we start building the exact definition)

[frivoal]

The wording is unintentionally loose, but the intent was to make it a shorthand. If we want to keep that, we should update the phrasing to:

For legacy reasons, UAs must treat word-wrap as an alternate name for the overflow-wrap property by implementing it as a shorthand of overflow-wrap.

Some of the reasoning for that is documented here: https://wiki.csswg.org/ideas/aliasing

TL;DR: we had a reasonably extensive discussion about how aliasing should work when "aliasing" break-before and page-break-before, and figured that shorthands were a good way to do that: well defined (including the OM) without needing to introduce any new concept, generally well behaved, deals well with the case when the legacy prop and the new prop don't have the exact same set of values.

I still think the idea has merit to it, but if implementations generally agree on a different aliasing mechanism, we should spec it and use that. Spec-fiction doesn't help anyone. Maybe we can keep exceptions and use shorthands when the legacy prop and the new prop accept different values.

[dholbert]

I'd also note that the normal rules for shorthands would produce a third result that is...undesirable
[serializing the modern property as its "shorthand" alias]

This doesn't actually seem to be what Chromium does for the few properties where they (ab)use shorthands to do aliasing.

Sample (live jsfiddle version):

document.body.style.webkitColumnBreakInside = "avoid";
console.log(document.body.getAttribute('style'));

This testcase produces break-inside: avoid; even though they implement -webkit-column-break-inside as a shorthand for break-inside, as shown here in their source and as noted in https://bugs.chromium.org/p/chromium/issues/detail?id=679068#c11

So, they do the Right Thing here, even though it's the opposite of normal shorthand behavior. (I wonder if that's due to a special-case codepath for shorthands that are only shorthands of a single property, maybe?)

[frivoal]

@dholbert @dbaron Since you consider shorthands as a bad aliasing mechanism, could you define what you consider to be a good one?