Thursday, December 17, 2009

CSS class inheritance: the way I would expect it to work

Disclaimer: I am a CSS newbie. So don't take this blogpost as an expert opinion. On the other hand, that gives me the unique point of view of someone with no predispositions on how things should work.

The problem

In my opinion, the purporse of CSS is to free the programmer from layout issues whilst keeping the freedom of layout with the designer. The way this works is as follows:

The programmer writes code that outputs HTML, eg:
<div class="foo">
<p class="bar">
Hello, world. This is a very short paragraph!
</p>
</div>
The designer then can make sure this looks nice without having to touch the html, like:
.foo {
  background-color: white;
  color: black;
}

.bar {
  background-color: inherit;
  color: inherit;
  font-weight: normal;
}


What bothers me with that?

Well, I think the programmer should not be aware of the CSS class structure that the designer will use or is using. Imagine a programmer making a main menu:


<div class="my-main-menu">
<ul>
<li>butter</li>
<li>cheese</li>
<li>eggs</li>
</ul>
</div>


The designer might like to use a CSS structure like:

.menu {
  background-color: white;
  color: black;
}

.horizontal-menu {
  float: left;
}
Suppose the designer wants to lay out the main menu as a horizontal menu. This requires him to write the following CSS code:
.my-main-menu {
  background-color: white;
  color: black;
  float: left;
  font-size: larger;
}
What I would like him to write is something like:
.my-main-menu {
  inherit: .horizontal-menu;
  font-size: larger;
}

What he needs to do with the way CSS is currently working:

1) he needs to write the custom site code:
.custom-menu-extension {
  font-size: larger;
}
2) he needs to tell the programmer what classes to use:
<div class="menu horizontal-menu custom-menu-extension">
<ul>
<li>butter</li>
<li>cheese</li>
<li>eggs</li>
</ul>
</div>


This approach violates the very idea of separating code and design. There is a tradeoff between either giving up your "modular" css structure or giving up separation between code and layout.

The solution

As you see above, I would add an "inherit" property to a class. This would include the definition of the inherited class to the newly defined class. In this way, programmers would only need to assign 1 class to each piece of content (instead of the clutter of divs / class names we see in current HTML). Designers could then declare that class using their favorite CSS framework as a basis and expand it with the specific properties for the given content and website.

Of course I could be missing the point, since my CSS experience is very limited. I'dd like to get more suggestions in the comments.

3 comments:

  1. A designer should design (read: Stick to Photoshop, Illustrator, Fireworks, ...). If the designer is going to write code, he should be handling both HTML and CSS. Neither of these I would call 'programming'. Programming is creating logic, not describing the looks of something.
    Naming conventions and stacking of your CSS-classes would be the designer's problem.

    ReplyDelete
  2. You are getting 2 thing mixed up here.

    Inheritance in CSS, the way you want it It does not exist, get over it :) If you want that type of flexibility have a look at SASS a CSS generating language.

    Classes in CSS. In your last HTML example put my-main-menu as class and it will look the way you want. As a dev you'll be happy, you don't need to care about the designer. The designer however will not be so happy as he can't use a more modular approach, but it will work. In an extreme example you could give each DOM element an id and tell the designer to style each of these.

    Anyways, HTML is part of the design, and not pure "data". For pure data we use XML (you can apply css to that 2 you know).

    Can't wait to see how you'll fix browser incompatibilities ;)

    ReplyDelete
  3. @meon @Bert

    I guess the key is in your comment:

    "If the designer is going to write code, he should be handling both HTML and CSS"

    "HTML is part of the design, and not pure data"

    That's true and it is probably the reason why we can't have a clear separation between logic and design.
    I guess the boundary between the two is where "interaction design" comes in: the HTML not only defines the data, but also how you interact with the data (e.g. button vs. link).

    It is indeed wrong to assume
    html = data
    css = design

    the correct representation is more like
    html = data + interaction
    css = design + interaction

    Thanks for your comments, i've learned from it!

    ReplyDelete