Separation, Abstraction, and Cascading in CSS | Hacker News Reader

Separation, Abstraction, and Cascading in CSS

lispcast.com

43 pointsoskarth31 comments

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

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

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

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.

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

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

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.

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.

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.

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

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

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.

That font size was uncomfortably large.

It seems the font size depends on the window width.

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

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?

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

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.

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

why not use them?

Because they are not powerful enough.

> An alternative would be to use a more powerful language

...can you show us an alternative?

http://subjectivelisp.org

This seems to imply that you think everyone should stop using the web browser.

I don't think everyone should stop using the web browser.

It's fascinating anyone starts using smartphones.

Because a declarative syntax makes sense for documents but not for writing logic.

A powerful programming language here could be assembly or Lisp--that hardly makes it a good tool to use to do the things we expect for making user interfaces.

Simple declarative DSLs (such as CSS) are head-and-shoulders above a general-purpose programming language, especially in a situation where logic is not really needed or required. CSS, fugly though it can be, very neatly and thoroughly solves the issue of "How do I style this content?" without adding the complexity of a programming language.

Not all things want to be programmable and flexible.

You'll be surprised how often logic is needed.

Can you automatically compute pixels or colors with CSS based on values of other elements in CSS? Or combined with values coming from a user's preferences?

Seemingly trivial logic can reduce presentation complexity enormously. With a powerful programming language you have a better grip over the complexity than you do with CSS.

This article seeks solutions to non-existent problems.

Really? How do you manage the long-term maintainability of the CSS on a complex website?

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

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

Reply on news.ycombinator.com