from the everything-should-be-in-plain-text dept.
Though somewhat DRY reading, the author provides salient commentary on how many declarations appear in style sheets, how many of those are unique, and offers perspectives on what that means for developing and maintaining web sites. From https://meiert.com/en/blog/70-percent-css-repetition/:
Teaser: Check on how many declarations you use in your style sheets, how many of those declarations are unique, and what that means.
In 2008 I've argued that using declarations just once makes for a key method to DRY up our style sheets (this works because avoiding declaration repetition is usually more effective than avoiding selector repetition—declarations are often longer). I've later raised the suspicion that the demand for variables would have been more informed and civilized had we nailed style sheet optimization. What I haven't done so far is gather data to show how big the problem really is. That's what I've done in the last few weeks.
In a Google spreadsheet I've collected the Top 200 of content sites in the The Moz Top 500, and taken another 20 sites related to web development for comparison. (I've also added 3 of my sites out of curiosity.) I've then used the extremely useful CSS Stats to determine the total number of CSS declarations, as well as the number of unique declarations, to calculate ratios as well as averages: You get the idea as soon as you check out said spreadsheet.
[...] Before we dissect the numbers, let's first quickly establish what one can consider good CSS development practice:
As with all code, don't repeat yourself (DRY).
In CSS, an effective way to not repeat yourself is to use declarations just once. The resulting repetition of selectors is less of a problem because declarations are usually longer than selectors—and yet variable selector length makes using declarations once a soft rule that still requires thinking. (More as follows.)
No repetition of declarations is theoretically attainable, but in practice, two things interfere: Not just in cases when selector order is mandated (another oft-forgotten subject, yet there are detailed proposals on how to standardize selector sorting), the cascade may not permit grouping of all selectors; and when strict separation of modules (CSS sections) is important, one may also tolerate some repetition. These two pieces deserve more elaboration, but relevant here is the note that strict separation of modules should not be used as a blanket refusal to curb declaration repetition—as the data show, that would be foolish.
Now, what is a reasonable amount of repetition? From my experience, 10–20%; in other words, 80–90% of a style sheet should consist of unique declarations. Reality, however, looks vastly different, and here we get to the 70%.
I found the analysis to be informative and eye-opening. What have you found to be best practices when it comes to Cascading Style Sheets?
(Score: 4, Interesting) by krishnoid on Tuesday June 27 2017, @12:57AM (1 child)
I've found this chart [standardista.com] to be a good syntax reference for declaring and overriding styles.
(Score: 1, Informative) by Anonymous Coward on Wednesday June 28 2017, @01:14AM
http://tachyons.io/ [tachyons.io]
"Don't let the cascade slow you down. When you apply a class to an element, there is nothing in the cascade to override its effects. You get rapid feedback on how your css is affecting your markup without wasting time debugging why your styles are being overridden."
(Score: 3, Insightful) by c0lo on Tuesday June 27 2017, @01:15AM (1 child)
DRY applies to things that are the same in nature (representable by a common abstraction)
Just because a two things happen to have the same attributes, it does not make them the same in nature (even if both the grass and emerald are green, it doesn't make the grass a precious stone, nor the emerald able of photosynthesis).
"Walks like a duck, quakes like a duck..." does not necessarily imply we are looking at a duck.
However, as Douglas Adams put: "If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands." That's a good practice when taken together with the "anti-pseudo-DRY" pill above.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by frojack on Tuesday June 27 2017, @03:21AM
Everybody using the same tools. Hacking and hammering together pieces and parts from the same sources.
Is it any wonder the end product contain the same hammer marks?
No, you are mistaken. I've always had this sig.
(Score: 2) by tibman on Tuesday June 27 2017, @01:50AM (10 children)
My only gripe is when i find every style on the site in one css that is included on every page.
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @02:11AM (9 children)
What's the problem with that?
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @04:46AM (8 children)
You run into situations, such as the following, with the rules. Output cutesy of the Chrome Developer Tools:
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @08:51AM (2 children)
And?
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @10:12AM (1 child)
The bandwidth of IPoAV isn't very high. ;-)
(Score: 1, Insightful) by Anonymous Coward on Tuesday June 27 2017, @11:05AM
The bandwidth is high the first time the css file is requested. For the rest of the pages it is already cached and does not need to be downloaded again.
Is this approach efficient? That depends on the number of pages with unique styles. Is it more efficient than page-specific stylesheets? That depends on the number of pages a visitor actually views. Does it cause my OCD to bristle? Yes. Does it make my monkey cry? Absolutely.
What I generally do to address this type of situation is have a master stylesheet that applies to everything that is in all the pages and then have supplemental stylesheets - either page specific or a few pages combined - to address the items that appear on one or more individual pages.
There is no perfect solution to this unless you go with one of those annoying "cram everything on to one never ending page" websites. The you lower the number of unused items to only those that should be culled from the stylesheet entirely.
(Score: 2) by ledow on Tuesday June 27 2017, @10:40AM (4 children)
Apart from a processing point of view (and I imagine that unused elements in a stylesheet barely figure in terms of overall parsing time), what's the deal?
It means the first page load caches the stylesheet for the entire site, preventing refetching. And, if the browser has any sense, it could interpret it at that point and keep hold of the interpretation in the cache, ready for reducing the processing time of the next page.
To be honest, it makes MORE sense to me to have global style sheets than anything else.
(Score: 2) by tibman on Tuesday June 27 2017, @03:06PM (3 children)
Including all the site's css on every page is like including all the site's javascript on every page. You aren't doing good things for the end-user. It's not just a consumer problem. It's also a development one. I just opened a css file for the project i'm on and it's 8,602 lines long. Nightmare. A css file for an entire site becomes a dumping ground. So many styles in here that are used on only one page out of hundreds of pages.
A good way to deliver css is have the sheets broken out by feature or by experience. Then minify and package them together for those specific features/experiences. A client won't ever need the css used for the admin pages, for example. Having a tool that identifies styles that are never used is also great. So you can delete all the dead stuff.
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @03:33PM (2 children)
The same, except that they are not alike at all. JS has far worse memory/perfomance footprint.
(Score: 2) by tibman on Tuesday June 27 2017, @04:28PM (1 child)
You'd be amazed how expensive css selectors can get in a deep dom.
I just googled and found this: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/#h-H1_6 [benfrain.com]
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Wednesday June 28 2017, @07:41AM
JS will dwarf those numbers any day. While also blocking everything else.
(Score: 1, Informative) by Anonymous Coward on Tuesday June 27 2017, @02:27AM (8 children)
CSS writing is like being a garbage pickup person.
(Score: 1, Touché) by Anonymous Coward on Tuesday June 27 2017, @05:03AM (3 children)
Someone whose job keeps the society from breaking down?
(Score: 2) by c0lo on Tuesday June 27 2017, @05:45AM (2 children)
Even if something needs to be done, does it mean that I should like it?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @11:55AM (1 child)
You'd certainly bitch and moan if it wasn't being done.
(Score: 2) by c0lo on Tuesday June 27 2017, @12:29PM
No moaning at my age, no more.
I have better reasons to groan than CSS. My bad back in the cold weather, for instance.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @05:46AM (2 children)
CSS is a dumb language. Whoever invented it should be forced to program in Brainfuck for eternity.
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @05:53AM
Do you expect CSS to be a programming language somehow?
Perhaps you'd feel better with XSL [w3.org]?
(Score: 2) by tangomargarine on Tuesday June 27 2017, @02:55PM
Do you hate XML, too? And SQL?
JavaScript would make more sense to hate. That's a "real" (non-DSL [wikipedia.org]) programming language, and it's ugly as hell.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 4, Insightful) by c0lo on Tuesday June 27 2017, @05:49AM
At least you have a truck to carry the garbage, instead of individual buckets to carry to the dump and back (i.e. styling using <b>, <blink> elements and 'border' and 'cellpadding/cellspacing' attributes in table).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by kaszz on Tuesday June 27 2017, @02:41AM (2 children)
The problem is that people perceive the need for style and runnable code for aspects that will not improve the core purpose of mediate information.
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @08:55AM (1 child)
No, styling actually does improve your access to information. It is somewhat an information as well, as long as your idea of styling does not include gray on grey blinking text with bulbbing cursors and video in the background.
(Score: 1, Funny) by Anonymous Coward on Tuesday June 27 2017, @10:15AM
Phew, so I'm on the clear with my grey on gray blinking text, bubbling cursors and video in the foreground, above the important content. ;-)
(Score: 3, Interesting) by The Mighty Buzzard on Tuesday June 27 2017, @10:31AM (7 children)
Entire article is garbage because of the premise. Optimizing something that takes minimal processing time, minimal memory, and uses minimal bandwidth is always premature optimization. It should never be done until you've got a 100% complete and bug-free product.
My rights don't end where your fear begins.
(Score: 2) by romlok on Tuesday June 27 2017, @11:06AM (1 child)
Or, preferably, done by an automated tool during deployment, so developers can continue to work with code broken up into logical units optimized for people to interpret, rather than all mashed together and optimized for machines to interpret.
(Score: 2) by The Mighty Buzzard on Tuesday June 27 2017, @11:58AM
Interesting idea but writing the tool would also be a form of premature optimization, though using it wouldn't.
My rights don't end where your fear begins.
(Score: 3, Insightful) by tibman on Tuesday June 27 2017, @03:16PM
Organization is not premature optimization. There is also plenty of "optimizing" that you would want to do during development. Refactoring duplicate code into functions, for example. You wouldn't want to wait until your product is finished before you made it maintainable. It should continuously be made more maintainable. CSS that didn't actually cascade would also be something you'd want to optimize/refactor during development. Because if you waited until "you've got a 100% complete and bug-free product" then it would never be done.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by DutchUncle on Tuesday June 27 2017, @03:49PM
In 1894, The Times predicted that London would be buried in horse manure from all of the carriage and carting horses. That's about what the Internet looks like.
This is a burden on everything, like phantom power, wall warts, and all of the other small inefficiencies that weren't worth someone's time to fix. Multiply your wasted overhead by the thousands or millions of times that you're paying for the data transmission, not to mention the users' side, and it matters. I will agree with you that this should not be the first priority, but I'll bet just a little bit of cleanup would make a big difference. Note: I work in embedded systems, where bytes and milliseconds count, and just being neat IS enough to make the difference.
(Score: 2) by FatPhil on Tuesday June 27 2017, @07:30PM (1 child)
For aiding register colouring in non-SSA compilers, placing declarations just before, or as the first use of a variable is an optimisation. However, it's often a prefered or formalised coding style, so it's not an optimisation, it's just how you do things, it's the RAII paradigm. Or you don't - some coding standards specify the exact opposite.
Anyway, don't do it solely as an optimisation, do it because it is a style you prefer for maintainability. However, as another poster noted, not all things that are equal are the same, so merging all "8px" fonts together may be an illogical coupling of unrelated things. Consider what you are likely to want to change independently of other things. Font sizes in a header/footer block may be coincidentally the same size as side menus or body text, but having them share a CSS rule is an antipattern if you think that you might want to restyle the header or the footer or the menus at a later date. Pretent they're CSS vars, and ask yourself if they're the same var. THe answer is that there's a good chance they're not, and therefore you will not want to follow the article's advice as it will be *bad* for maintainance.
So, coming back full circle to where you came in, yes it looks like he's holding the unproven optimisation aspect as the ultimate end goal, and yes, he's therefore applying some wrongthink.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by The Mighty Buzzard on Wednesday June 28 2017, @02:17AM
Bingo. I just don't care to go into that much detail often.
My rights don't end where your fear begins.
(Score: 2) by Bot on Tuesday June 27 2017, @09:18PM
My objection is similar, css has repetitions, they get compressed by the network protocols right?
the parsing time of optimized css could well be longer than plain css. So, nothing to optimize on this side.
The only optimization and DRY is needed for the webmaster convenience, which is not anymore an activity for hobbyists that flocked to wordpress and facebook and templates.
So, the authoring platform and NOT css needs to be used. No need to mess with css. Keep stuff that can crash/compromise the user agent out of the protocols thx
Account abandoned.
(Score: 2) by wonkey_monkey on Tuesday June 27 2017, @03:27PM (5 children)
CSS is a great concept, but it desperately needs variables and proper nesting.
systemd is Roko's Basilisk
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @03:55PM
Also, templates. As everyone who develops in C++ knows, everything is better with templates. /rimshot
(Score: 2) by tibman on Tuesday June 27 2017, @04:31PM (2 children)
You can get variables with a css preprocessor like sass. It will compile into normal css. Definitely the way to go for a large project.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by wonkey_monkey on Tuesday June 27 2017, @04:47PM (1 child)
It's abominable that it requires a compiler to do that.
systemd is Roko's Basilisk
(Score: 2) by tibman on Tuesday June 27 2017, @04:57PM
The web world is weird. There are languages that compile down to javascript now.
SN won't survive on lurkers alone. Write comments.
(Score: 0) by Anonymous Coward on Wednesday June 28 2017, @07:49AM
Variables? We already have them: https://www.w3.org/TR/css-variables/ [w3.org]
(Score: 3, Informative) by meustrus on Tuesday June 27 2017, @06:25PM (3 children)
This is why serious frontend projects use a CSS preprocessor. With SASS / SCSS / LESS, you can create mixins that describe a concept, then bring that concept into many disparate parts of the web site. Like utility functions.
Mixins compile down to the exact DRY situation the author wants: one rule, many many selectors. But you almost never want to actually develop with your CSS in that state. You want to be able to edit the "user stats box" CSS by going to the "user stats box" stylesheet, not the "things with border style 3-B" stylesheet.
Preprocessors also help in cutting down selector repetition as well, due to nested selectors and some basic looping / recursion concepts. Variables also allow related things, such as design colors, to be specified in one place instead of being sprinkled everywhere. And finally, file references with a pre-processor make it possible to jam all your styles into whatever collection of resulting files you want to serve, separating development concerns from performance concerns.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Wednesday June 28 2017, @06:15AM (2 children)
The mere existence of these assistive tools means that CSS is far too complex. It must be the fruit of a committee. I prefer things along the lines of the Python manifesto - keep it simple and elegant.
(Score: 0) by Anonymous Coward on Wednesday June 28 2017, @07:52AM
It's the reverse. CSS is too simple. Which isn't that bad of a thing unless we want it to become full-fledged programming language.
(Score: 2) by meustrus on Wednesday June 28 2017, @08:26PM
The complexity of CSS is not the (current) problem. The problem is that CSS lacks basic tools to reduce redundancy, like variables and mixins.
Sure, C would technically be less complex without variables or function calls, but the resulting code would be significantly more complex and error-prone, not to mention awful to look at and deeply inefficient without some serious compile-time optimization.
It starts to sound a lot like the biggest problems with CSS, actually.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 0) by Anonymous Coward on Tuesday June 27 2017, @08:27PM
CSS has always been half-baked, underfeatured and misfeatured crap. Why do you think things always turn out so ugly when using it? At some point, you have to just admit it's shit. Too bad the Web is just an accretion of different shit layers that will never be replaced.