
Coding Horror: What's Wrong With CSS - Anon84
http://www.codinghorror.com/blog/2010/04/whats-wrong-with-css.html
======
Xurinos
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?

~~~
klochner
<http://en.wikipedia.org/wiki/XSL_Transformations>

~~~
Xurinos
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.

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

~~~
sant0sk1
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?

~~~
evlapix
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/

~~~
aaronblohowiak
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 }

------
Legion
I am all about SASS. SASS feels like someone took CSS and decided to finish
it.

------
RyanMcGreal
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.).

------
rradu
CSS variables? Sign me up! (<http://lesscss.org>)

~~~
marcusbooster
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.

~~~
pstuart
Noted in the comments of the article is that less is moving to JavaScript.

<http://github.com/cloudhead/less.js>

~~~
juvenn
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.

~~~
jamie_ca
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).

~~~
sjs
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.

------
mcantelon
SASS isn't new, but good that Atwood is pointing people to it. Much nicer than
raw CSS.

------
treyp
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;
      }
    

can become

    
    
      .uno, .dos {
        color: green;
        font-size: 18px;
      }
      .uno {
        text-align: center;
      }
    

also, as others have pointed out, nesting is kind of there in the form of a
hierarchy. child elements will get parent styles for most properties.

~~~
chriseppstein
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;
      }

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

~~~
nex3
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.

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

------
klochner
I'm not taking sides yet, but . . .

"why CSS needs no variables" [http://meiert.com/en/blog/20090401/why-css-
needs-no-variable...](http://meiert.com/en/blog/20090401/why-css-needs-no-
variables/)

~~~
kj12345
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.

------
robin_reala
Mozilla recently added experimental support for -moz-any() which fixes (sort
of) Jeff’s third pain point:

<http://dbaron.org/log/20100424-any>

------
code_duck
I'm always out of the loop... I thought I was hip to be generating CSS with
some glanky PHP compiler that I wrote.

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

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

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

~~~
petercooper
It felt more like "Microsoft-land developer finally discovers technology most
HN users have known about for ages" to me ;-)

~~~
bruceboughton
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.

~~~
petercooper
You might be right. In contrast, Joel seems very clued up as to what's going
on outside of his niche.

