W3C home > Mailing lists > Public > www-style@w3.org > December 2012

Re: [css-variables] parse-time error handling in uses of variables

From: François REMY <francois.remy.dev@outlook.com>
Date: Fri, 7 Dec 2012 18:28:10 +0100
Message-ID: <DUB120-DS10F7740A9024587A8C2D93A5440@phx.gbl>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT