Re: [css-d] Ready for Pre-processors?
Barney (anyone interested in the subject), I understand you’re passionate and are familiar with the subject, so I simply caution to brush away preprocessor-skeptic advice, and to underestimate traditional code optimization. CSS optimization is a complex issue. The example I gave is powerful because it shows how a fantastically effective technique is difficult to be employed automatically (to my knowledge no preprocessor has even tried, for good reasons): “using every declaration just once” changes the order of rules, and can have undesired side-effects if applied blindly. (I’m coming from a career of exploiting style sheets.) However, it’s just *one* technique. The point is that there are more such techniques. I don’t think we identified all of them—that’s why I urge to be careful with preprocessors (garbage in, garbage out), but also wish the CSS working group to focus more on the side effects of all the new features [1]. Now, there’s of course use for preprocessors. But there can’t be a blanket yes or no: use of them depends on the project, the size and skill of the team, the goals and ambitions, c. Somebody just voting yes (or no!) without considering these points doesn’t give sound advice. As for small projects, I recommend to use and—cherish them. Small projects are great to build experience and to test theories. Try *not* to use CMSes, libraries, preprocessors, and such in small projects. The size—small :)—should permit that. There are many valuable things to learn in small projects. One is how to avoid problems that are annoying in a small project, but devastating in a big one. And another is to employ techniques that improve code in a small project—and also in a big one. This all assumes people to be interested in tailored, optimized code. I view this as the hallmark of a professional web developer, but I understand that some of us are so used to being “pragmatic” that anything that gets the job done faster wins. Alas, getting the job done doesn’t mean getting the job done well. And I think that’s also important to consider, at least be aware of, in this debate. Otherwise preprocessors still mean but one thing: garbage in, garbage out. I hope this helps. [1] http://meiert.com/en/blog/20131205/spec-fragmentation/ -- Jens O. Meiert http://meiert.com/en/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
http://blog.millermedeiros.com/the-problem-with-css-pre-processors/ Irrelevant to the subject here, which is about the discussion of preprocessors on this list. Just following with one ear but why would that be irrelevant? By that logic, if you were to buy a car and somebody warned you it would explode once you get in, you’d ask not to be interrupted while signing the contract? I argue general concerns always worth listening to. My two cents: assuming the project is complex enough to even warrant something like a preprocessor, it’s still better to exploit “native” optimization options first. Now in the age of ever-growing specs (feature creep) and ever-growing tools (preprocessors c.), few explore such options. (That’s a problem for all of us.) My favorite example is that even something simple as using every declaration just once [1,2] can reduce CSS size and complexity by around 20% (empirical value). That’s not peanuts if you’re talking style sheets with 1,000s of lines. [1] http://meiert.com/en/blog/20080515/css-organization-and-efficiency/ [2] https://developers.google.com/speed/articles/optimizing-css -- Jens O. Meiert http://meiert.com/en/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
apr 27 2014 12:18 Jens O. Meiert j...@meiert.com: Just following with one ear but why would that be irrelevant? Read the OP. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
Jens, a big advantage of CSS pre-processors is that they can facilitate management of selectors in the manner you describe. Indeed, the advantages you cite are one of the key reasons large teams decide to adopt pre-processors in the first place. A terrible prejudice I have towards the authoritative experts on this list is that there is a perennial attitude geared towards hand-pruning the style sheets of small consistent sites, whose any change in content or requirements would duly be enacted through a conscientious reconsideration of every line of code by one author. CSS pre-processors appeal mostly to people who work with very large web projects with many developers of different levels of ability, which must be built to order in limited time, and then set loose in to the wild. As a brief example, SASS's 'extensions' allow the definition of a rule under a given name (for example 'clearfix'), which can be called in by any number of selectors: the compiled CSS then makes sure that all selectors invoking this abstract are condensed into one rule, without the author having to manually insert the selector into that declaration, and without the contrivance of appending a 'clearfix' class in the markup. This in turn works wonders with version control and other paradigms suited to large teams working on the same project. Of course, the output CSS can be under-optimised. You may find that bytes could have been shaved off, and decide that this is worth taking action over. But that's true of anything: pre-processors are definitely not scornful of this attitude; they offer a way to sustematise it. -- Regards, Barney Carroll barney.carr...@gmail.com +44 7429 177278 barneycarroll.com __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
On Apr 24, 2014 11:46 AM, Andrew C. Johnston attyjohns...@yahoo.com wrote: Hello All: I have been a bit busy and haven't been keeping up, how does the list feel about discussions involving LESS, SASS and SCSS? I have a Sass project where I have to make some changes and feel a little lost. Not sure if I would have any specific question to ask here, but is the list open to these technologies as well? Cheers! I'd also vote no. Using SASS for more than a year now, I've found that issues I run in to have less less to do with CSS per se, than SASS or Compass, and would prefer this list purely CSS related. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
I didn’t get the original for this. Eric? apr 25 2014 03:21 John Johnson j...@coffeeonmars.com: certainly seems appropriate to me…I’d vote “yes” for the powers that be to consider. I’m for it as long as there is a clear connection to CSS, which there typically is. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
On Apr 25, 2014, at 1:43 AM, Philip Taylor p.tay...@rhul.ac.uk wrote: Eric wrote: I'll raise my hand and say I'm against it. Not because I have a problem with CSS pre-processors rather because this is a CSS list. Pre-processors are simply a tool used to write CSS in a more programmatic way and then 'compile' it I agree, and each is presumably different; a separate list for such things (or no list at all) would allow this list to retain its focus. Possible Holy War as well... __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
25 apr MiB digital.disc...@gmail.com: I didn’t get the original for this. Eric? Andrews original was found in the spam folder for unknown reasons. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
At 06:53 AM 4/25/2014, Tom Livingston wrote: Possible Holy War as well... CSS pre-processors do not write optimized code by default, it is very easy to write code that will result in bloat and reduced performance. It didn't take much Googling to find this article: http://blog.millermedeiros.com/the-problem-with-css-pre-processors/ If that isn't reason enough to shun them... Reese __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
apr 26 2014 00:36 Reese howel...@inkworkswell.com: CSS pre-processors do not write optimized code by default, it is very easy to write code that will result in bloat and reduced performance. It didn't take much Googling to find this article: http://blog.millermedeiros.com/the-problem-with-css-pre-processors/ If that isn't reason enough to shun them… Irrelevant to the subject here, which is about the discussion of preprocessors on this list. __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
certainly seems appropriate to me…I’d vote “yes” for the powers that be to consider. J __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
I'll raise my hand and say I'm against it. Not because I have a problem with CSS pre-processors rather because this is a CSS list. Pre-processors are simply a tool used to write CSS in a more programmatic way and then 'compile' it CSS for use by the UA. I just think it would be a thick layer of static on this list. Just my US$0.02 worth. Eric On April 24, 2014 at 11:46 AM Andrew C. Johnston attyjohns...@yahoo.com wrote: Hello All: I have been a bit busy and haven't been keeping up, how does the list feel about discussions involving LESS, SASS and SCSS? I have a Sass project where I have to make some changes and feel a little lost. Not sure if I would have any specific question to ask here, but is the list open to these technologies as well? Cheers! __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
Re: [css-d] Ready for Pre-processors?
Eric wrote: I'll raise my hand and say I'm against it. Not because I have a problem with CSS pre-processors rather because this is a CSS list. Pre-processors are simply a tool used to write CSS in a more programmatic way and then 'compile' it I agree, and each is presumably different; a separate list for such things (or no list at all) would allow this list to retain its focus. Philip Taylor __ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
