Im ok with this, but do worry about the general trend which I have recently contributed to (if and unless on <define> in <csc> and siblings, though this is, as with <cc> a mapping of conditional java properties to #define values.
Ditto. Generally, I favour usefulness over a theoretical, unimplemented design so given a valid use case I think keeping the change is a good idea, unless people want to talk about implementing a redesign to address the general trend more cleanly.
On the subject of if/unless, what if we modified the tests to not just take the name of a property, but take any of the values of true either in the string itself
If we wanted to do this, shouldn't we use attributes other than "if" or "unless", for backwards compatibility? "iftrue" and "unlesstrue" would be ugly choices, but you get the idea. We could deemphasize "if" and "unless" in the documentation since people find them confusing.
Or we could redirect the problem a little. How about a "condition" attribute that is a reference to an existing condition at the top level? The property that is set if the condition is true when called in this way could be a special internal one for use only by the element with the condition attribute, hidden from the user. So whether it is tested as set/unset or true/not-true would be irrelevant to the end user.
