
Separation, Abstraction, and Cascading in CSS - oskarth
http://www.lispcast.com/cascading-separation-abstraction
======
shubhamjain
"Similarly, why do styles defined in the HTML (in a style tag) take precedence
over those that are linked to externally? It has always made more sense to me
that it should be the exact opposite. An HTML page could define default styles
for its elements, which would be carried in the page, and overriden with an
external stylesheet."

Well that statement is just peculiar. Most people define the style of elements
in CSS stylesheets. However, in certain cases, like positioning a single image
where is does not make much sense to create a new CSS style, it can be defined
in inline, overriding default properties. At least for me, it is always the
other way round.

~~~
joe_hoyle
Hmm, I would tink the opposite naturally. Any style rules that is "closer" to
the element I would expect to take greater precedence, because you are
applying it more "directly".

------
crazygringo
This article makes an interesting point about using mixins instead of multiple
classes in the HTML, e.g.:

    
    
        <div class="foo">
        div.foo { .red(); .big(); .narrow(); }
    

instead of:

    
    
        <div class="foo red big narrow">
    

It feels so much nicer to use. Unfortunately, if you use it in a general way,
your compiled CSS will balloon _hugely_ \-- in fact, you're kind of defeating
the whole point. Obviously gzip can help somewhat, but it still doesn't seem
like the right way to go for any site of scale. (Plus the browser needs to
keep track of so many more rules.) So for the foreseeable future, HTML+CSS is
going to include a weird mix of classes for some things and mix-ins for
others. Separating presentation from content was always a goal, but has never
been remotely close to a reality.

Regarding the references 37 signals post [1], I definitely sympathize. But the
problem there is that they've essentially gotten rid of the whole concept of
"styles" that can be used in different places, because everything is mapped
exactly to the tree. Except for page size, they might as well just be
including all the CSS inline! Plus, they're forcing themselves to use mixins
to create actual "styles" that can be reused.

I've found that CSS cascading generally isn't a problem at all if you stick to
a few sane and well-chosen development rules with a well-planned architecture,
and someone is in charge of being a dictator in enforcing them. Of course, in
most places, that's too much to ask for...

[1] [http://37signals.com/svn/posts/3003-css-taking-control-of-
th...](http://37signals.com/svn/posts/3003-css-taking-control-of-the-cascade)

~~~
charliepark
_your compiled CSS will balloon hugely -- in fact, you're kind of defeating
the whole point_

Obviously, it depends on the use-case, but I doubt it would balloon too much.
The styles themselves aren't expanding at all — all that would be happening in
your example would be that you'd have

    
    
        .red, .foo {color:red}
        .big, .foo {font-size: 2em}
        .narrow, .foo {letter-spacing: -1px}
        .foo{border-radius: 10px}
    

(or whatever). So you'd be adding a bunch of ", .foo"s in the CSS. And, yes,
most class names will be longer than that, but I don't know that for most web
applications you'd be adding too much bloat. Even an inefficient CSS file is
going to add minimal overhead when compared to an additional image file or
javascript library.

As to "you're kind of defeating the whole point" ... well ... what _is_ the
point? If your point is optimizing to get the absolute fastest download
speeds, then it very well might be a bad direction to go in. But in terms of
developer efficiency, using @extends and mixins can make the process radically
easier. I'm working on an approach to CSS architecture that's similar to the
original article linked (lots of @extends), and the benefits have far, far
outweighed the costs. I'm still experimenting with it, and it's not ideal for
every use-case, but I've been working with CSS for over 10 years, and it's the
best approach I've found.

Definitely agree with you on the critique of the 37signals approach. It seems
like a very fragile method.

------
ezyang
I don’t think cascading is necessarily a problem; rather, HTML/CSS lacks good
encapsulation features. Actually, this has been well-recognized by browser
vendors, who want to use HTML and CSS to implement things like HTML5 video
player UIs, but don’t want the styles of the page itself to interfere with the
video player. They’ve implemented a rather intricate system called the "shadow
DOM" to manage this. (This page explains it decently well:
<http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/>)

We'd like CSS to grow up, and decide it wants to be a proper programming
languages, with all the abstraction and encapsulation facilities we'd come to
expect. Until then, I guess there is this language called JavaScript...

~~~
masklinn
> We'd like CSS to grow up, and decide it wants to be a proper programming
> languages, with all the abstraction and encapsulation facilities we'd come
> to expect.

I'm not sure that's really needed. Having semi-independent DOM trees with CSS
not leaking across from one tree to its sub-trees would be sufficient (that's
roughly what "Web Components" aim to achieve, from what I understand)

------
saraid216
Not really responding to the OP, per se, but had some thoughts motivated so
I'll just jot them down:

The issue isn't that there's a problem of content versus styling; it's that
there's no strict definition for _structure_. Instead, structure is conflated
with content in HTML. You can't style something generically unless you have a
content-agnostic structure to style. You can see this working in templating
languages: we define views and have a bunch of sockets into which the content
goes, and the styling just rides on top.

I could see content that looks like this: <text for="login_link">Log in</text>

And then something structural like this: <span id="login_link" />

Obviously, this is already possible using ERB or Handlebars or whatever, but
if we're ignoring server-side processing the way the OP is (and JS's ability
to manipulate DOM, for that matter), then I think this has a little merit.

------
Thrall
It irks me to find a paragraph break in the middle of a sentence in a document
which is, broadly speaking, about doing html et al. correctly.

One inconsistency that I have noticed blighting pages all over the web is
defining a dark text colour and just assuming the background will be white.
Try to view this using a 'dark theme' and often the undefined background
colour will be dark but the original css will be respected for the text
colour, meaning dark text on a dark background.

Try to force a light text colour in the user/theme css and you mess up all the
pages that did it right in the first place (i.e. specify text and background
colour to have suitable contrast, or leave it all up to the browser/whatever
to render nicely)

I wonder if this is something that could be adressed by the tools in the
article.

------
CGamesPlay
It took me a long time to understand this article because I don't think the
definition of "cascade" is what we typically use. When I say "cascade", I
think of inherited properties and the CSS values falling through the DOM nodes
(properties like font-family). The author, however, is simply referring to
multiple CSS declarations that match a single DOM node.

    
    
      div {
        margin-left: 10px;
        margin-right: 10px;
      }
    
      .my-widget {
        margin-left: 0;
      }
    

The author refers to margin-right "cascading" into my-widget. I don't think
that's what "cascade" means, but it certainly made CSS harder to work with
before tools like Firebug showed you exactly where each property comes from.

------
Kiro
"No bare selectors may occur in the LESS rules."

I don't like this. It would require me to come up with a name for every single
element I would like to style.

~~~
CGamesPlay
I think the author's intention was that nested LESS rules aren't considered
"bare", so this is OK:

    
    
      .my-widget {
        a {
          text-decoration: underline;
        }
      }

------
geargrinder
The cascade is very useful. In real-world situations, where I usually don't
have the luxury of building a new website from scratch, the cascade has
allowed me to implement changes and improvements the original creators never
imagined. Maybe I have been in a hole and missed it, but this is the first
complaint I have seen about the cascade.

------
flog
That font size was uncomfortably large.

~~~
demetrius
It seems the font size depends on the window width.

~~~
Zr40
It's that size when the width is at least 1000 pixels.

------
mcartyem
Can someone explain why they use CSS and HTML?

Why are two presentation frameworks used with a language called Javascript
bolted on top, rather than a powerful programming language?

~~~
clyfe
Because one would end up implementing HTML and CSS in that "powerful
programming language".

Funny, have a friend that does desktop dev because he "hates web dev", built
his own UI building framework on top of Swing :

    
    
        menu.addChild(item)
        ...
    

Now he's building an XML dtd to automate it...

~~~
mcartyem
You seem to be saying that the reason to use HTML+CSS+Javascript is that
without them one would need to use HTML+CSS+Javascript. That you use it
because you need it. Well, are you sure you need all three?

An alternative would be to use a more powerful language that would let you
express the kinds of things you often need with CSS as macros and have no CSS
at all.

~~~
angersock
More like, without them you will likely reinvent (badly) some subset of
HTML+CSS+JavaScript.

The problem is that you want to organize the content of the document
(HTML+DOM) with annotations and whatnot, and then style it to look pretty or
position it just-so (CSS), and then finally maybe add some goofy runtime logic
or updating (Javascript).

We've got tools that have evolved already to solve these three problems, so
why not use them? One of the happiest days in my life was getting to do UI
development on the web instead of an AWT/SWT/Swing behemoth (CAD software in
Java) or really clean but subgreat visualization/menu framework (C with
OpenGL, C++ with rendering interface, various other toolkits over time).

~~~
mcartyem
_why not use them?_

Because they are not powerful enough.

------
mddw
This article seeks solutions to non-existent problems.

~~~
larrybotha
The article addresses some valid issues, but tackles some of them in a manner
which is likely to affect maintenance in a different, and not always positive,
way.

The article illustrates LESS and Sass in a sort of magic bullet fashion, but
the reality is that such pre-processors are likely to cause many side effects
and unwanted behaviour when coming back to maintain a site when used in the
fashion suggested.

The author complains about the cascade and such issues, instead of embracing
those same features and utilising them to their power.

I've written an article covering methods for writing scalable CSS utilising
the cascade, preprocessors, and practices I have found invaluable in assisting
with scalable sites / apps:

[http://themousepotatowebsite.co.za/simple-methods-for-
writin...](http://themousepotatowebsite.co.za/simple-methods-for-writing-
scalable-css-right-now/)

------
tmcw
Bolting-on preprocessors that add features to a language without changing its
actual model fixes the problem forever, maybe.

