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

I need to give visual examples, so I’ll have to write another post.

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.

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!

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