- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 10 Feb 2011 14:01:06 -0800
- To: David Singer <singer@apple.com>
- Cc: "Linss, Peter" <peter.linss@hp.com>, www-style list <www-style@w3.org>
On Thu, Feb 10, 2011 at 1:55 PM, David Singer <singer@apple.com> wrote: > On Feb 10, 2011, at 12:44 , Tab Atkins Jr. wrote: >>>> Using a variable that hasn't been declared is a syntax error. (It's >>>> valid to use a variable that hasn't been declared *yet* - the >>>> declaration may appear later in the stylesheet, or in another sheet >>>> entirely.) >>> >>> Don't use the term "syntax error" here. I read this as "invalid and may be >>> thrown away at parse time", which is clearly not your intent. >>> >>> Better to define referencing an undefined variable as having a 'null' >>> value, or more likely a value of 'invalid' which is a special token >>> meaning that it's there, but will always be invalid. You also need a way >>> to "unset" a variable via script and/or set it to a null/invalid value. >> >> You definitely understand my intent here. I'm open to better ways to >> express this. I like the idea of an always-invalid special value. >> I'll put that in the draft. >> >> An interesting issue - how does an invalid variable get treated when >> you ask to serialize the property? I'm going to assume it's >> serialized as itself, since the syntax for variable names is already >> designed to always be invalid. (Is this true?) > > Do you mean to say that using a variable that is not defined, there is an implied value which if found in any construct, in any position where a variable may go, causes the construct to have a syntax error? (As if there were a special token "wrong!" ). Yes. ~TJ
Received on Thursday, 10 February 2011 22:01:59 UTC