- From: Brian Kardell <bkardell@gmail.com>
- Date: Fri, 17 Feb 2012 20:34:32 -0500
- To: Chris Eppstein <chris@eppsteins.net>
- Cc: François REMY <fremycompany_pub@yahoo.fr>, "www-style@w3.org" <www-style@w3.org>, Arron Eicholz <Arron.Eicholz@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Dirk Pranke <dpranke@chromium.org>
- Message-ID: <CADC=+jd-3p1fo_4oF+Y2EDu6=188NAzQSDn=p3cnEyYdGiQWYw@mail.gmail.com>
On Feb 17, 2012 7:27 PM, "Chris Eppstein" <chris@eppsteins.net> wrote: > > While that would be very good for my career, I think it would be bad for developers and users alike. CSS preprocessors produce bloated output that is difficult to debug. Would moving it into CSS automatically make it easier to debug or is that ultimately reliant on the tools you use? The tools we have today know how to understand css as it exists today right? The reason, in my experience that they are hard to debug is that there is no way to find out where in the preprocessed source those values came from. Whether this were moved into the browser as a new thing or made a part of css, I think the tools would require changing to give you that. Also, the underpinnings of how they are handled by the broswer would require fairly significant change. On the other hand, a macro-like preprocess built into the browser could give you all those things too without almost trivial cost by comparison. > Sass has shown that with more syntactic features like mixins and selector inheritance most of the presentation can move from the markup's classitis into the stylesheet's definitions -- actually delivering on the promise of a clean separation of markup and design. Unfortunately, the realities of performance require that in many cases, you cannot build this way. It makes me sad -- which is why I want to bring many of Sass's feature to CSS itself. > > Chris > > On Fri, Feb 17, 2012 at 4:16 PM, Brian Kardell <bkardell@gmail.com> wrote: >> >> >> 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 >> > >> > > >
Received on Saturday, 18 February 2012 01:35:03 UTC