Re: Proposal for adding variable declaration blocks

On Fri, Jul 18, 2008 at 4:57 PM, James Elmore <James.Elmore@cox.net> wrote:
> Agree, but would wish it were not so because of prior experience with
> overlapping names in programming languages which allow that sort of thing.
> It just makes reading the code harder.

Personally, my feelings are the opposite.  Since I'm most used to PHP
(unfortunately :P), I get annoyed in languages like Python when I want
to call a variable something like "class" -- say, to store the HTML
class of a tag I'm outputting -- and it doesn't work.  It's probably
an individual preference sort of thing.

On the other hand, disallowing keywords can cause problems for reverse
compatibility if new keywords are added.  Implementing a new feature
may mean that stylesheets that were previously valid no longer are.
This is probably not desirable.  If people feel that reusing keywords
is bad form, they can always avoid it as a stylistic matter, just as
they tend to indent properly and use comments.

> <style>
>    declare { $font: Times, New Times, serif; }
>    p { font: $font 12px blue; }
> </style>
>
> Maybe that points out the confusion better than 'color'.

I don't find it at all confusing.  It makes perfect sense to call the
variable for storing a font "$font", and to use it in conjunction with
the font property.  But that's me.

> In terms of parsing, if the sigil is not present, then standard CSS syntax
> would declare the use of keywords invalid, otherwise a declaration might
> just be a CSS selector with a selector for an element of type 'declare'

Using such syntax is broken in the first place.  CSS can be used to
style documents with elements named "declare", or anything else.
Variable declaration needs to use at-rules or similarly unambiguous
constructs.  In that case the rules for parsing the at-rule can be
separate from attribute parsing anyway, or so I assume (not having
looked carefully at CSS parsing rules).

It's a fairly trivial difference anyway.

Received on Friday, 18 July 2008 21:13:06 UTC