- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 7 Dec 2012 18:28:10 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "L. David Baron" <dbaron@dbaron.org>, <www-style@w3.org>
| This is unacceptable for several secondary use-cases for Variables, | namely using a CSS variable in JS to effectively get a "DOM-tree | scoped" JS variable, and using CSS variables as "author-prefixed" | properties that are preserved by the engine and used for polyfills. Wait... what? I didn't say the *property* has to be given a type (in case you don't remember, I'm actually one of the persons strongly defending the use of custom properties for prolyfills and web components) but that all *references* _should_ accept type enforcers/converters. By default, the type converter would be "any" and would accept any <value>. It's just that you could for exemple have a "string" converter that would actually convert the value stored in the variable as a string, as the attr(... string) proposal would do. Or maybe specify a fallback value other than "initial" in the case the value of reference is not a valid <length>. <dream>It would be so nice if people actually took the time to read Brian & I proposal at some point...</dream> | attr() validates its fallback value at parse time | *so that it will either be discarded at parse time or guaranteed | valid at computed time*. If you did read my reply to the other mail of David, you would know that I came up with an unified model where the fallback value of any kind of references is type-checked at parse time, not just attribute ones. My goal right now has been to unify 'references' under a similar umbrella and common behavior instead of specializing all kinds of references. If something is good for one kind of reference, there's no reason it would be bad for another one. | Even if the fallback is omitted, because we know | the value's intended type, we can provide a default fallback that will | be valid for use in that position. My proposal includes the possibility for the author to add such type information if he want in addition to a fallback value. There's no reason why you would REFUSE an author the possibility to type check its variables. In fact, it's really important to do so, because if you do not check anything, you can get really difficult to debug CSS files where something goes wrong for a very complex reason and you don't even understand why. If you have type enforcers/converters, things are much better already.
Received on Friday, 7 December 2012 17:28:39 UTC