Re: [css-variables] ...let's change the syntax

On Fri, Mar 14, 2014 at 1:13 PM, Andrew Fedoniouk <news@terrainformatica.com
> wrote:

> 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: ...;
> }
>
> Yes, and, how can you ensure that?  Provide an indicator reserved by the
language by promised never to be used by the language. That is the topic of
discussion here.




> 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.
>
>
CSS Custom Properties enable p(r)ollyfilling of things that go beyond
proposals for actual CSS properties or fills for properties that are
implemented in some browsers but not others because they carry underlying
matching, calc rules, etc.   It's not actually strictly necessary to
polyfill CSS directly, merely to provide a single author specified version
which can choose to defer to a native implementation or not.  This is
actually probably better because it means you don't have to reserve
anything really in order to future proof both CSS and (if you are careful)
things that were written with something author created (your c and d) below.




> 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
>
>


-- 
Brian Kardell :: @briankardell :: hitchjs.com