w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 651 forks source link

[css-align-3] `grid-*-gap` should be aliases instead of shorthands #8014

Closed cdoublev closed 1 month ago

cdoublev commented 1 year ago

grid-row-gap, grid-column-gap, grid-gap, are defined to be treated as legacy shorthands instead of legacy name aliases, but they must take the same grammar as the property they are aliasing, whereas CSS Cascade defines:

legacy name aliases: when the old property’s value syntax is identical to that of the new property, the two names are aliased with an operation on par with case-mapping [...]

I did not quite understand the whole discussions in #866 (especially the meeting transcript) that led to the changes in CSS Cascade for the above definition and the definition of legacy shorthands, so I am not sure the resolution is you must use legacy name aliasing when the syntax is the same. I also note that the details of the aliasing mechanism is intentionally left up to the UA for some legacy properties whose syntax is the same as the new property (eg. -webkit-user-select).

Loirooriol commented 1 year ago

In practice, the difference can be observed as such:

document.body.style.gridGap = "var(--gap)";
document.body.style.gap; 

Firefox and WebKit say "var(--gap)" because they implement grid-gap as an alias of gap. Blink says "" because it implements grid-gap and gap as independent shorthands.

cdoublev commented 1 year ago

In practice, the difference can be observed as such

Do you mean the difference between a simple alias and a legacy shorthand?

Blink says "" because it implements grid-gap and gap as independent shorthands.

Is this the expected behavior of a legacy shorthand? If so, I do not understand. grid-gap is a shorthand for gap which is a shorthand for row-gap and column-gap, so the parsed value for grid-gap must expand to declarations for both longhands. Why gap would then serialize to ''?

EDIT: oh right, ok, it is specific to substitution-value, I will have to think harder to understand how it could be wrong to not serialize gap with the substitution-value specified for grid-gap.

Loirooriol commented 1 year ago

Yes, this is just when using var(). For these gap properties I think it would be fine, but in general it would not, e.g.

document.body.style.cssText = "--bb: page; break-before: var(--bb)";
document.body.style.pageBreakBefore; // ""

It can't be var(--bb) since page-break-before: page would be invalid.

cdoublev commented 1 year ago

Then when syntaxes are different, UAs must implement the legacy property as a legacy shorthand, otherwise they can choose the mechanism they want.

cdoublev commented 1 year ago

I would not want to stray too far from the topic of this issue (which is to allow aliasing grid-*-gap as a simple alias), but did you had discussions about serializing the legacy shorthand with var() as a specified value (when it was declared for the target property), but with empty string as a computed/resolved value? This may avoid these confusing serializations:

style.pageBreakAfter = 'var(--custom)'
style.cssText; // 'break-after: ;'
style.breakAfter = 'var(--custom)'
style.cssText; // 'break-after: var(--custom);'

But how to serialize these cases may not be fully defined though (cf. #3109).

Loirooriol commented 1 year ago

This could maybe be addressed as part of #2515? https://drafts.csswg.org/css-cascade-4/#legacy-shorthand says

CSSOM will not use them when serializing declarations

but I think they should be used when a longhand has a pending-substitution value linked to the legacy shorthand. WebKit does this:

style.pageBreakAfter = 'always'
style.cssText; // 'break-after: page;'
style.pageBreakAfter = 'var(--custom)'
style.cssText; // 'page-break-after: var(--custom);'
cdoublev commented 1 year ago

I was thinking to serializing the legacy shorthand with getPropertyValue():

style['--custom'] = 'recto'
style.breakAfter = 'var(--custom)'
style.pageBreakAfter; // 'var(--custom)'
computedStyle.pageBreakAfter; // ''

But yeah, "using" it in a style block also makes sense to me, and I am fine with discussing it in #2515. I subscribed to it.

dbaron commented 5 months ago

Based on @Loirooriol 's comment in a Chromium code review, it sounds like:

I will also admit when reading the spec that I didn't catch the distinction that these weren't aliases.

dbaron commented 5 months ago

(We should probably also add helper functions to parsing-testcommon.js for testing that something is one or the other of these types of aliases, based on the technique in https://github.com/w3c/csswg-drafts/issues/8014#issuecomment-1302965043 .)

dbaron commented 2 months ago

FYI, Chrome has done this.

css-meeting-bot commented 2 months ago

The CSS Working Group just discussed [css-align-3] `grid-*-gap` should be aliases instead of shorthands, and agreed to the following:

The full IRC log of that discussion <jarhar> oriol: so we had the case with grid that we initially added the grid properties but then we wanted to ? as gap and then the currently the specification that grid gap should be a hsorthand of gap
<jarhar> oriol: however, but firefox and webkit implement it not as a hsorthand but as an alias
<jarhar> oriol: both cases basically have the same behavior but if you set a variable to the grid gap property, then you try to read the value of the gap property, if they are aliasses then you get the ? otherwise you get the emptry string
<jarhar> oriol: if it gets set to an internal ? value
<emilio> s/?/pending substitution/
<jarhar> oriol: and then i think that doing show interest or ended up doing it as an alias i dont remember the situation
<jarhar> dbaron: it is already done and shipping in 125
<jarhar> oriol: the propsoed resolution would be that grid gap should be an alias of gap and not a shorthand
<jarhar> oriol: not sure if i missed anything
<iank_> make the spec fiction, non-fiction :)
<jarhar> miriam: so thats the proposed resolution and is also whats now shipping?
<jarhar> dbaron: yes it is now shipping in 3 engines
<jarhar> dbaron: we added it to the agenda around the same time we made the change and it took some time to come to the meeting
<jarhar> miriam: great, lets resolve on the thing that all the engines do
<jarhar> fantasai: make grid gap aliases
<fantasai> PROPOSED: Make grid*gap properties be legacy name aliases
<fantasai> RESOLVED: Make grid*gap properties be legacy name aliases