Cargo Cult CSS
kapowaz.net
Cargo Cult CSS
1–10 of 44 posts
Re: Cargo Cult CSS
#2Good read. It has me asking quite a few questions of what I consider to be best practice.
Re: Cargo Cult CSS
#3Please stop it with the massive fonts on web pages
Re: Cargo Cult CSS
#4Please stop it with the massive fonts on web pages
Please familiarise yourself with the command/control + minus shortcut.
Re: Cargo Cult CSS
#5> The web is fundamentally a semantic medium.
I think this premise is outdated. The web is more and more hosting apps rather than documents.
Re: Cargo Cult CSS
#6I had mixed feeling until I saw “USE IDS, FOR THE LOVE OF GOD”, then I stopped worrying and stopped reading.
Re: Cargo Cult CSS
#7> The web is fundamentally a semantic medium. I think this premise is outdated. The web is more and more hosting apps rather than documents .
Not sure what that has to do with semantics. Are you saying that NAV etc. aren't valid semantics on applications?
Re: Cargo Cult CSS
#8> if you’re writing CSS professionally then there’s really no good excuse for not using a CSS preprocessor.
CSS preprocessors aren't without their own problems as well. An app that I'm currently working on has a history of semantic HTML, but having no room for compromise had resulted in a CSS file that is 4000 lines long.
There were lots of cases where an innocent looking @extend created monster selectors (https://twitter.com/mezzoblue/status/390274599167877120/phot...). This is non-obvious behaviour that should be avoided.
Re: Cargo Cult CSS
#9> The web is fundamentally a semantic medium. I think this premise is outdated. The web is more and more hosting apps rather than documents .
Not sure what that has to do with semantics. Are you saying that NAV etc. aren't valid semantics on applications?
> Are you saying that NAV etc. aren't valid semantics on applications?
What I mean is that the (supposed) benefits of semantic use of CSS classes go out of the window when you're no longer hosting documents to be read by machines. And the user does not care if the classes of HTML elements are semantic or not.
Re: Cargo Cult CSS
#10> if you’re writing CSS professionally then there’s really no good excuse for not using a CSS preprocessor. CSS preprocessors aren't without their own problems as well. An app that I'm currently working on has a history of semantic HTML, but having no room for compromise had resulted in a CSS file that is 4000 lines long. There were lots of cases where an innocent looking @extend created monster selectors ( https://t…
> This is non-obvious behaviour that should be avoided.
Generating selectors automatically obviously carries the risk of creating something excessively large that you don't want. But I want to challenge the widely-held view that a long CSS file is necessarily bad. First of all, what does 4,000 lines mean in terms of actual document weight? And what is the weight of the gzipped file actually served? Repetition in selectors might look bad on the surface, but this is exactly the kind of thing that compresses well. Once actually served this file then ought to be cached well, and so the issue of document weight is potentially moot.
Obviously there are extremes beyond which it may no longer be sensible to serve something like this, but arguably at that point you ought to be noticing issues in your un-preprocessed source anyway.