[css-variables][cssom] Empty value doesn't round-trip #9847
Comments
|
The latter seems better, right? |
|
The first seems more appropriate and easier to implement.
Why authors would use |
|
@cdoublev I imagine authors using jQuery like $(".foo").css({
display: "block",
"--foo": "",
})which I think ends up using https://github.com/jquery/jquery/blob/527fb3dcf0dcde69302a741dfc61cbfa58e99eb0/src/css.js#L253C1-L257C6 if ( isCustomProp ) {
style.setProperty( name, value );
} else {
style[ name ] = value;
} |
|
Ok. They expect property values that include |
astearns
moved this from TPAC/FTF agenda items
to Regular agenda items
in CSSWG Agenda TPAC 2024
|
I agree that we should change I was at first concerned that this could break things that are depending on the custom property actually being empty - CSS usually doesn't care about whitespace, just token separation, but we do have a few places that care, like in selectors. But then I remembered that parsing is already specified to strip leading/trailing whitespace, so there's actually no behavior difference between I do think changing Serializing to other values, like |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> oriol: In the past, we didn't have any property that would accept empty value as valid<fantasai> oriol: but we changed custom properties to trim whitespace and accept empty values <fantasai> oriol: problem is with CSSOM, because in setProperty if you provide an empty string, then instead of trying to set an empty value it behaves as removeProperty <fantasai> oriol: so if you serialize a custom property that's empty string, it won't round-trip <fantasai> oriol: Some possible improvements <fantasai> oriol: 1. For custom properties we could stop doing removeProperty for assigning the empty string. <fantasai> oriol: but might have some compat problems at this point <fantasai> oriol: 2. Instead of serializing empty values as empty string, serialize a single space. This will round-trip. <dbaron> option 2 sounds good to me <fantasai> oriol: Could also use a comment instead of space, but space seems preferable <kizu> +1 to a space <ChrisL> single space seems a good way, to me <fantasai> +1 to space <fantasai> astearns: has anyone tried implementing? <fantasai> oriol: no <emilio> q+ <astearns> ack fantasai <emilio> fantasai: I think there's a benefit with being consistent in the way we remove properties <astearns> ack emilio <fantasai> emilio: +1 to that. Serializing to space is simpler and less inconsistent <fantasai> astearns: any opinions against? <fantasai> RESOLVED: Serialize custom properties with empty value as a single space |
tabatkins
added
Closed Accepted by CSSWG Resolution
Tested
|
Wouldn't it be appropriate to also change |
|
That falls out of the behavior defined here, right? |
|
Sorry, I think it does, actually. The problem is serialize a CSS declaration. It should not produce two whitespaces in a declaration block.
But you wanted me to open a separate issue? |
|
I realized that maybe I had misunderstood... should |
|
Ah, no, that should indeed just produce a single whitespace. (Ideally. Not very important either way, but it's definitely what I'd expect.) I'll go tweak. |
…ake sure serializing a decl doesn't produce two spaces for them. #9847
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890 UltraBlame original commit: 177f30aa00c92ae5dcc4263b7c02227b185b1d63
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890 UltraBlame original commit: 177f30aa00c92ae5dcc4263b7c02227b185b1d63
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890 UltraBlame original commit: 177f30aa00c92ae5dcc4263b7c02227b185b1d63
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890
…es serialize as a single space., a=testonly Automatic update from web-platform-tests Per w3c/csswg-drafts#9847, empty variables serialize as a single space. (#50890) -- wpt-commits: 43b3eef3baa36fbe158ddc5f31ab945fd49f2c9b wpt-pr: 50890
I would expect the JS to be no-op as per the round-tripping principle.
However, an empty string has a special meaning in
setProperty: it behaves asremoveProperty, even though it's valid for custom properties.Some reasonable possibilities:
setPropertytoremovePropertyfor custom properties, since empty string is a valid value. Authors could explicitly useremovePropertyif they want to remove. I suspect this may not be web compatible at this point." "instead of""so that they can be safely used insetProperty, as @prjnt proposed in [css-syntax] Trim whitespace around declarations? #774 (comment)The text was updated successfully, but these errors were encountered: