SoylentNews is people
SoylentNews
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: 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.