On the last day of TXJS, a developer asked me:
Doesn’t Object Oriented CSS leave you with a pile of presentation based class names?
Each layer in the web stack has its own architecture. You wouldn’t expect the DB schema to be used to architect the PHP middleware, and yet people expect that of the HTML and CSS. HTML needs to be written with a sense of the meaning of the data or content, something I call code semantics. Code semantics are incredibly important in the HTML for both portability and accessibility. On the other hand, CSS really is a separate layer in the stack, and it needs its own architecture that reflects the visual semantics of the page.
Visual semantics describe all the repeating patterns in the design of the page. They represent the fundamental building blocks of your website. In fact, they are often portable across sites with only minor modifications. Visual semantics shouldn’t necessarily be tied to HTML semantics, because you want an architecture that fits the unique requirements of each layer of the stack.
Separating Template Architecture From Styles
Similarly, many PHP developers are tempted to match the CSS and HTML architecture to the PHP. Perhaps it is common to try to apply the abstractions of the layer with which you are most comfortable to those that you find more challenging? I’ve certainly been guilty of it. During my time at Facebook, I expected the PHP layer to match the CSS layer. Luckily Facebook has some smart developers who pushed back and helped grow my understanding.
Shoehorning CSS and HTML into PHP abstractions prevents the code from being DRY and ultimately leads to code bloat, because, the CSS and HTML require a far more granular object structure than the PHP. In fact, PHP templates are not a very natural fit because each template includes many different HTML and CSS objects combined in different ways.
Visual Semantics != Presentation Based Classes
It is important to note that I’m not suggesting class names like “giantBlueHeading.†Class names need to represent the object structure you are defining, not the specific visual look and feel of this particular instance. For example, I often choose abstract class names that are easy to remember, like “mediaâ€. The media block combines of a fixed width image or flash with some text or other content that describes it.
The media block may be used in many different contexts, for example, to join an icon and a link or a profile picture and user name. The specific use case is separate from the object structure. The HTML can be looked at as instances of the CSS object.
The code for the media block, and many other base objects are available on the OOCSS open source project.
Comments
10 responses to “Visual Semantics in HTML and CSS”
Help me out if you can. Is there a name for a clean separation between the layers of the stack? Though not repeating myself was one of my goals with OOCSS, I didn’t realize it was called DRY. It can make it so much easier to talk about this stuff if you know the lingo. Thanks!
I wish you could elaborate on this with some concrete examples of anti-patterns — I’m not sure I understand what you mean by “Shoehorning CSS and HTML into PHP abstractions”.
As for a name for clean separation between the layers, I think there are a few analogous programming terms that could apply, depending on what you mean. Ironically, they’re all somewhat overlapping in meaning. These are all Wikipedia keywords:
* Encapsulation
* Modularity
* Loose coupling
* Separation of concerns (vs. Cross-cutting concerns)
* Law of Demeter (Principle of Least Knowledge)
* Multi-tier architecture
Please write on this subject more often! Even if it’s just a quick insight. I don’t think anyone’s really addressing the philosophy of semantic markup in the same way you are. Discussing these ideas has already brought about some tools to accomplish what you wished for in your previous post. (I’m really digging Sass’s implementation of “extend”!)
Great post!
I find that defining a logical structure for my documents to be one of the most challenging aspects of front end engineering. However once a great structure is discovered it is extremely reusable across sites which makes it well worth the effort!! I also agree on separation of the stack, which is a never-ending challenge in itself.
However, I think that visual semantics must absolutely be tied to the structural semantics. The challenge is that the architecture needs to stack one way or the other. Does the logical structure of the HTML document influence the structure of the CSS? Or is it that visual semantics in the CSS should influence the logical structure by including class name hooks, whether they be defined visually or in abstraction? The term “visual semantics” leads me to believe that the CSS has an influence in the logical structure of the HTML in which to define its own visual semantics in the element class names.
I tend to believe its better to have the HTML and its structurally defined class names influence the design in the CSS than the other way around. Mainly because a change to just the design will only affect the stylesheets, and not the HTML. One disadvantage to this approach is redundancy between the { } over the site as a whole. However, I believe the inverse problem to be that logically disjoint HTML structures may be tied together implicitly through the visual semantics in the stylesheet and class names, which may make redesigns and refactoring of the CSS difficult.
I appreciate the discussion, you always get me thinking twice about my strategies with CSS!
lol internetz
“Shoehorning CSS and HTML into PHP abstractions prevents the code from being DRY and ultimately leads to code bloat, because, the CSS and HTML require a far more granular object structure than the PHP”
Nicole, can you provide a concrete example of what you’re describing here? I feel like it’s on the verge of revealing a big insight, but I can’t quite grasp yet what you’re trying to get across.
Haha, ok, it seems pretty clear now that this all makes sense in my own head, but I need to give more context rather than starting right in the middle. 🙂
I need to give visual examples, so I’ll have to write another post.
Voila! A concrete example. 🙂
re: a name for it – separation of concerns?
[…] 原文网å€ï¼šhttp://www.stubbornella.org/content/2010/06/12/visual-semantics-in-html-and-css/ […]
The clean separation between layers would be:
– separation of concerns (the habit from the past to specify presentation violates separation of concerns), together with:
– modularity (keep CSS physically separated from HTML, form instance).
I agree that the word “Visual semantics” is a dangerous one, because most people will immediately think of presentation-based classes, so you have to state explicitl;y, as you do, that it does mean something else.
As I understand it, you state that in HTML, there are often some elements that belong together, like the elements in a table or a form. In HTML5, the figure element binds together elements that were uncoupled before, but often belong together.
In fact, you bind those elements together to form one “chunk” by treating them as one object in your CSS, in such a way that you can exploit those “chunks” in different places. Is that right?