What is wrong with CSS is the same thing that is wrong with HTML and XML. We are trying to use these things as DSLs, but they lack a core aspect of a language: means of abstraction. As a result, modern website work generally involves using somebody's favorite layer on top of this web data that provides that missing aspect. Jeff's favorite ruby gem is one approach.
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?
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.
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.
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:
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.
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%
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.
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.
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.
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.
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)
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.
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.).
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
Though it should be noted that Rubygems has introduced a bit overhead in
the Ruby version.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?