- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Fri, 14 Mar 2014 10:13:21 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: Marat Tanalin <mtanalin@yandex.ru>, "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On Fri, Mar 14, 2014 at 1:56 AM, François REMY <francois.remy.dev@outlook.com> wrote: >> 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 > > > That's simply impossible. Imagine some library would have used the > "transform" property to provide 2d transforms. Now, browsers decide to > support "transform" and start to honnour the property (validate syntax > according to the new specification and drop invalid rules, apply scaling at > the browser level, and have other side effects...). How can a page using the > library still continue to work properly? It can't. I do not see any "major" problems there. If the library is about (a) providing some unique functionality then it makes sense for the library to use "namespaced" names: #foo { coolib-bar: ...; coolib-baz: ...; } If it is about (b) polyfill use cases ( new standard emerged but some browsers do not support it yet ) then having ability reuse property name just makes that polyfill viable. I do not see how polyfill is possible otherwise. If some existing library is using some property (c) that become CSS standard and with different semantic then that library shall be fixed. If two different libraries use the same property name (d) but with different semantic then their authors shall resolve that conflict. Otherwise these libraries are incompatible. Naming conflicts, like case (d) above, are possible in either naming convention no matter what we will invent here. > > The only way we could accept this is by allowing authors do "declare" their > custom properties so that the browser stop to recognize them as normal > properties even if they can. That's out of scope for the current CSS Custom > Properties level (but I don't see why we could not envision such a change in > a further revision, if we think it's worth (I think there are valid reasons > you may want to declare your custom properties, but those reasons only make > sense once CSS-CP L2 & typing strategies)). > I don't think that such "declaration" is productive at all considering (b) and (d) cases above. Especially for polyfill purposes. > >> I do remember that IE6 supported arbitrary named CSS properties and sky >> didn't >> fall since when. > > > IE still do. I use this for my polyfills by the way (which improves the > performance dramatically in IE). > > By the way, I got hurt by the exact issue I described before for my > [css-regions] polyfill. IE11 started to support "break-before" and some > demos relying on the polyfill stopped working in IE because the stylesheets > contained "break-before: region" which IE11 doesn't recognize and dropped > (demos using "break-before: always" continued to work, however). And that is about completely different thing. It is about feature support detection rather than property naming schemas, something like this I believe: @supports not (break-before:region) { ... your polyfill rules... } -- Andrew Fedoniouk. http://terrainformatica.com
Received on Friday, 14 March 2014 17:13:50 UTC