- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Thu, 13 Mar 2014 20:41:16 -0700
- To: Marat Tanalin <mtanalin@yandex.ru>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On Thu, Mar 13, 2014 at 2:17 PM, Marat Tanalin <mtanalin@yandex.ru> wrote: > 13.03.2014, 07:39, "Tab Atkins Jr." <jackalmage@gmail.com>: >> Simultaneously, I'm wrestling with the fact that basically nobody >> understands that one of the primary use-cases of Custom Properties is >> to do CSS polyfills, where you write your own properties with a "var-" >> prefix and interpret them with JS. This avoids the "have to re-parse >> the whole stylesheet yourself, and woe unto you if it's cross-origin" >> problem that today's CSS polyfills have. From what I can tell, it's >> the "var-" prefix that's misleading everyone - it's *so* closely tied >> to var(), mentally, that it prevents people from imagining any other >> use. >> >> Given that "tie it to var()" was one of my explicit justifications for >> sticking with the "var-" prefix, I'm very aware of how much I've >> hoisted myself by my own petard. >> >> So, suggestion. Assuming that we're sticking with the underscore >> thing for custom MQs/pseudo-classes/etc, I think we should move the >> syntax of Custom Properties to "any ident starting with/containing an >> underscore" as well. This'll tie the syntax more closely to the >> *other* "custom" things, which hopefully will lead to it being more >> obvious that this is literally a CUSTOM PROPERTY, not just a variable >> definition. > > Reasoning looks weak. +1 > > Those interested in polyfilling (and capable to write a polyfill) are themselves able (regardless of exact syntax of custom CSS properties) to easily recognize custom properties as a workaround way to avoid pure-script reparsing of entire stylesheet. > > As for the purpose of polyfilling itself, I'm still strongly convinced that _any_ (ANY) property should be easily accessible via JS _regardless_ of whether the property is standard or custom. So it should equally be possible to get specified value of `background-image`, or `my-super-custom-property`, or any other property. See my proposal of 2011-09-18: > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=14203 > > Using custom properties for polyfilling (while, of course, better than _nothing_) forces web developer to _duplicate_ value in both standard property _and_ a custom one. Such duplication is totally not the same as "just _adding_ a small prefix to property name" as Tab likes to incorrectly advertise. +1 > > Anyway, if to choose between solely the two options -- "start with _" or "contain _" -- as a custom property indicator, I tend to prefer the first one. > > >> The var() syntax is unchanged - the argument just switches to being >> literally the property name, rather than the property name minus the >> prefix. > > Using `var()` for accessing something that is not a variable looks confusing and therefore undesirable. Something like `prop()` would probably be more appropriate and intuitive. (And `prop()` should work for any property -- not just custom ones. ;-) > And in general about underscores: we shall admit that use of '_' in names as a custom attribute determinant is a hack. And quite nasty one. This approach has the same problems as '-' in HTML for custom element tags determination. Authors of the idea were forced to provide list of exceptions ( http://www.w3.org/TR/custom-elements/#concepts ). I am with Marat here: we just shall allow any arbitrary property name that is not known to the given CSS processor to be treated as custom property and to have prop() "functionoid" that will allow to refer any property, like: div { border-color: red; color: prop(border-color); } And for polyfills only use of arbitrary names for customs tags is really useful. I believe that is quite obvious. And yet, CSSOM shall have means to report "known" and "custom" status for particular property. I do remember that IE6 supported arbitrary named CSS properties and sky didn't fall since when. -- Andrew Fedoniouk. http://terrainformatica.com
Received on Friday, 14 March 2014 03:41:43 UTC