Semantics and Design
The other day while working on a Notre Dame site, our group came up against an interesting CSS dilemma. The design called for a fixed-height box with editable text inside that centered both horizontally and vertically. Seems simple, right?
Option 1: Semantic Markup
<div><br />
<h3>Centered Title Text</h3><br />
</div>
Ok, on to the XHTML. We’ve got a div with an h3 inside. Good. Now to the CSS. This is where things get a little unclear. Horizontal centering is easy enough with a text-align:center; on the enclosing div. But how can we vertically align something when we don’t know the height? The obvious answer to this would be to add vertical-align:middle; to the h3 element. Here’s what the W3C has to say about what this declaration should mean.
The element [with vertical-align:middle] is placed in the middle of the parent element.
Ok, so we try that… no dice. Almost no browser renders properly. So what are some other options?
We could use line-height on the h3 to match the height of the parent box. That would stick the text in the middle. But what if the text wraps? Well, then you’ve got one ugly situation there, as the wrapped line of text would be underneath the parent div, if it showed up at all.
So what about top and bottom padding on the enclosing div? Same situation, only a little better if the text wraps. The text would be readable, but not centered, as the top padding wouldn’t change, so our text would be a little south of center. Probably the best solution of any using this structure. But still not perfect.
If only there was an element who’s default nature in every browser was to vertically-align all enclosed elements to the middle. The only one I can think of is [GASP] the table (or more appropriately the td). Which leads us to…
Option 2: Not-so-semantic Markup
<table><br />
<tr><br />
<td><h3>Centered Title Text</h3></td><br />
</tr><br />
</table>
Yes, I know, even typing this I’m getting a little nauseated. But with only a few little CSS declarations, we have a cross-browser solution matching exactly what the design is calling for. Sure it’s a little ugly. But it solves the problem, doesn’t it.
Deciding on the lesser of two…
In option 1, semantics took the lead, while design had to give. In option 2, just the opposite. In one sense, why should designers have to bend just to make up for browser inconstancies? On the other hand, why should proper code give way because of the same? It’s hard for me to pick a solution here. In fact, I’m not going to tell you what we picked. What would you choose? I’d like to hear what you think.
Post and Author Info.
Published December 02, 2005 by:
Commenting is currently off for this post.
So far there are 40 comments.
This may seem a little pragmatic, but if this was my design (and i did it just for myself) I would rather alter the design than using a table here (would be the water/wine-thing, you know). Of course, working for a client is another story. Without heavy testing I can’t offer you a solution to your problem (I even doubt that there is one (at the moment) which remains semantically correct) but I can assure that I’ve been wondering why “vertical-align: middle” only works with TDs for a hundred times.
December 2nd, 2005
If the design called for a specific appearance and there were no compromising design changes that could be had, I would have to implement the design using the non-semantic solution.
Designers shouldn’t have to compromise the integrity (if you can call it that) of their design or the code that provides for it; however, what should be is not what is in this area. Compromises are perfectly acceptable if they provide a benefit to the end-user without any detrimental or noticeable cost or detraction. It’s hard to make a judgement on whether this is equally as acceptable if the compromise is for purely aesthetic reasons, but I would venture that it is in most cases.
December 2nd, 2005
Usually when the web designer does the designing and the building, little things like this can be foreseen and avoided, but when it comes up (either because you’re building somebody else’s design or just didn’t think something through properly) I usually opt for compromising the design to avoid the dreaded table tag.
On the other hand, sometimes sites just annoy me that much that i’ll use dreamweaver objects just to get the job done. There i’ve admitted it. Maybe the healing can now begin.
December 2nd, 2005
From my limited understanding of CSS (and O’Reilly CSS Pocket Reference), can you not give the div the attribute
display: table-cell;? My thinking being that most browsers will correctly showvertical-align: middle;in a table – so change the div to mimic a cell and it may work?December 2nd, 2005
I design web pages for fun, and the bulk of which are Flash-based. I have been reading blogs recently on CSS and DIVs, and everyone bashing tables. What’s so bad about tables? They work well, they load fast, and they are much more cross-browser compatible than DIV tags. I often look for solutions to my DIV positioning issues, and most times I find what I need, with a disclaimer “doesn’t work in IE.” IE is atleast 75% of my viewing audience. So if it doesn’t work in IE, it doesn’t matter to me. Maybe I am just uneducated in DIV positioning. So can you tell me? What’s so bad about tables? I’ll be open-minded about it…. Convert me!
-Justin cmsjustin |at| gmail |dot| com
December 2nd, 2005
I’d do the table. CSS is a work in progress, and probably always will be. Maybe this design will still be around when an elegant solution is found, and maybe it won’t be.
Do the best you can, never fudge unless you have to, and when you have to, just do it and move on.
December 2nd, 2005
Adam: That is another option, but not very browser compatible. There are still several browsers that don’t understand this declaration, so unfortunately, it wasn’t an option for us.
Justin: In this case a table is not semantic because the data inside is not tabular… it’s that easy. Element positioning with CSS is a very different thought process than with tables… and trust me, once you get it, it’s actually way easier to deal with, but it takes time to learn. It can be frustrating at times, but it’s far better in the long run. I’d encourage you to read ‘Designing with Web Standards’ by Zeldman and ‘Web Standards Solutions’ by Dan Cederholm after that. This will give you a great introduction to the theory and practice of using the web as it was intended.
December 2nd, 2005
I would choose option one. I’m sure you already have a solution but this css seems to work well in Firefox. I’d be interested in knowing IE results. CSS:
#header { background-color: #333; height: 200px; overflow: hidden; position: relative; display: table; position: static; }h3 { color: #FFF; text-align: center; display: table-cell; vertical-align: middle; }December 2nd, 2005
aaand… since steve just posted while i was posting… now i know
December 2nd, 2005
whoops… position: relative; position: static;—> don’t need either…. unless you want to explicitly declare those properties.
also… sorry to hijack this post and carry on my own conversation
December 2nd, 2005
The underlying code might not be what you’re after, but this demo from Web Page Design for Designers looks like it’s accomplishes everything that you were attempting.
December 2nd, 2005
YavaScrip…(cough). What I meant to say is, JavaScript. I figure you make it look as best as possible with CSS, and then fix it with JavaScript, then only about 10% of the ‘disablers’ will view the less than par look. Go with the div/h3.
December 2nd, 2005
Steve, what is driving the height of the div? The amount of text inside it? If so why wouldn’t you just add top and bottom padding to the h3 element? Then it would always be centered vertically whether the text wraps or not. Am I missing something? I tried mark’s suggestion but couldn’t get it to work in IE.
December 2nd, 2005
Tim: The issue with that demo is that the item being centered vertically is fixed height… not the case with the text in my scenario. It could be 1 line, or maybe 2… or the font size could be increased by the browser…
Dustin: Yes, JavaScript could be implimented to fix the presentation. But seing that JavaScript is meant to be a Behavior level, isn’t using it to fix presentation just as unsemantic as using a table?
Brett: The fixed height in our situation came from an aligning image to the left… the container block was suposed to be XXX pixels high exactly… no more, no less. The text inside was to be centered inside this fixed height (and width) block.
December 2nd, 2005
I would have used display:table / display:table-cell for modern browsers and come up with a reasonable compromise for IE (the line-height trick or letting the design be slightly off).
December 2nd, 2005
I suppose that’s acceptable, and the web standards crowd won’t burn you at the stake over it, especially since it’s work-related, and nobody wants you to learn your job. Incidentally, in past situations, that’s the only way I could figure out how to do things cross-browser without some serious hacking.
December 2nd, 2005
Er, that last little bit should’ve read “lose your job.” I guess I should check the live preview, eh?
December 2nd, 2005
is this the ajax comment?
December 2nd, 2005
What about this? Dušan suggests nested <div>s …
December 3rd, 2005
Well, I’d rather tell my client “No can’t do – your entire computer will explode, and you’d have to pay me double” rather than use the
tableoption…On the other hand, I’ve been in this situations before, and I know how frustrating it is (I keep a Dell, just so I can hit something whenever such happens… My mac is just too sexy to hit…)
What I’d do, is either keep the text short enough not to wrap – or to take the picture as a CSS replacement and do a
no-repeatwith a proper background color…Or change the design.
December 3rd, 2005
Yes Steve, I think that’s a questionable fuzzy area of JavaScript. Sometimes I wonder how much presentation is allowed to be manipulated through JavaScript. Afterall, the DOM has built in style properties. I suppose the grey area is that you’re not just manipulating the presentation for a cool effect, you’re ‘fixing’ your presentation which I guess makes the case for not using it.
Either way, you shouldn’t be ashamed if you go the JS route, but all the power to you if you it working with ‘CSS only’ which would still be ideal.
December 3rd, 2005
Well, I’d never seen it before, and all the extra tags suck a bit, but the link that Florian provided does in fact work.
December 3rd, 2005
Florian and Jeff: Unfortunately IE5 Mac compatibility was a project requirement because of higher-than-normal campus market share. The method you describe does indeed work in modern browsers, but not in IE5 Mac. Pisser, huh?
December 3rd, 2005
I haven’t tried it, but would it work if you set the H3 line-height to 1em, and then set the first-line pseudo-element to have a tall line-height? Theoretically, any text that wraps in that situation should look normal.
December 4th, 2005
I’d just take the table route. Even Zeldman writes about hybrid use of techniques (had the book but you triggered me in re-reading). It’s a temporary problem anyway, since the IE5 Mac will cease to exist.
As for the almost-there solution: while Florian cam with the actual example, Roger Johansson launched the idea.
December 4th, 2005
I would just use a TD if its for a client, I think a client would rather have something that works on all browsers rather than a div site!
December 5th, 2005
At work recently we’ve been using little bits of JavaScript to tweak layouts on non-conformist browsers, taking the view that if the content is totally semantic then it is somewhat future-proof.
At some later stage when the worst offending browsers have dropped off the radar we can remove the unnecessary JavaScript.
December 5th, 2005
I’d still say that a JavaScript route is better than a non semantic table route…you know, if you had to pick one or the other. That’s just what I think.
December 5th, 2005
Hi, Steve. That’s all I can say on this one, because I don’t have a clue. Maybe your next post will discuss hortatory subjunctives in the Greek New Testament! :) See you soon!
Dad
December 6th, 2005
Prefix: I’m all for standards, they’re a good thing.
It seems that often, web standard advocates are blinded by ‘the standards’. At the end of the day, your job as a developer is to get the job done. If a client wants design A, then you give it to them if at all possible. If it means sacrificing a little markup for it – so be it. If you’re really struggling with using a table, because ‘its wrong’ – run it past your client. I’m sure, in nearly every case, they’ll be happy to use a table here and there.
Ultimately, the difference between div->h3 and table->tr->td->h3 is minimal. Yes, you use a couple extra tags but since there isn’t multiple rows and cells, you’re not losing much either. In this scenario, I would nearly look on it like wrapping a h3 in three span elements – futile but it’d still basically mean the same thing.
Al.
December 7th, 2005
Alistair is spot-on.
My mantra at the moment is “standards work for me, not the other way around”. The table method (barring a new css solution that doesn’t require 20-million divs) certainly looks like the most pragmatic solution in this case.
-Josh
December 7th, 2005
I still disagree with Alistair, of course if you run it by a client they’re going to say “go with the table.” Besides, what do they know anyway. Ask your client whether you think it’s appropriate to use a windows server vs. a linux server. Point being, they won’t have a clue. Our job is to do it correctly. The matter isn’t about bloated markup. Even if using a table meant ‘less’ markup you should sway away from it.
If you’re using ‘20 million divs’ then there is something obviously wrong with your development process. Using the correct markup isn’t hard. I really don’t see how using JavaScript for this little piece is all that bad. Are people scared to use it because they don’t understand how to use it? (Steve, I know you aren’t).
December 7th, 2005
For what it’s worth… I’d go with the table option.
I’m all for web standards as well however if you need IE5/Mac compatibility you’re not going to have much option (having just spent ages trying to do almost exactly the same thing and IE5 on Mac is always the exception to the rule!
December 7th, 2005
The only ie5mac stats you’re going to be getting are from web developers testing your site in it… isn’t it about time we imported our styles like this: @import”/css/styles.css”;
December 8th, 2005
Dustin: On campus, there’s still a lot of Professors, etc. with old university machines that use IE5 Mac. Quite a few more than I even expected when I came here. I’m no happier than you are about IE5 support, but at least for another year or so, it’s going to be neccessary to support it here at Notre Dame, at least for this kind of project.
December 8th, 2005
I love it when people point out the realities of building websites. Many, many, many standards nazis completely disregard the real world and throw design aside for code.
A lot of times it’s better to have a superflous div than spend 5 hours wrestling 5 different browsers. A lot of times it’s better to disregard those with javascript turned off to save 80% time on a project. There’s just so many times that doing the “right thing” isn’t the best choice.
December 8th, 2005
Steve, That’s definitely your call. I am definitely the more progressive type and would opt for the ‘upgrade your browser’ routine. I know that at Sacramento State almost every computer in the lab was a windows machine with IE6 which at least serves a decent box model (and that was in 2002). And as we all know, Mac users should be using Safari anyway at this point. And well, most are now.
Steve, do you personally know these professors that are surfing on IE5? Have you looked at your logs rather than just casually noticing old machines?
At Yahoo!, we are no longer serving dispay styles to the IE5.x- generation of browsers. Nor will we be serving behavior.
Kyle, I resent the fact you’re hinting that I’m a standards nazi. It might just be that I have a little more experience than you in the industry ;) Enhancing your code improves the accessibility of a document. Content is in fact, more important than design.
Has anyone peaked at Rogers recent post on 10 reasons to learn and use web standards? http://www.456bereastreet.com/archive/200512/ten_reasons_to_learn_and_use_web_standards/
If you’re using a table (for other than what its intended for) because of a design problem, it ‘unaccessifies’ the document.
One last thing Steve, technically your first approach works, if it’s just the wrapping your concerned with, why not stretch the outer box as well? Fluid inside fixed is quite an odd combination to seek after.
December 8th, 2005
Dustin, I was not aiming my comment at you at all ;) No need to be condensending. There’s no need to assume you have more experience in the industry. Quite frankly, you have no idea of the work I do day-by-day.
I used to think as you did before my current job, but after building my first half a dozen sites, I learned more than any book or article could ever tell. There’s a big separation between theory, goals, and practice.
December 8th, 2005
Dunno if this might be helpful:
Vertical and Horizontal Centering 2 by Jon Hicks
December 9th, 2005
Kyle, my mistake. It’s tough to figure out what people are saying without hearing a voice.
My apologies :) You still rock bro. 9rulers need to stick together ;)
December 11th, 2005