> That does not address the use-case I presented for the proposal, which
> is to allow variables to substitute nothing for themselves, which is
> required for some semantics where the lack of a value is different
> from any value you can provide. (It's also convenient for some other
> cases, like lists of values.)
The use cases seem valid, I've to agree.
> Why is it difficult? The standard way to delete a property in JS
> still works ("style.removeProperty('var-foo')"), and I've added a
> second way using the convenience API ("delete style.var.foo").
What if you want to undeclare a custom property from CSS to make sure the children make use of their fallback instead of inheriting the parent value? This is also a very valuable use case in my mind, maybe more important than the previous one.
In the context of my CSS Reference proposal, I think I've a way to solve both use case in a natural way, with an 'undefined' value that would be the 'initial invalid' value of a custom property (undeclared) :
* {
something: get(my-property||fallback);
}
.selector {
// empty but valid token stream
my-property: /*nothing*/;
}
.selector > * {
// treat the property as undeclared
my-property: get(undefined);
}
In this case,
element.style.myUndefinedProperty would return 'get(undefined)' instead of ''
and
element.style.myUndefinedProperty=element.style.myUndefinedProperty
would still be a no-op (well, almost). To clear a property without using delete, I guess you can still to
element.style.myUndefinedProperty=';'
since that would be invalid and therefore will result in the declaration being dropped.
What do you think of that?