Coding Horror: What's Wrong With CSS(codinghorror.com)
codinghorror.com
Coding Horror: What's Wrong With CSS
http://www.codinghorror.com/blog/2010/04/whats-wrong-with-css.html
18 comments
Interestingly, Chris Eppstein, my co-developer on Sass, agrees with you that CSS needs abstraction. However, he concludes that Sass is a good language for expressing that abstraction: http://chriseppstein.github.com/blog/2009/09/20/why-styleshe...
Why the hell do you want the web to use stateful, synchronous, persistent connections?
Good luck implementing Xanadu.
Good luck implementing Xanadu.
XSLT is a parser for XML similar to how a browser is a parser for HTML (and, well, XML). I counter with SVG (see http://www.renater.fr/Video/2001ATHENS/DC-SVG/ALL.HTM for some fun stuff), which, even in an XML format, includes abstractions such as defs that will be handled by the SVG parser.
We can do better with/than HTML. We can do better with/than CSS.
We can do better with/than HTML. We can do better with/than CSS.
you shouldn't declare your sass variable 'blue'. If it becomes green in the future, you'd have a 'blue = green' assignment. Even 'color1' would be a better name.
The two things hard in computer science: cache invalidation and naming things.
I'd say the latter is the more difficult. Nice point.
I've had a hard time deciding on a naming convention for my sass variables, and have sometimes resorted to 'color1' and friends.
Anybody have a method they feel good about and would like to share?
Anybody have a method they feel good about and would like to share?
If you go to http://colorschemedesigner.com/ and hit "Random > Randomize Palette" you'll see that most colors in a theme/palette could be categorized like this:
!theme_primary !theme_secondary !theme_accent
!theme_primary_dim !theme_secondary_dim !theme_accent_dim
!theme_primary_bright !theme_secondary_bright !theme_accent_bright
s/theme/palette/
!theme_primary !theme_secondary !theme_accent
!theme_primary_dim !theme_secondary_dim !theme_accent_dim
!theme_primary_bright !theme_secondary_bright !theme_accent_bright
s/theme/palette/
and if you go to export as html/css you'll get something like this:
.primary-1 { background-color: #FFDDC2 }
.primary-2 { background-color: #E5C9B4 }
.primary-3 { background-color: #DAAA84 }
.primary-4 { background-color: #FFEBDB }
.primary-5 { background-color: #FFF6EE }
.secondary-a-1 { background-color: #FFE6C2 }
.secondary-a-2 { background-color: #E5D1B4 }
.secondary-a-3 { background-color: #DAB784 }
.secondary-a-4 { background-color: #FFF0DB }
.secondary-a-5 { background-color: #FFF8EE }
.secondary-b-1 { background-color: #FFCFC2 }
.secondary-b-2 { background-color: #E5BEB4 }
.secondary-b-3 { background-color: #DA9684 }
.secondary-b-4 { background-color: #FFE2DB }
.secondary-b-5 { background-color: #FFF2EE }
.complement-1 { background-color: #C2FFFD }
.complement-2 { background-color: #B4E5E3 }
.complement-3 { background-color: #84DAD7 }
.complement-4 { background-color: #DBFFFE }
.complement-5 { background-color: #EEFFFE }You could use names that make sense in the context of the overall design, e.g. theme_color, horizontal_padding, column_width.
Same as in normal programming, really.
Same as in normal programming, really.
Good advice and I do for non-color related variables.
I guess its hard for me to put names on 3-6 colors that are used in various places on the site. This is probably just because I don't have a good idea going in where I'll be using these colors and I end up using them in places that don't apply to the name given.
For instance, I'll name a variable "background_color" and then I'll want to use it somewhere unrelated.
I guess its hard for me to put names on 3-6 colors that are used in various places on the site. This is probably just because I don't have a good idea going in where I'll be using these colors and I end up using them in places that don't apply to the name given.
For instance, I'll name a variable "background_color" and then I'll want to use it somewhere unrelated.
Don't waste time on this. The easy answer is "choose your names semantically", but that's easier said than done. In the end, your users don't care if your variable is named "blue", "color1", or "color_used_to_represent_user_likes_something"
Semantic markup and CSS is something to strive for, but don't kill yourself trying to get to 100%
Semantic markup and CSS is something to strive for, but don't kill yourself trying to get to 100%
if you use it for something unrelated, then set the unrelated thing equal to background_color, but keep them semantically separate.
This is what I'm using for a website I'm building.
// >> HEADER/FOOTER
// background color for header/footer
!nav_background = #5C504F
// border of header/footer
!nav_border = #5C504F + #2B2830
// text in header/footer
!nav_text = #F0F8FE
// >> BACKGROUND BEHIND CONTENT
// background between content and nav elements
!site_background = #2B2830
// border between background and content
!site_border = #ABAB8E
// >> CONTENT
// background for content
!content_background = #F0F0D8
// table odd row
!content_lighter_background = #F0F0CA
// text color
!content_text = #000
// regular links in content
!content_links = #2B2830
// control links (flag, edit, delete, etc.)
!content_edit_links = #8B8870
// secondary nav border, section seperator, table header seperator
!content_seperator = #D9D7A3
You should declare your sass variable 'blue', because it's easier to work with than #3bbfce. if you want to change it to green, you would change it in the declaration from border-color = !blue to border-color = !green. (Or add an intermediate variable like !primary_color = !blue.)
If I go through replacing all of the !blue with !green in my files, I might as well replace #0000ff with #00ff00.
Your variable names represent a value, not a color. You should ask yourself what the function of that value is before naming the variable.
But that's just me. CSS is not something you can let slide. Adding templates, widgets, and pages on a mass scale (20+ templates, 30+ widgets, 500+ pages), your CSS deficiencies will show quickly.
Your variable names represent a value, not a color. You should ask yourself what the function of that value is before naming the variable.
But that's just me. CSS is not something you can let slide. Adding templates, widgets, and pages on a mass scale (20+ templates, 30+ widgets, 500+ pages), your CSS deficiencies will show quickly.
I should've said "You should add an intermediate variable" instead of "Or add an intermediate variable". If you were to name a variable !blue, it should be treated like a global variable, and only used in matters of say, the color palette of a site, and not the particular color used in sidebar.
Agreed. I do the exact same thing. First define a palette and with variable names that describe the color (eg, !mauve= #E0B0FF), then assign those to descriptive variable names (eg, !accent_color= !mauve). That way it's immediately clear which colors are being used while also avoiding the need to replace variable names throughout the partials.
Can the same not be accomplished with a comment?
Sure, if you want to leave the same comment in every place you assign a particular hex value to one of the descriptive variables and don't mind changing each of those duplicated hex values if you ever need to tweak the color. Personally, I don't see the benefit of using comments when using variables is already self-documenting and further avoids possible duplication of hex values.
I think you misunderstood me, which is understandable.. I was unclear. The comment question wasn't meant to be combative. I agree and can see the benefit/use.
Thanks for being patient with me while I explore alternative solutions.
Thanks for being patient with me while I explore alternative solutions.
I think mtoledo's point is that variable names should have context, and not be mere appropriations of their content. For example, "theme_color" would be better than "blue" because you could use it in context among lots of different CSS definitions, and if your theme color changes, it's a single change, as opposed to changing all the "blue"s to "green"s or whatever.
I understood that part, that's why I gave the example of !primary_color. The point I'm making is that naming a variable after a color isn't necessarily a bad thing and can be a useful abstraction, and there's no reason you can't do both. I can recognize some common color hex codes, but I find it easier to work with more human readable names. If I'm looking at a site and I want to make the orange color slightly darker, will I remember that it's !color3? Or is it easier to look through for !light_orange?
I follow you isleyaardvark. I think one of the challenges of having a discussion about CSS is scope/setting. CSS is used on every different type project. If you're doing client work and building 5 page mini site (I'm not suggesting anything), your thoughts on CSS are based on a completely different use than the developer that maintains 500+ pages.
We both know CSS. But we use them entirely differently.
On a site with 500+ pages, by the time you've implemented all of your !blue to !green, or !light_orange to !dark_orange throughout your stylesheets, management will be considering another redesign.
We both know CSS. But we use them entirely differently.
On a site with 500+ pages, by the time you've implemented all of your !blue to !green, or !light_orange to !dark_orange throughout your stylesheets, management will be considering another redesign.
For me, it's easier to inspect the element in Firebug and copy/search the hex code, since I get the guarantee that I'm not changing an unrelated poorly named variable.
I find that for simpler sites, naming colors after their closest tone works well, but when I have a dozen shades of the same color, I start to run out of names very quickly (e.g. it's not unusual for me for a single page to have different background boxes, zebra striped tables, subheaders, selected/hover states and an array of other details on top of the overall layout)
I find that for simpler sites, naming colors after their closest tone works well, but when I have a dozen shades of the same color, I start to run out of names very quickly (e.g. it's not unusual for me for a single page to have different background boxes, zebra striped tables, subheaders, selected/hover states and an array of other details on top of the overall layout)
That's why I think names like "color3" are bad. If the orange is on headings, look for headings. If the orange is the page background, look for what represents that. I don't see a compelling reason to actually use the color name in the variable name since things should be easier to look up if the context is taken into account.
I am all about SASS. SASS feels like someone took CSS and decided to finish it.
It makes sense for CSS to remain a static language and for the dynamic logic to stay in preprocessors like Sass and LessCSS, for the same reason that HTML itself is a static language for which the dynamic logic goes into preprocessors (PHP, Ruby, Python, etc.).
CSS variables? Sign me up! (http://lesscss.org)
I haven't looked at this package, but it seems running the CSS through a preprocessor like m4 would achieve similar results - for those not into Ruby.
Why do you need to be "into Ruby" to run a tool written in Ruby? LESS and Sass are both fully usable from the command line.
Noted in the comments of the article is that less is moving to JavaScript.
http://github.com/cloudhead/less.js
http://github.com/cloudhead/less.js
That new node-based v2.0+ implementation can be 10x faster than the ruby-based implementation.
# Ruby version
$ time lessc -v
lessc 1.2.21
real 0m1.681s
user 0m1.492s
sys 0m0.176s
# Node.js version
$ time lss -v
lessc 2.0.0 (LESS Compiler)
real 0m0.104s
user 0m0.088s
sys 0m0.016s
I'm disappointed with this change - it seems like picking up the new shiny tech for the sake of new shiny tech, at the expense of usability. My mac came with ruby, but not node.
Also, a 1.5-second speedup is not terribly compelling for something done rather infrequently (and if you're not caching or pre-processing to static files, you're doing it wrong).
Also, a 1.5-second speedup is not terribly compelling for something done rather infrequently (and if you're not caching or pre-processing to static files, you're doing it wrong).
One reason to move to JavaScript is so that you can process LESS on the server and client. This way you can serve up a static LESS file and let the user's browser parse it, cutting out the extra compilation step. But you can still compile it beforehand and serve up the CSS directly if you don't want or cannot afford the performance hit on the client.
At the very least I could see myself using it in the browser for development.
At the very least I could see myself using it in the browser for development.
installing node on your mac takes all of 5 minutes if you already have ports installed. speed in development turnaround is important to me.
SASS isn't new, but good that Atwood is pointing people to it. Much nicer than raw CSS.
you don't necessarily have to duplicate code blocks all the time since you can declare a definition for multiple styles:
.uno {
color: green;
font-size: 18px;
text-align: center;
}
.dos {
color: green;
font-size: 18px;
}
.uno, .dos {
color: green;
font-size: 18px;
}
.uno {
text-align: center;
}
Sass provides inheritance to accomplish this same result but without spreading your selectors all over the place.
.uno {
@extend .dos;
text-align: center;
}
.dos {
color: green;
font-size: 18px;
}Following @joehewitt recent thoughts on browser innovation, I think it would be cool if browsers added client-side support for processing lesscss (or sass) files. They could send an extra header (accept-encoding:less), and web servers could serve up main.css.less vs main.css.
I disagree. One of the main benefits of CSS compilers like Sass and Less is that they can innovate at their own pace, without worrying about any browser compatibility headaches.
That's one reason why lesscss is being ported to JavaScript.
http://github.com/cloudhead/less.js
http://github.com/cloudhead/less.js
I'm in a similar situation, I've got a decent pool of apps running on the same framework that only differ in config and static files. The approach I took is using the ruby gem compass and sass. I moved any sass variables into a skin.sass file and that way each site can just implement its own skin file very easily with only editing a single file and not having to jump into the main css. This has made it relatively painless to create another skin for a new site.
One issue I'm dealing with on this setup is that these skin files are site dependent and outside of the base code repo. They're in their own repo, but the issue is every site has its own files, so to add a new variable to the skin file requires adding it in 5-10 places, and that number is just going to get bigger. I'm curious if you guys have any suggestions.
One issue I'm dealing with on this setup is that these skin files are site dependent and outside of the base code repo. They're in their own repo, but the issue is every site has its own files, so to add a new variable to the skin file requires adding it in 5-10 places, and that number is just going to get bigger. I'm curious if you guys have any suggestions.
I'm not taking sides yet, but . . .
"why CSS needs no variables" http://meiert.com/en/blog/20090401/why-css-needs-no-variable...
"why CSS needs no variables" http://meiert.com/en/blog/20090401/why-css-needs-no-variable...
Its a good point about comma-delimited selectors reducing repetition, but constants offer other advantages, just as they do in any language.
One example is the ability to distinguish in code between !warningColor and !saleColor even if they happen to be the same value of red at a given point in time.
Another is increased readability, since scanning a stylesheet and quickly seeing that #f54e4f and #f5e4f4 are very different colors is difficult.
Additionally in Jeff's case constants would allow for one complex stylesheet which maps selectors to constants to be shared across all skins, and then each of the 10 skins can be simply definitions of constants.
One example is the ability to distinguish in code between !warningColor and !saleColor even if they happen to be the same value of red at a given point in time.
Another is increased readability, since scanning a stylesheet and quickly seeing that #f54e4f and #f5e4f4 are very different colors is difficult.
Additionally in Jeff's case constants would allow for one complex stylesheet which maps selectors to constants to be shared across all skins, and then each of the 10 skins can be simply definitions of constants.
There is not only no reason a preprocessor like SASS can't someday efficiently process selectors like he describes, but theoretically it would be easier with something like SASS. In SASS you could keep the color declaration alongside the other CSS declarations, then the preprocessor could simply find all the declarations with that variable and string them together with commas.
Unfortunately the SASS preprocessor doesn't do that... yet. The main draw of SASS is the ease of development and maintainability, not reducing the byte size of your CSS files. Personally, I don't want to spend the time manually hunting through CSS to combine selectors in order to save a few bytes.
To give you a more practical example, instead of a color like #efac68, imagine the variable held the value 1em or 10px. If you wanted to increase the width of the gutters between columns, it's easier to change $gutter than to try a find and replace of 10px in your CSS, while trying to only change the values you want.
Unfortunately the SASS preprocessor doesn't do that... yet. The main draw of SASS is the ease of development and maintainability, not reducing the byte size of your CSS files. Personally, I don't want to spend the time manually hunting through CSS to combine selectors in order to save a few bytes.
To give you a more practical example, instead of a color like #efac68, imagine the variable held the value 1em or 10px. If you wanted to increase the width of the gutters between columns, it's easier to change $gutter than to try a find and replace of 10px in your CSS, while trying to only change the values you want.
I can't believe it; a screed against CSS constants, published on April 1st, and it claims not to be a joke.
Yeah, but if you can have a variable hold more than declarations than just a color value, then that's a lot of space saved.
Maybe I'm missing something here...
The big problem with CSS without variables is the time and effort it takes to make changes. If you only have to change the declarations once, at the top of the file, well it doesn't get much easier.
The big problem with CSS without variables is the time and effort it takes to make changes. If you only have to change the declarations once, at the top of the file, well it doesn't get much easier.
[deleted]
Mozilla recently added experimental support for -moz-any() which fixes (sort of) Jeff’s third pain point:
http://dbaron.org/log/20100424-any
http://dbaron.org/log/20100424-any
I'm always out of the loop... I thought I was hip to be generating CSS with some glanky PHP compiler that I wrote.
[deleted](1)
[deleted]
Does anyone else think we would invent a whole new layout/typography system independent of HTML and CSS? I mean, HTML, .doc, .pdf , epub, etc. are all repeating themselves. The fact is the whole rich-text presentation stack need to be freshed and better designed for new HCI and new devices.
When working on a web project where I have no designer I inevitably get sucked into hours of painfully tweaking CSS. The biggest pain points is that CSS is not programatic and feels very restrictive(it's a declarative non-turing-complete language); Nor is it concise.
[deleted]
While Jeff's issues with CSS are valid ones, the post feels like a lot of his, "here is a little bit about a few things both nothing really deep or helpful, click my ads now?".
I guess it's a bit like his business partner Joel quitting blogging, hasn't got a great deal left to say.
I guess it's a bit like his business partner Joel quitting blogging, hasn't got a great deal left to say.
Part of being a high-output blogger is cranking something out even if it's not a revolutionary idea. I appreciated the post and I know where to go if I need deeper insights on LessCSS or SASS.
Sometimes connecting the dots is all a blog post needs to do.
Sometimes connecting the dots is all a blog post needs to do.
It felt more like "Microsoft-land developer finally discovers technology most HN users have known about for ages" to me ;-)
This is just Jeff's style. I'm not sure the fact he is a .NET developer is relevant. He likes to pump out vacuous link-baity articles. I don't particularly blame him though.
You might be right. In contrast, Joel seems very clued up as to what's going on outside of his niche.
I personally like the ideas behind languages the Lisp community is developing via Weblocks and UCW (on top of yaclml or cl-who) -- and the similar possibilities provided by perl's Catalyst::View::TD -- where you approach page design from the perspective of widgets combined on a page.
Here is what is forced on us with this flat data approach: The server bears the weight of producing the flat data, and the network has the burden of carrying that large flat data from the server to the client. The client must render all that flat data. If the data had means of abstraction, the server would not need as many intermediate layers to convert it, the network would have less to transfer, and the client browser would be able to take advantage of optimizations for abstractions and parse less data.
Has anyone made any real headway on getting a replacement for HTML browsing? a movement away from "pages" and more towards "gateways" or "portals" to the graphical net?