content layout headaches

So yeah, we've now reached the point where we are worrying about efficiently implementing things like 3d-transforms in css, how cool is that? Exciting times no doubt, but one would assume this means that all the basics of visual layouting would be covered by now. Well ... no, not in the slightest. So let's take a peek at one of the most basic issues that still exists in modern day web development and try and look for some ways to work around it.

who is your king?

Content is king, what lovely a cliché. Even though this is something we preach to everyone entering the wonderful world of web design/web development, the way our profession is evolving is hardly conform with this cornerstone of our believes. When it comes to the core content of a site, we're still letting clients fiddle with rich text editors until every notion of semantic validity and separation of content and style is shred to pieces. It's funny how CMSes have pretty tight control over everything not related to the core content of a page, but fail when it comes to what matters the most.

Not only that, css is still quite under-equipped to deal with very common cases of layouting our core content, at least, if you care about structural validity in html. Most designs are doable if you start playing around with the logical order of elements until you can match the design, but looking at the resulting source code there is often very little left to be proud of. And one of the most irritation-inducing design hurdles plays between the heading and the image of a content unit. Let me explain.

heading-first htmling

To make the core content a bit more attractive we often introduce several, semi-decorative images into our text units. Sure these image are somewhat related to the content, but they also serve a clear decorative function. Some images are floated left, others are floated to the right to create a more exciting layout dynamic. This is all good until we throw some headings into the mix, expecting our headings to flow along with the text.

It might be just me of course, but as a html guy I believe that whatever blurb of content you begin, you always start with the heading. The function of a heading is to introduce the content that follows the heading, so naturally it should be placed first in the content. This is a major problem for the css, because in order to make use of floats as they were intended, the floated element should appear first in the source. Say we want a floated image with the heading and text appearing beside it, we have to put the image first in the source. Ugh.

One other popular example (mostly related to content types - check out the product blocks on amazon.com) is to visually put the image above the heading. Luckily this poses less of a problem as these instances of images are (almost) always equal height, so some position absolute magic does the trick here. Clearly amazon.com does not really care about logical order though, they don't even seem to care about semantics as there isn't even a header in sight.

so what can be done?

.wrapper {position:relative; padding-left:Xpx;} .wrapper.noImg {padding-left:0;} .wrapper img {position:absolute; left:0; top:0; }

If the text does not need to flow around an image and you can safely estimate the max-height of each separate block, the position absolute trick is your best bet. It's not very flexible and you haven't lived as a csser if such an implementation didn't come back at least once with the remark "but what if there is no image". Back-end developers probably hate me for it, but when there is no image this solution requires an extra class on the wrapper. Clearly not an ideal solution, but it does the trick in some cases.

.wrapper h1 {margin-left:Xpx;} .wrapper img {float:left; margin-top:-Xpx}

Now, assuming you've put your image between the heading and the text, there is another semi-workable solution. Just provide a margin on the heading, float the image and pull the image up with a negative margin. This will blow up in your face if the width of the image changes or when the heading breaks to a second line, but in some cases it's definitely worth the gamble.

And that's about as far as I got, at least if you opt to place your heading first. Most people don't really care about that of course and they will just put the image first, float it and see the design adapt as it was prescribed, but there's an interesting little problem with that way of working, especially when dealing with rich text editors.

structure I tell you!

When I write html code I always provide a wrapper around a heading + p + img + ul + whatever other elements comprising a logical unit of text. When there are nested text units, I make sure they are structurally nested as a single unit in the parent text container. There is no good way to do this with rich text editors as far as I know (unless you're using a wysiwym editor) and technically this could be considered overkill. After all, a logical unit of text could be described as hX ~ hX (all the elements between two headings of the same level.

If you want your heading to appear next to a floated image though, you need to place your image in front of the heading. Considering the rule above, this means the image will be seen as part of the previous text unit, not the actual text unit it belongs too. Clearly a structural error that cannot be detected as it is entirely dependent on the context and the styling of the image. Visually it may look okay, but structurally you're constructing one big mess.

conclusion

Long story short? There is no good way to make an image appear next to a heading + text. And that's a pretty sad observation, this being 2012 and all. There are some less than preferable ways to work around the problem, but none look very appealing to me. If I missed something here, please let me know.

So can we really say that content is king when we have such little control over the core content of our sites? Maybe this should be fixed before we're going to put all our content in 3D spaces.