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

On Mon, Mar 17, 2014 at 4:08 PM, Sylvain Galineau <galineau@adobe.com>wrote:

>
> On Mar 17, 2014, at 12:27 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>
> > * Sylvain Galineau wrote:
> >> On Mar 17, 2014, at 12:04 PM, Bjoern Hoehrmann <derhoermi@gmx.net>
> wrote:
> >>> I am more concerned about having to debug through
> >>>
> >>> #something {
> >>>   -webkit-border-radius: 5px;
> >>>   width: 200px
> >
> >> Sure, this can happen as long as some browser vendors preserve prefixes.
> >> But I'm not sure why this would be worse than:
> >>
> >>> #something {
> >>>   -webkit-border-radius: 5px;
> >>>   width: 200px
> >>>   -moz-border-radius: 5px;
> >>>   height: 200px;
> >>>   --scroll: carousel(...);
> >>>   -o-border-radius: 5px;
> >>>   border:radius: 5px;
> >>>   --says: groovy;
> >>> }
> >>
> >> ...where the custom props carry no information as to what makes use of
> >> them. Which is harder to investigate?
> >
> > To go back to Daniel's orginal argument about author familiarity, it
> > should rather be something like
> >
> >  #something {
> >    -webkit-border-radius: 5px;
> >    width: 200px
> >    -moz-border-radius: 5px;
> >    height: 200px;
> >    data-jquery-scroll: carousel(...);
> >    -o-border-radius: 5px;
> >    border:radius: 5px;
> >    data-sassy-framework-says: groovy;
> >  }
> >
> > Where the vile ones stick out their ugly heads.
>
> I get that you prefer to differentiate them. I'm just not convinced it's
> harmful if they sort of look alike. Never mind that two major browser
> vendors have already given up on using them for new features.
>


There are two problems with this: First, you would have to reserve all
known vendor prefixes because those clearly do something 'else'.  Second,
on the inverse, once authors start using them those would be unusable by
any new agent.  The later is kind of unbound, so you've basically just
hosed every new agent out or randomly they will drop author rules when they
come round.  This seems bad and unnecessary and kind of like a violation of
the spec to me.  Using underscore instead of dash for extension prefixes is
allowed, but no one does that.  It should require no changes (assuming
everyone implements per the spec, it's almost as good, it's actually easier
to access via a JavaScript API anyway, sets them apart nicely, etc.  And it
shouldn't really have the underscore hack problem chris mentioned either
(though, those wouldn't be so much a problem, they would just create
properties unnecessarily) since its _prefix_blah... A vanishingly small
number of things using the underscore would be meeting that criteria as
well.

Unsure why no one is commenting on that idea, it seems like the most
good/least bad option.



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