Re: [css3-variables] review comments on latest draft

On invalid variables, I think the inherited value (or just invalid) would
nearly always make a better fallback than initial.

Quite a few properties on this list would not degrade well to initial
values in terms of not breaking the natural cascade:
https://raw.github.com/peteboere/css-crush/master/misc/initial-values.ini



On 25 May 2012 19:29, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Mon, May 21, 2012 at 10:56 PM, John Daggett <jdaggett@mozilla.com>
> wrote:
> > Looking over the CSS Variables ED again, I have a few questions/comments.
> >
> > * var-foo, var(foo) syntax
> >
> > The more and more I look at this, I think the choice of the prefix-
> > syntax is not a good one.  All CSS properties are named as
> > indivisible, hyphen-separated entities, I don't think making a syntax
> > where properties with a given prefix are magically separable is a
> > great idea.
>
> Yes, given my desired change of using "$foo" as the var use syntax,
> I'd like to sync this with the definition syntax and use "$foo: blue;"
> as well.
>
>
> > * variable names
> >
> > You don't really define what the set of possible identifiers is allowed
> to be.
> > For example, are the variables definitions/uses below valid?
> >
> >  var-inherit: red;
> >  var-initial: larger;
>
> Tricky.  Depends on exactly what syntax we end up with.  Under the
> current "var-foo / var(foo)" regime, I'd want to disallow those names.
>  Under the "$foo everywhere" regime, they're perfectly fine.
>
> >  var-\-\-foo: red;  /* tossed as invalid? */
> >  color: var(\-\-foo);
>
> "\-\-foo" is a legit identifier.  Nothing wrong with those.
>
>
> > Given the variable with the invalid ident syntax above, are these the
> > two declarations below equivalent?  Just to be especially evil...
> >
> >  font-family: bar var(\-\-foo); /* doesn't match var ( ident ) syntax */
> >  font-family: "bar var(--foo)";
>
> "\-\-foo" is an ident, but "--foo" isn't (it produces a DELIM followed
> by an IDENT).
>
>
> > * variable value definition
> >
> > I think you explicitly need to define what 'initial' and 'inherit'
> > mean in the context of var-* properties.  Are they simple values
> > assigned to that variable or are they the standard keywords with their
> > normal meaning?
> >
> >  p {
> >    var-family: sans-serif;
> >    font-family: cursive;
> >  }
> >  span { var-family: inherit; }
> >
> >  p > span { font-family: var(family); }
> >
> > Do spans with paragraph elements use sans-serif or cursive?
>
> Yeah, I probably need to make this clearer.  I lean toward keeping the
> general rule of "variables aren't interpreted at all except to replace
> other var references", so they aren't replaced at specified-value
> time.  Then, when they get expanded into a property, they'll have
> already missed the expansion opportunity (initial/inherit expansion
> happens at specified-value time, variable expansion happens at
> computed-value time), so it just makes the property invalid.
>
>
> >> The valid possible values of a variable property are almost
> >> completely unrestricted. A variable property can contain anything
> >> that is valid according to the value production in the CSS Core
> >> Grammar. The values do not have to correspond to any existing CSS
> >> values, as they are not evaluated except to replace variables
> >> occurring within them until they are actually referenced in a normal
> >> property with a variable.
> >
> > So are user agents required to do some form of validation on these
> > values?  And is the value production really the one you want to use
> > here, that allows all sorts of stuff that I can't see being valid
> > anywhere at use time.
>
> I've updated the draft with my proposal for the var syntax.  It's
> pretty simple, and allows every CSS value, and plenty of non-CSS
> values (for the JS-based use-cases).
>
>
> >> This specification reserves the use of all function tokens starting
> >> with the prefix "var" within variable properties. Authors must not
> >> use any such functions except as defined in this specification or
> >> future updates. If a variable property contains such a function, it
> >> must match the grammar defined in this specification or future
> >> updates; the use of such a function that does not follow the
> >> grammar, or that utilizes such a function that is not yet defined,
> >> makes the variable property invalid and it must be ignored.
> >
> > Er, how do I construct something today that follows something in the
> > future?  Time travel required? ;)
> >
> > Are you saying here that this spec effectively disallows the use of
> > var-xxx as an identifier?  How would an author "use any such function"
> > in today's CSS (as opposed to some future version of CSS)?
>
> Yeah, it reserves that class of function names, but not general
> identifiers.
>
> Using a function of that form that's currently undefined in CSS would
> be a syntax error *anyway* in a regular property.  I'm just making it
> explicitly invalid in a variable property as well.
>
>
> > I also think you need to define the value declaration in terms of CSS
> > tokens, since this is effectively a way of substituting CSS tokens from
> > one place to another.
> >
> > For example, are escaped entities passed through?
> >
> >  var-optical-size: \10pt;
> >  font-family: Modern var(optical-size); /* invalid? */
>
> Yup, done now.  That escape sequence produces an IDENT, not a DIMENSION.
>
>
> > * value use
> >
> >> A variable can be used anywhere a value is expected in CSS.
> >> Variables can not be used as property names, selectors, or anything
> >> else besides property values - doing so either produces an invalid
> >> value or, in some situations like the attribute value of an
> >> attribute selector, a valid value that nonetheless has no relation
> >> to the variable of that name.
> >
> > I think you mean to restrict this to values within style rules, no?
> > For example, the syntax below is invalid, right?
> >
> >  @font-face {
> >    font-family: test;
> >    src: var(foo);
> >  }
>
> Yes, sloppy wording on my part.
>
>
> > * invalid variables
> >
> >> When a variable property has its initial value, a ‘var()’ function
> >> referencing that property represents an invalid variable. Using an
> >> invalid variable in a property value makes the declaration invalid
> >> at computed-value time.
> >>
> >> A declaration that is invalid at computed-value time results from
> >> either using an invalid variable in a property value, or using a
> >> valid variable that produces an invalid declaration when it is
> >> substituted in. When this happens, the declaration must compute to
> >> the property's initial value.
> >
> > This ends up changing CSS semantics in some fairly subtle ways which I
> > think you should explicitly note.  Specifically, invalid declarations
> > with variables behave differently from invalid declarations without:
> >
> > /* without variables */
> >
> > p        { color: blue; }
> > p > span { color: 3px;  }  /* invalid ==> color == blue */
> >
> > /* with variables */
> >
> > :root    { var-span-color: 3px; }
> > p        { color: blue; }
> > p > span { color: var(span-color); }  /* invalid ==> color == black */
>
> Makes sense.  I'm cool with changing the behavior to be either initial
> or inherit based on the property.
>
>
> > * CSSOM
> >
> >> Variable properties are ordinary properties, and can be read or
> >> modified using all of the existing CSSOM APIs for reading or
> >> modifying properties.
> >
> > So getPropertyValue returns what value for "var-foo" if 'var-foo' is
> > never declared?  It *always* returns 'invalid' for var-* if the
> > variable hasn't been defined?
>
> Yes.
>
> ~TJ
>
>


-- 
Pete Boere
Web Developer