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: 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.