- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 13 Jun 2012 17:01:18 -0700
- To: Chris Eppstein <chris@eppsteins.net>
- Cc: Divya Manian <manian@adobe.com>, "www-style@w3.org" <www-style@w3.org>
On Wed, Jun 13, 2012 at 4:17 PM, Chris Eppstein <chris@eppsteins.net> wrote: > On Wed, Jun 13, 2012 at 3:49 PM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > And I'm not satisfied with this reasoning. Lots of people are not. Just > because variables cascade doesn't make them properties. If they were > properties, then properties could be read like variables without any issue. This doesn't make sense. I explained the reason why non-variable properties are problematic to hook into the variable-reference graph except as endpoints. (Normal properties have some implicit references between each other which aren't currently well-documented and is somewhat arbitrary anyway, so it would be difficult to avoid the occasional footgun where you accidentally got a reference cycle. We'd also like to be able to add new features which produce more references, but doing so would have the chance of producing new cycles in existing code and breaking pages.) You seem to be saying that if variable declarations look like properties, then they must be identical to properties (and properties must be identical to variable declarations), and if they're different at all, then they must look different. This is an overly-restrictive view which I cannot agree with. Variable declarations are properties - they use the same syntax, interact in the cascade the same way, etc. They *additionally* have the ability that their values can be substituted into other property's values, because they're simple enough that they're guaranteed not to have any implicit connections between themselves and any other property - only the explicit, obvious ones produced by using variables in their value. > Here's why I don't like the property syntax: It gives fine structure to an > identifier where there needn't be any. the delineation between declaring > something is a variable and the name of that variable should be syntax, not > a naming convention. Are you talking about the "var-foo" pattern for naming variables? I agree this isn't ideal, and would prefer using syntax like "$foo: blue;". I haven't made the change to the draft yet because it requires a change to the Core Grammar, and so I need the WG to agree to it first (and by that I mean the browsers that the WG represents). Note, though, that the difference between "$foo: blue;" and "var-foo: blue;" is trivial - it's just one character of prefix versus four. Either both are syntactic or both are naming conventions. > If it really is a property then make it a property with a -user- prefix and > then make all properties accessible for read. This is a lovely system. it's > not variables really. but it is completely consistent. If your going to draw > a line about what properties can be read as a value, then make this > delineation formal. I'm not sure sure what you're suggesting here. The best I can interpret this is that you're suggesting changing from "var-" to "-user-" as a prefix, and then making it possible to substitute any property's value into another. The former suggestion seems identical to the current draft except with a worse name. The latter I've already explained isn't going to fly. ~TJ
Received on Thursday, 14 June 2012 00:02:06 UTC