Separating Structure and presentation

[oddz]

This is a question that I thought would be interesting to discuss that was motivated by the off topic discussion in this thread.

If your applying class/id attributes on the basis of whether or not you need to style a specific element aren't you condoning the mixture of structure and presentation? Thinking of the mark-up as a separate entity shouldn't it be written putting aside any need for presentation?

Doesn't the idea of applying attributes without considering how they may be presented support the notion of loose coupling between presentation and structure?

[AutisticCuckoo]

If your applying class/id attributes on the basis of whether or not you need to style a specific element aren't you condoning the mixture of structure and presentation?

I guess it depends on what IDs or class names you choose. If they are semantic, then no. If they're presentational, then yes.

If you're introducing guests at a party, saying, 'This is Jane, she's a carpenter, and this is Bill who's a nurse,' you are merely giving some additional context. You're not expecting the people to whom they're introduced to be in any particular, immediate need of a carpenter or a nurse. If they are, at some leater time, though, they've got a couple of names...

[AlexDawson]

I never put classes and ID's into the realm of presentation. You should not name a class for example as "red". You would give it the more appropriate convention "header", this is giving semantic value which explains the structure of the document so that specific style can be applied to it. A perfect example of this would be the use of Microformats to give explicit naming conventions to give semantic structure to the attributes.

[oddz]

I never put classes and ID's into the realm of presentation. You should not name a class for example as "red".

I think your misunderstanding the question. The question is whether or not defining class and id names on the basis of needing to style(target) a element could be considered a mixture of presentation and structure.

I guess it depends on what IDs or class names you choose. If they are semantic, then no. If they're presentational, then yes.

Semantic meaning they have nothing to do presentation and everything to do with describing the actual content/purpose of the element/data?

[AlexDawson]

Well you could apply that to HTML and say that providing additional mark-up such as empty DIV's (for example to clear floats) would make the extraneous mark-up presentational rather than structural. I think personally it falls somewhere between presentation and structure as even though the tags technically would not exist there without the presentational need, it does hold some structural value (even if the structural value is of questionable intent).

[oddz]

I think personally it falls somewhere between presentation and structure as even though the tags technically would not exist there without the presentational need

That isn't true because HTML is data description not presentation.

[Stomme poes]

I think personally it falls somewhere between presentation and structure as even though the tags technically would not exist there without the presentational need...

Exactly. If I never styled a page, not only would not not have a div id="header", I likely wouldn't even have the div at all, because he gets the name "header" mostly so I can style everyone who is special because they are sitting in the div called "header". If I didn't need a styling hook, it would not get a name at all, most of the time.

From the other thread, I agree with Paul more.

Here's the rule of thumb (and it's just that, a rule of thumb):
If every child of some box is getting the same class, then you don't need any of the classes.

You know how George Foreman named all his kids George? The point of giving your different kids different names is to differentiate them.

Instead of this:

<ul id="products">
<li class="product">blah</li>
<li class="product">blah</li>
<li class="product">blah</li>
<li class="product">blah</li>
<li class="product">blah</li>
<li class="product">blah</li>
</ul>

You only need this:

<ul id="products">
<li>blah</li>
<li>blah</li>
<li>blah</li>
<li>blah</li>
<li>blah</li>
<li>blah</li>
</ul>

And if there are no other uls on the page or on the site, you don't even need the id either. What are those classes doing? Naming every kid George. Which has no use when you can just say "George Foreman's kids" and mean exactly the same thing.

Use classes for the ones who are different. And when you have like half who are different and half who are normal, you don't need two classes. Let half get normal element styles, while only the other half get the class:

instead of:

(in a table)
<tr class="even">
blah...
</tr>
<tr class="odd">
blah...
</tr>
<tr class="even">
blah...
</tr>
<tr class="odd">
blah...
</tr>
<tr class="even">
blah...
</tr>
<tr class="odd">
blah...
</tr>
.../table

there's no reason not to do this:

<tr>
blah...
</tr>
<tr class="odd">
blah...
</tr>
<tr >
blah...
</tr>
<tr class="odd">
blah...
</tr>
<tr>
blah...
</tr>
<tr class="odd">
blah...
</tr>
.../table

because with CSS you can very simply:
tr {
styles;
}

tr.odd {
other styles;
}

[AlexDawson]

That isn't true because HTML is data description not presentation.

Incorrect, even though it is depreciated HTML can be very presentational, or do I need to remind you about <FONT> tags?

PS: You misread what I was implying, if you used extra mark-up purely for the purposes of providing presentation, that mark-up is for presentation benefit alone, which makes it by definition presentational mark-up.

[Stomme poes]

^ I think he meant, that that's not the true purpose of HTML... that that's why they're deprecated.

[AlexDawson]

True but a tag being used to aid presentation is just as bad as using a depreciated presentation tag. Like using IMG tags for flourishes and design elements (as opposed to using background-image in CSS). Those kinds of tags which exist in the mark-up purely for the purpose of presentation are unsemantic uses of the elements.

[AutisticCuckoo]

Semantic meaning they have nothing to do presentation and everything to do with describing the actual content/purpose of the element/data?

Yes, as far as that's possible. Sometimes CSS selectors cannot adequately target the desired element (especially cross-browser), so we may still have to bloat our markup a little bit with extra IDs or classes. That's where we need to be pragmatists, rather than zealots.

Well you could apply that to HTML and say that providing additional mark-up such as empty DIV's (for example to clear floats) would make the extraneous mark-up presentational rather than structural.

Yes, in this case the extra empty DIV is purely presentational. It's a necessary evil if we need to cater to browsers with poor CSS support.

[AlexDawson]

Yes, in this case the extra empty DIV is purely presentational. It's a necessary evil if we need to cater to browsers with poor CSS support.

Of course Tommy, but I was just using the example to show oddz that his idea about HTML not being able to be presentational was slightly incorrect

[cooper.semantics]

This is a question that I thought would be interesting to discuss that was motivated by the off topic discussion in this thread.

If your applying class/id attributes on the basis of whether or not you need to style a specific element aren't you condoning the mixture of structure and presentation? Thinking of the mark-up as a separate entity shouldn't it be written putting aside any need for presentation?

Doesn't the idea of applying attributes without considering how they may be presented support the notion of loose coupling between presentation and structure?

I think that using classes/ids/rel/rev attributes you can add further semantics to your document.

Some people think adding classes bulks up the document, but if you use these efficiently and give the data further semantics then your fine....

An additional bonus of using the class design pattern is the extra style hooks... If you keep styling out of your mine when developing a page and just concentrate on using the class design pattern to add extra meaning to your document, you can go back and style away...

So to answer your question from my point of view:

If you use the class design pattern to markup data that html does not have the vocabulary to semantically describe then use classes.... If you use classes for styling purposes you fall into the category of abusing them as many do.

[Stomme poes]

...If you use classes for styling purposes you fall into the category of abusing them as many do.

I do this (often, esp on main pages)

three divs (or whatever, but usually divs) for a main page, to perhaps showcase three (or two or four) main elements of (company) that some people would like to have pointed out to them or would like to click directly to. This is currently pretty popular in design, possibly even... trendy (yes, I know I'm not hip enough to make trendy pages; I don't use a Mac).

So for instance, I'm currently doing a moving company's website and they don't just do "moving" but would like to have their main page showcase their "extras" such as
1. Storage for in between moves
2. Repairs (home fixes before moving, including the yard!)
3. Moving shop (buy packing boxes, paper, blankets, roll-containers...)

so just for the main page, I make three boxes with a cute little image, a clickable header (h3 likely), the image is clickable, and some text saying Hey guess what we offer these awesome things to our clients blah blah read more... (this could also be a list, in fact the more I think about it, this one will likely become a list as it mimics the site menu anyway).
These boxes/divs aren't on any other page, and they are basically a showcase, and they are getting a class purely for styling reasons. if they weren't getting styled, they would not get a class. The class lets me either
-set them in a centered row using display: inline-block
-set them in a vertical stack
-offset them to cascade like a staircase
-whatever else I think of when sitting on the john

So, maybe that's abuse, but it seems the only practical way to style some boxes. I use a class, and the class is there purely for styling hooks, not because it has anything, at all, to do with the content. Right now, I'm calling them "Rubrieken" (categories) as they are showcasing other subjects related to the company. But it was nothing more than the first name I pulled outta my butt. Sure, I didn't name them "centeredboxes" but I could have.

Or, I could have added yet another div (or something) and given it an id, and then styled the boxes with #id div {styles;}.

Abuse?

[oddz]

but I was just using the example to show oddz that his idea about HTML not being able to be presentational was slightly incorrect

HTML isn't presentational. Like XML it is meant to represent the structure of data and that's it. In the context of a view on the server side one could consider it presentational, but once its outputted to the page it is a structure and that's all it is. Take away all the presentation and what your left with is a tree.

[AlexDawson]

oddz, please re-read the thread (as you apparently just skipped to the end) . While it is meant to represent the structure of data, clearly there are examples such as the now depreciated font tags which are entirely presentational and nothing else, your idea about HTML not being presentational is in certain circumstances wrong.

[oddz]

Regardless of the node HTML is always a structural representation of a hierarchy.

<ol>
  <li>
     <font size="4" color="red">Para 1</font>
  </li>
  <li>
     <font size="4" color="red">Para 1</font>
  </li>
  <li>
     <font size="4" color="red">Para 1</font>
  </li>
  <li>
     <font size="4" color="red">Para 1</font>
  </li>
</ol>

+ ol
  +li
    +font
      - simple text
  + li
    +font
      - simple text
  + li
    +font
      - simple text

[cooper.semantics]

I do this (often, esp on main pages)

three divs (or whatever, but usually divs) for a main page, to perhaps showcase three (or two or four) main elements of (company) that some people would like to have pointed out to them or would like to click directly to. This is currently pretty popular in design, possibly even... trendy (yes, I know I'm not hip enough to make trendy pages; I don't use a Mac).

So for instance, I'm currently doing a moving company's website and they don't just do "moving" but would like to have their main page showcase their "extras" such as
1. Storage for in between moves
2. Repairs (home fixes before moving, including the yard!)
3. Moving shop (buy packing boxes, paper, blankets, roll-containers...)

so just for the main page, I make three boxes with a cute little image, a clickable header (h3 likely), the image is clickable, and some text saying Hey guess what we offer these awesome things to our clients blah blah read more... (this could also be a list, in fact the more I think about it, this one will likely become a list as it mimics the site menu anyway).
These boxes/divs aren't on any other page, and they are basically a showcase, and they are getting a class purely for styling reasons. if they weren't getting styled, they would not get a class. The class lets me either
-set them in a centered row using display: inline-block
-set them in a vertical stack
-offset them to cascade like a staircase
-whatever else I think of when sitting on the john

So, maybe that's abuse, but it seems the only practical way to style some boxes. I use a class, and the class is there purely for styling hooks, not because it has anything, at all, to do with the content. Right now, I'm calling them "Rubrieken" (categories) as they are showcasing other subjects related to the company. But it was nothing more than the first name I pulled outta my butt. Sure, I didn't name them "centeredboxes" but I could have.

Or, I could have added yet another div (or something) and given it an id, and then styled the boxes with #id div {styles;}.

Abuse?

Their is one way to semantically mark up data but a lot of people veer away because they don't like how classes look in their markup.
e.g.

<div class="section-entry">
    <h2 class="title">....</h2>
    <p class="description">....</p>
    <p class="date">....</p>
    <ul class="items">
        <li>...</li>
        <li>...</li>
    </ul>
</div>

Some authors seem to actually use this approach which might seem to most (cluttered), but in all actuality are keeping html strictly data with no presentational aspect in mind...

[Aken]

Just to touch on the original question of this thread: How can you NOT condone mixing structure and presentation? That's what the web is meant to do.

SGML is a system for defining markup languages. Authors mark up their documents by representing structural, presentational, and semantic information alongside content. HTML is one example of a markup language.

http://www.w3.org/TR/1999/PR-html40-...o/sgmltut.html

W3 encourages the use of better distinction between structure and presentation through the use of style sheets, for the purpose of aiding in the accessibility of the web to non-visual user agents. A user agent is defined as any device that interprets HTML documents (your browser, text-readers, search robots, etc). This is also the main reason why HTML4 and 5 has deprecated presentational tags such as <b>, <menu>, <center>, <font>, etc.

Class names, according to W3, are used in general 1) as style sheet selectors, and 2) for general purpose processing by user agents (eg: translating HTML documents into other formats). So unless your user agent has a specific use for class names - which we know search engines don't, and screen readers focus on content not attributes - your class names are only going to be handled by style sheets, or to make yourself happy.

Basically what I'm saying is you can do both and please everyone. The thread in general sounds more like a debate between when and how you should and use class names, which I think is semi-irrelevant and personal preference.

Also, to you oddz, I believe you're thinking too analytically. HTML is NOT a server-side language, nor was it ever intended to be. The information is designed to be viewed, not executed. Its structure exists as a means to provide standardization, internationalization, etc. Yes, in terms of hierarchy, most HTML elements have a set structure. That doesn't mean the content itself will be taken into consideration when regarding that hierarchy.

Some bedtime reading: http://microformatique.com/?p=83

I think that explains my point... I worked on this post for far too long, might have mixed some things up

[AlexDawson]

It is not really a matter of not mixing structure and presentation, it is a matter of trying to separate as much of it as possible, and trying to organise the presentation more effectively so that the code is easier to maintain. No professional developer will proclaim that using CSS within the HTML document is explicitly a bad thing however it is rather counterproductive to the benefits which putting the CSS into an external file will provide.

[felgall]

It is not really a matter of not mixing structure and presentation, it is a matter of trying to separate as much of it as possible,

Very true - especially once you start to consider different stylesheets for different media and perhaps even alternate stylesheets which can be selected from the view menu of most browsers so as to change the appearance of the page without touching the content (you can add the same functionality to IE using JavaScript). Once there is more than one alternative way that the page can be styled you can't have any presentational material in the HTML or it will be unable to change when the alternative styles are used.

At the moment some presentational hooks are needed in the HTML to allow for styling that CSS 2.1 doesn't support such as alternate colours for alternate rows of a table. Once all the browsers support that part of the CSS 3 specification that allows that to be defined entirely in the CSS then those class hooks will become redundant. One of the purposes of the CSS 3 draft is to resolve those issues where some HTML is still seen to be at least partly of a presentational nature.

[Stomme poes]

<menu>

Since it's being revived (in the new form of <nav>, I'm not talking about HTML5 <menu> cause I was even surprised to see that, it must be food menus), I wouldn't consider that a presentational tag. In ye olden days, the idea of a "site menu" was pretty new, and stringing together a bunch of hyperlinks and calling them a "menu" of options might have once seemed presentational... nowadays, it's considered semantic (we say that such a string of hyperlinks is a menu).

and screen readers focus on content not attributes -

ok you already know this, but titles, alts, and scopes/headers are attributes, and are focused on by (the better) screen readers. I admit, nitpicking. : )

Some bedtime reading: http://microformatique.com/?p=83

This is what cooper is talking about. I did think the original question wasn't about using classes to inject semantics, but looking at the original thread linked in the OP, it seemed to be more, does it make sense to give every child of an element a class, if it's stating what that thing is?

If you're using classes as CSS hooks, I find it unnecessary bloat. If you're using them for microformats, it's too bad there's no way to strip those from users like me whos browsers never look at them, yet serve them to the PDA/whatever that would like to use them for semantic reasons. Wishes, ponies....

[Alex]

Yes, as far as that's possible. Sometimes CSS selectors cannot adequately target the desired element (especially cross-browser), so we may still have to bloat our markup a little bit with extra IDs or classes. That's where we need to be pragmatists, rather than zealots.

Wonderful advice. I have developed on a personal, hobby level and I've developed in high-pressure, corporate environments. When I'm developing on a personal level, it's very easy to play towards my zealot side because the variables are controlled by me in many cases.

On the other hand, in real-life situations in the workplace, it is much different. When dealing with clients and/or bosses, it becomes increasingly difficult to meet demands and maintain all of the ideal practices. While many foundational methods can be followed, at times it's just necessary to step outside what's ideal and have a presentational element in your code if it makes the project a success and the solution a solid, reliable one. Pragmatism can be the difference between your project succeeding or failing.

Yes, in this case the extra empty DIV is purely presentational. It's a necessary evil if we need to cater to browsers with poor CSS support.

This would be a great example of what I just explained above.

Alex

[oddz]

While many foundational methods can be followed, at times it's just necessary to step outside what's ideal and have a presentational element in your code if it makes the project a success and the solution a solid, reliable one. Pragmatism can be the difference between your project succeeding or failing.

no debate there.

[cooper.semantics]

your class names are only going to be handled by style sheets, or to make yourself happy.

Not true... Have you looked into Microformats