Re: [css-variables] the new ED for CSS Variables

On Feb 18, 2012 4:50 AM, "François REMY" <fremycompany_pub@yahoo.fr> wrote:
>
> Doesn’t preprocessing requires the whole file to be downloaded?
Either way it requires a whole file to be downloaded, so I don't see your
point there.  In fact, there should be network savings if you do it right
as a file to be processed should be smaller than the css it represents.

It it’s the case, I think it’s pretty dramatic.
> And, seriously, I prefer that one developer does his own preprocessing
one time that to have the same preprocessing done a million of time in
local browsers.
>

Well, but... If the counter argument is to build this complexity into CSS
itself and therefore into browsers, it won't necessarily be any faster than
what I am describing and it requires significant changes, breaking core
grammar which (seems to me) is going to be a tough sell.

All of the major techs supported in the broswer, including css, are
serialized forms which have to be parsed and processed.   A simple form
could be processed natively very very fast, and browsers can do all kinds
of magic there to gain efficiency, especially on repeat visits.

Today, people can preprocess and that is great.  My whole point here was
simply that if there is a serious argument to be made that this can achieve
features which are not in css today (I think there probably is) and which
both appealing and should be supported natively, but it doesn't easily
"fit" CSS...this seems a simpler option.

Again, I'm not pushing for this, just throwing it out as a possible
alternate way forward for some of the things that fit the description above.

> From: Brian Kardell
> Sent: Saturday, February 18, 2012 1:16 AM
> To: Chris Eppstein
> Cc: François REMY ; www-style@w3.org ; Arron Eicholz ; Tab Atkins Jr. ;
Dirk Pranke
> Subject: Re: [css-variables] the new ED for CSS Variables
>
>
> On Feb 17, 2012 6:51 PM, "Chris Eppstein" <chris@eppsteins.net> wrote:
> >
> > I'd also like to keep a long view here with respect to other features
like mixins and user-defined functions. The current var-based syntax seems
very unnatural in those contexts.
> >
> > Chris
> >
> >
> There are some excellent preprocessors out there... sass is great but it
is preprocessing what winds up being CSS. Sass itself is not CSS and
without some core changes it can't be.  This presents problems to more than
just browsers, it affects anyone who parses CSS.  IMO, Tab's draft feels so
different from those precisely because it is.  It fits CSS and while it
doesn't allow some things those preprocessors do, it enables other.
>
> Rather than worry about dramatic changes to CSS to support things that
actually ARE handled really well by a preprocessor already, why not just
keep it as a preprocessor?  I think its an easier case to make, even to
make the case that the browsers should adopt and natively support some
preprocessing of a new mime type that ultimates turns into CSS than it is
to change the core grammar.
>
> Maybe not, I could be wrong, just another way to look at it.
>
>
>
> > On Fri, Feb 17, 2012 at 3:44 PM, Dirk Pranke <dpranke@chromium.org>
wrote:
> >>
> >> On Fri, Feb 17, 2012 at 3:26 PM, Arron Eicholz
> >> <Arron.Eicholz@microsoft.com> wrote:
> >> > On Friday, February 17, 2012 2:43 PM Chris Eppstein wrote:
> >> >>Variables are a new primitive. Seems justified.
> >> >
> >> > Altering the core grammar takes a great deal of investigation. An
alteration to the core grammar requires us to analyze all 400+ existing,
proposed and suggested properties, including SVG properties, (there are
actually 606 by my last count, but who is keeping track). We must determine
if any of them have to be updated, altered or changed to account for this
new primitive. Don't forget to multiply all the values that all those
properties take and how they will be affected. This is an extensive amount
of work and who knows what we might miss when looking at all the values
that those properties take.
> >> >
> >> > Now take into account the OM and Javascript side of things and even
how frameworks interact. Will a '$' interfere or makes things confusing? My
guess is it will, at the very least it will make things confusing. It also
wouldn't shock me if it broke a Javascript library somewhere.
> >> >
> >> > In the end the cost is very high for changing the core grammar.
Going with 'data-' or 'var-' really doesn't have much impact in this regard
and would be the best solution to move things quickly.
> >> >
> >>
> >> Is "move things quickly" really the priority? It seems like "have the
> >> most intuitive syntax" would be a more important goal. Of course,
> >> "don't break the web" is probably a more important goal still :)
> >>
> >> FWIW, if we were to keep the currently proposed notation (more or
> >> less), "var-" seems better than "data-" to me; I too see the potential
> >> confusion between this and data- attributes in HTML, and data- doesn't
> >> scream "variable" or "value" to me.
> >>
> >> -- Dirk
> >
> >