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

On Fri, Dec 7, 2012 at 9:28 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> |  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>

If we want typechecking, we should add it via an explicit mechanism
(and I'm not opposed, as it would enable things like animating
variables intelligently).

However, there's a reason that attr() has the restrictions that it
does on what the fallback values can be (if attr() isn't the sole
component value, the fallback *must* typecheck the same as the stated
type) - if you don't have that, typechecking takes combinatorial time
in the number of attr() references in the property.  That's not great,
and variables would trigger that all the time, since they don't have a
stated type.


> |  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.

Since variable values are not explicitly typed, this falls into the
problem I described above.  I know your proposal allows an explicit
type, but it's not required (and it defaults to typeless), so it's
still subject.


> |  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.

There is a reason I would refuse that possibility, if it's low value
and confusing.  ^_^

~TJ

Received on Friday, 7 December 2012 19:03:24 UTC