A design pattern for image and figure alignment

46 thoughts on “A design pattern for image and figure alignment”

1. i must be thick headed about this semantics stuff. actually, i must just be stupid in general.

   the whole point of giving the image a class is to move it to one side or the other, but a class name that tells you where the author intended to put the image is anti-semantic?

   yes, it’s presentation. semantic presentation. that’s bad? i’m so confused. ‘splain me better. a, b, and c seem arbitrary and meaningless. why should they translate to left and right?
   and why not do class="figure a", so that your figure and your a are reusable? and why restrict this stuff to images? surely tables, blockquotes, and lists can be figures as well?

2. Chris,

   I recently started a series of articles on the whole issue of semantics in HTML – built in, microformats, design patterns, and more.

   At present, as far as I am aware, all microfomats fall into one of two categories, Content semantics (they add richer semantics for marking up specific kinds of content, like addresses) or Relational semantics – they formalize a way of capturing the relationships between resources, or the things those resources represent (rel-license in the former case, XFN in the latter).

   Now, the design pattern you outline here captures a different kind of semantics, I believe – one that I have losely termed Structural – akin to paragraph or heading elements, for example, in HTML.

   The point of this long winded introduction is to pose the question, do microformats restrict themselves to only content and relational semantcs, or is that simply an accident of current development? Is the microformats project the best place to develop all kinds of semantic extensions to HTML? I don’t know the answer, nor have a particular position, but I do think it is an interewsting question – but of course maybe its not 😉

   john

3. I think .figure-c should be float:left, not float:right. And I’ve adopted this on my blog :).

4. Pingback: Simon Jobling (aka One Phat DJ) » Blog Archive » Tagged (2007.02.26)

5. Since you’re using float on “img.figure-b” and “img.figure-c”, don’t you need to specify an explicit width for those classes?

6. So let me see if I’ve got this correctly…

   We want a microformat which indicates that the given image is a figure, as opposed to some other kind of image, so that (for example) some other application can trawl through and generate a table of figures in your document.

   So far so good.

   On top of that, we want to codify whether the image should be floated left, right or centre – presumably so that applications like feed readers display images where you’d like to see them.

   Now there’s an argument to be had as to whether such presentational information should be embedded and/or respected. I don’t personally have a problem with it, but for Heaven’s sake don’t obfuscate the value with -a -b and -c codes just out of “class names shouldn’t be presentational” dogma!

   Class names should reflect what they classify. In this case if we’re classifying “the set of figures that should be displayed to the left of a document”, “figure-left” (or similar) is just fine.

   In any case, as Adam points out, we should really be using multiple classes to define those different issues. So class=”figure” identifies an element as a figure, class=”figure left” further identifies it as needing to be floated left.

7. And why not just get a template that suits your needs by default?

8. just to take chris hunt’s idea of a ‘table of figures’ further, each figure should probably also have an ID. wordpress could add these pretty easily (i thought it used to), since it’s already giving a blog-specific rel value (e.g. wp-att-506).

9. Tim, img elements have intrinsic dimensions. (but that assumes the user does load images, I believe)
   —
   I don’t know how’s the discussion going for this microformat, but please don’t forget to cover one of HTML’s semantic weaknesses: let us associate a caption to a figure!

10. I wonder where my comment went?

    +1 for figure-right, figure-left, figure-center.

11. The general concept of a ‘figure’ class is nice – especially the idea that it could be applied to other elements like tables etc… But I’m so with Chris Hunt that the -a, -b, -c notation is really no better than the original ‘left’, ‘right’ and ‘center’ approach.

    A B C are meaningless. They have no semantics. ‘left’ and ‘right’ at least have some meaning, even if it is presentational. Where the decision to float an image left or right is entirely arbitary and purely presentational, you can’t cover up the fact that your layout has no semantic basis by picking meaningless classnames. The ‘presentational’ classnames “left” and “right” are surely the lesser evil here?

    For the ‘figure-a’ you could find a more semantic tag than “a”. Something like “masthead” or even “block” which arguably tells us something about how the image is being used. I don’t actually like either suggestion – perhaps others will have better.

    Ultimately wouldn’t context-based rules would be better and more semantic? Such as images in paragaphs are floated, while those just in a div are not and are centered. These are conventions which feed readers et al could equally deploy without adding extra classnames (though I guess that might mean it wasn’t a microformat)

12. While I can appreciate your principles and ideas, I’m not sure I’ll be using this idea any time soon.

    For me, while “align-left” is technically not correct as it describes a changeable state of something- design related, as opposed to content based- it at least makes some sense. On the other hand “figure-a” is doing the same function, but to anyone else trying to understand your mark-up it would have no relevance unless they understood the system you were using, which seems to me to somewhat defeat the objective of semantics. I thought that Semantics was about (as well as being “right” and fashionable 😉 ) creating mark-up that is “future proof”, will redesign easily and well (hence, not giving ids and classes of “redtext”- thank you Myspace…) and can be understood by anyone who looks at your mark-up (again, thank you Myspace..).

    Applying this, the figure-a system wouldn’t be easy for people to understand who weren’t familiar with your system (point 3) and would still do the same function as “align-left”, so would require touching the actual XHTML if you wanted to move one element from the left to the right, for instance, thus not really making it any easy for design purposes and the ultimate aim (or so I thought) of having pages that can be completely redesigned without touching the XHTML whatsoever.

    Perhaps I have misunderstood the concept, because I certainly don’t think I made much sense. Personally, however, I think that the align-left system is still the best system we have without grouping single “properly” named elements to align left which, for dynamic content like blogs, is not really feasible.

    Possibly, if a blog wanted to really be Semantically correct and name all their images with classes that applied to their function and not where they appear or how they look, then wouldn’t it be best to have all the images, for instance, within the articles given a class of “article” and all aligned the same, to the left or right according to preferences, and the same principle for other images in sidebars etc.?

13. I can understand how figure-a is semantically different from figure-b and figure-c — there’s a legitimate case to be made that a “block” figure (one that interrupts the flow of text) is different from a “floated” figure (one that is floated to the side or placed in a margin) in more ways than just presentation.

    But how are figure-b and figure-c semantically different from one another? Isn’t it enough to indicate it’s a “floated” figure without specifying which side it’s on?

    There’s no point in pretending to be presentaiton-agnostic when the only difference between figure-b and figure-c is visual. If you think the distinction between left and right floating is important, then you should name the classes accordingly. If not, then rename figure-a to figure-block, consolidate the other two into figure-float, and let the implementation decide which side to float them on.

14. It seems to me that one advantage to this system is that down that track if you wanted to switch the presentation of your floats, i.e switch figure-b to float: left and figure-c to float: right, then you don’t get caught out by having presentational names which are then counter-intuitive to their actual presentation.

    In my mind, that doesn’t make them any more semantically correct than figure-left or figure-right, simply more flexible. I guess as you mentioned it’s more desirable to be semantically neutral than incorrect/restrictive.

15. Nice idea, Chris. Do you think it would be better to give a class of “figure” to style all figures, then give each figure a unique ID value of figure-a, instead of adding another class? It seems to me that the ID attribute is ideal for marking up a specific figure, since that’s what the ID attribute is for. Then again, this wouldn’t work if you had multiple “figure-a” figures on a page. But I would question whether one would want to do that. In print publications (say, books), there are often lists of figures, but figure-a is never repeated in a book. Using the ID attribute would help ensure the uniqueness of figures.

16. Chris,

    I’m interested in what makes something a figure a, figure b and so on? Is it simply a matter of taste as a designer, or is it a function of place in the document (first image is figure-a) or something intrinsic to the image?

    john

17. I, too, am curious as to what makes something a “figure a”, “figure b”, and so on. I initially thought these were to be unique (then why not use id?), but when you mentioned deprecating “alignleft”, “alignright”, and “center”, it sounded like they aren’t – you might have two images with the “figure a” class because “a” really means center. If all we cared about was the site these images appear on, that seems just fine. You can come back later and change your CSS because you decide you really want your “figure a”s to be on the left. Great. But suggesting that other software should see a “figure a” and know that it should be centered and break the content flow is definitely bad. You’re giving permanent, non-transient meaning to the letter “a”. The whole point of semantic markup is that the words you use mean what they are or what they mean in actual spoken language. “rel=’friend'” means the relationship is that of a friend, “class=’vcard'” means the content represents a vcard, “rel=’stylesheet'” means that document is a stylesheet for the document you are viewing. “a” meaning “centered” certainly does not fit with that idea. Better to leave it as “center” or “figure-center” or “figure center”.

    However, I question the idea putting this in a site-wide stylesheet at all. Unless we’re looking at this from the point of view that we really have certain types of figures and we display each type in a certain way (e.g. “figure-a” means a graph and we want to display graphs centered and have them break the text flow), we’ve essentially traversed into putting presentational information (“this is a left-aligned figure that does not interrupt the text”) into the html. Is that bad? I’m not sure. It’s definitely *technically incorrect,* but it’s also much more convenient. I think the technically correct way would probably be to put the css on the page in a <style> element or a style attribute, since whether a certain image is on the left or right is layout information that is essentially specific to that page. Of course, since these are pretty generic styles that we’d likely use again and again, that’s a huge hassle. So, putting that style information in a site-wide css file is technically incorrect, but in the interest of making the technology work for us and making things more convenient, it might not be bad. But then, that’s pretty subjective.

    And a last little point: as Adam said, shouldn’t this go for other types of elements besides images? After all, a table might be a figure, too. If it’s just images, then doesn’t the <img> tag itself imply that it’s a figure? Shouldn’t non-content (and thus non-figure/non-illustrative) images be css backgrounds?

18. Many complaints posted, but no suggestions for an alternative method.

    How about we consider that each of these images has a rank of importance? In design, a centered image or masthead-type image usually has the most impact. It is meant to be noticed and is used to communicate concepts of greatest importance. A left-hand image would be second in importance, and a right-hand image of least importance. [There are exceptions, of course, in some languages that don’t read right-to-left.]

    So, perhaps our CSS classes become…

    figure-primary
    figure-secondary
    figure-tertiary

    …or something similar. Semantically agnostic.

19. A problem here is that not all presentational decisions have a basis in semantics.

    What happens when you have two semantically identical types of information that you might want to present in more than one way?

    We should be allowed to float images left or right for no other reason than “it looks nice”, without resorting to inventing semantic differences between the types of the images.

    Why not give all sematically distinct objects a default presentational style, then overide the default style on specific objects in the global CSS.

    So say, all ‘figure’ images are bordered and float left by default. However, some images on some pages are floated right, for purely presentational reasons.

    The CSS to overide the default styles could be maintained in a global style sheet so long as the specific images can be uniquely identified somehow (by id?).

20. Russ – that seems like a pretty good naming solution, but, like Andrew asked earlier, what’s the semantic difference between the left and right floated images? It seems like adding figure-tertiary is just making up semantics to satisfy presentational concerns.

    Tim’s solution seems pretty good — especially if you combine it with figure-primary and figure-secondary. You have text-interrupting figures (primary) and non-interrupting figures (secondary). Globally, you might make them block/centered and floated/left respectively and apply different/overriding styles to particular ones.

    The only change I’d make to that is to not put those overrides for specific figures in the global stylesheet; it’ll get bloated and cluttered pretty quickly. Instead, each page should have it’s own additional stylesheet or those overrides could be in a <style> element on the page.

21. primary, secondary, tertiary is a good suggestion, although it might run afoul of, or make confusing some layout elements. how about f1, f2, f3?

    so we get img id="figure-506" class="figure f1 left"

    since the point is that right and left can’t confer importance. by the same token, importance can’t confer position.

    -rob’s suggestion: i think all this in-post class stuff deserves its own stylesheet, possibly one that should be referenced as an attachment from the post itself, to inform feed readers of the formatting.

22. Regarding page-specific stylesheets, it might be interesting to add to the <link> element’s rel attribute. What if you had <link … rel=”page-specific stylesheet”/> (and conversely rel=”generic stylesheet” or “site-wide stylesheet”)? Or possibly rel=”simple stylesheet” if it were only doing things like setting some figures to float right? Then external readers might load a “simple” stylesheet. Then again, that’s pretty ripe for abuse.

    The other problem with this is that I don’t know if it might cause problems in some browsers (I know it works in Firefox, but what about Safari, IE, etc.)?

23. i was thinking more along the lines of adding
    <?xml-stylesheet href="http://www.somesite.com/css/elements.css" type="text/css" rel="generic" name="common"?> to the top of your atom feed, and getting feedreaders to start picking that up.

24. Line #24 should be “float: left”, according to the illustration.

25. A microformat of this type should concern itself only with semantic data and allow the specific presenting system define presentation style.

    This implementation seems to be solely concerned with presentation, and not with the semantics of a figure at all. As other comments have noticed, there is not even an implementation of a basic label.

    Compared to the hCard/vCard implementation (for example) I’m not sure why I would incorporate this as a design pattern, as it doesn’t really solve much beyond setting an image as being left/right/centered – and since other things like color and image width are implemented, I’d have to alter it on a case by case basis anyway.

    I would argue that a better system would be a norm based on the data associated with a figure for future machine readability combined with presentation css via stacking is a better solution. I’m not clear what a microformat based solely on presentation accomplishes, especially when it only provides a template for a single data type.

26. I love the idea of something more formal for marking up images – I share Dan’s frustration with the lack of a presentational side to images within newsreaders, and have been thinking about ways to do just this following my recent experience with Apress/friends of ED’s chapter formatting. Labeling images and other such inserts as “figures” makes as much sense as it does in traditional publishing, which is to say, boatloads 🙂

    The question of naming the classes has been my biggest issue – deciding between 3 separate classes (e.g. just figure-a, figure-b and figure-c) or the 4-class system you’ve outlined has just been a neverending loop for me. There are plenty of reasons to do one or the other, but both solve the problem, so I’m glad you’ve publicly suggested one.

    The class names also make sense: generic names are the only way to go, because it keeps presentation out of the equation – “figure-a” has no less semantic value than “figure-left”, because it’s describing a “figure” and the “a” variation. If I want to change my site design a year from now, I can switch figure-a from float:left to float:right or anything else I choose. The same can’t be said for figure-left or similar naming, and that flexibility will hopefully be extended to newsreaders or any other method of parsing my markup.

    The main question is, as John states, how do we determine which figures are -a, -b or -c? It could (and perhaps should) be simply a matter of personal preference (the focus being more on the consistency of the class naming rather than the actual use of them), or perhaps some sort of basic suggested hierarchy could be established, as a guide if nothing else.

    Rather than thinking of -a/-b/-c as denoting position (and since they can’t refer to order unless we expand beyond just a/b/c), maybe we can use them in a manner similar to headings: in order of priority. Thus -a would be a more important figure than -b which is more important than -c, etc.

    It’s not really ideal, and might not work for most people (I’m not even sure if I’ll do it that way), but at least it’s another idea for everyone to toss around 🙂

    Either way, I’m going to incorporate this pattern into my site and and future projects as-needed. At least it’s consistent, and with luck it may serve a bigger purpose down the road.

27. Wow — I’ve been arguably absent from this thread, but it’s great to see and take in.

    Dan, I think you’re closest to my thinking on this subject — while I completely appreciate everyone’s feelings about being practical, I just don’t think that it’s a wise idea to use position names in classes… that’s what the style attribute is for!

    As for the hierarchy you mentioned, Dan, I think you’re on to something… after all, we use H1-H6 for headings — why not doing something similar for images?

    Anyway, I think I’m going to stick with this for now — it might not totally take off, but until something better comes along, this is good enough for me.

28. “If I want to change my site design a year from now, I can switch figure-a from float:left to float:right or anything else I choose. The same can’t be said for figure-left”

    Yeah, but the proposal being made on this page is that figure-a should *mean* “a figure that should be displayed on the left”. If that’s what it means then why obfuscate it with all this a/b/c stuff?

    I think it would be helpful to start by defining the problem that this microformat is intended to solve. That would really help us in framing such solutions. My *guess* is that it’s mainly about news readers – I give some image a class of “foo”, and style it to float left, but news readers don’t read my styles and show the image inline.

    Now, if you’re worrying about what your site looks like in a feed reader you’ve probably got too much time on your hands, but let’s go with it anyway.

    We (supposedly) want a way of suggesting to other applications how they should display our content. That need not be the same way it’s displayed on our own site. I suggest three classes: “default-left”, “default-right” & “default-center”. Downstream users of your documents can take note (or not) of those presentational hints. You’re also free to ignore them yourself – giving the element another, more semantic class and applying styles to *that* instead of the default-xxx one.

    It occurs to me, incidentally, that if you want a solution that works TODAY, rather than years down the line, there’s a simple one open to you: use the “align” attribute of the img. Yeah, yeah, I know it’s deprecated, but it will (almost) do what’s required: feed readers will see it and apply it, but you can use CSS to override it according to your own semantic requirements.

    That’s assuming I’ve got the problem right – which I’d still like to see explicitly defined.

29. Pingback: Building a WordPress Framework at hyalineskies

30. I’m now using this design pattern on my site, at least until, like you said, “something better comes along.” I think this is pretty straightforward and it’s really easy to implement. So, why not use it?

31. What I have been doing all along was to have ‘float-left’ and ‘float-right’ classes and have something like [……], which will float the image box to the right

    Now it seems this isn’t the correct method to use…

    But it does offer flexibility as these two classes are not tied just to image elements, and can be used to float other elements as well, at least those which can be floated left or right depending on where it is and the context.

32. I like the idea of adding 2 different classes to the element.
    … class="figure primary"
    That way it’s always a ‘figure’ but can be bumped left or right depending on the next class. This forces adding another class definition to the css file, but it’s a nice trade off (arguably more code, but still).

    Where I’m not so sure is the usage of custom IDs for each ‘figure’, since that would really depend on the setup of your cms/blogsystem/etc.

    But from here, using double classes allows you to define the use of the same class on different elements as well, wouldn’t it?
    p.figure {}
img.figure {}
span.figure {}
    …and additionally on subelements as per your structure:
    p.figure img {}
p.figure span {}
p.figure img.primary {}

    And so forth…

    Though, it must be said, i’m not so up to snuff when it comes to semantics, where i’m considered a noob/gentile/unwashed/uninitiated/luser.

33. How about class=”figure primary”, class=”figure secondary”, class=”figure secondary alt”.

34. Luke, I like that approach, though using class names like “primary” doesn’t lend itself well to multiple uses in a hierarchal sense.

    Following up on Chris’ comment about H1-H6 for headings (which denotes hierarchy quite well, and suits multiple uses per-page), why not simply apply the exact same approach to figures? We could use either class=”figure-x” or class=”fx”, where “x” can be any number, in order of importance on the page (also allowing alternates easily, e.g. “figure-1a”, “f1a”, etc.)

    Perhaps too much navel-gazing on this, but I’m still trying to find a solution that makes immediate sense when explaining it to other people (say, clients who need to use said classes in a CMS).

35. @Dan — not a bad idea, though they’re considering removing the numeric heading tags in HTML5 and replacing them with a combo of <section> and <h> tags… which makes me wonder about presuming too much prioritization in these kind of figures when in reality, we’re looking for arbitrary formatting based on whims or design intuition.

    Ultimately if we were to use something like “figure-1” as the equivalent of an “h1” tag for images, I fear that we’d end up no closer to a solution. I think I’m going to blog about some more thinking I’ve done on this… thanks for pushing me forward on this.

36. What about using pseudo-class selectors? Obviously older browsers would have some issues but going forward it would be much more easy to maintain. Eg. give them all class=”figure” then give them a rel=”figure-a” or something similar which would then allow you to add in img[rel=”figure-a”] { float: right; }

    Just an idea – feel free to shoot me down 🙂

37. @Sean: yeah, that won’t work because the relationship (aka “rel”) of the image to the page isn’t “figure-a”… The whole point is to maintain semantics as much as possible — so we can’t pollute other attributes in the process. 😉

38. Apologies – forgot rel is only for links. If the image was enclosed in a link to a larger version you could then use the rel attribute. Not sure if that’s the scenario in this case though. Just throwing in some ideas.

39. Hmmm, re: the H1 -> “Section” and “h” tags, there was some pretty slightly heated discussion and confusion about the future of html5 and xhtml 2 and css3 at the @media SF hot panel discussion with the panel members:
    Tantek
    Joe Clark
    Cameron Moll
    Jeremy Keith
    Andy Clarke

    Besides the attacks and small banter, it was especially to do with the working groups and they’re ‘befuddling progress’.

    My point is, it’s even more frustrating coming up with semantics when the standards for markup are in a stalled state such as this.

    At some point, I’d like to see a revival of sites like http://bitesizestandards.com and more promotion of correct coding methods.

    Thanks for bringing up this topic up again and allowing discussion (comments).

40. Ah, Luke, I’m working on just that kind of thing… You’ll have to stay tuned! 🙂

41. Pingback: Styling figures with CSS3 - CSS3 . Info

42. They have no semantics. ‘left’ and ‘right’ at least have some meaning, even if it is presentational.

43. Schweet.

    But FWIW I would have named the alignments differently, i.e.:
    -a left (first), -b right (the obvious next one), which leaves -c for center (slightly mnemonic).

    –bentrem

44. @Ben: well, then you’d break the CSS convention of top, right, bottom left (TRBL).

45. Pingback: links for 2008-10-15 «

46. The problem with including figure-left or anything of that sort is that you’re *embedding presentational information still*.

    The cool thing about figure-a is that my user agent has no reason to render it left or right or center, but may render it some other way depending on what *makes sense* for the first figure in an article. It may even render it on another page (on a mobile device where real estate is important maybe).

    That’s what makes completely non-presentational semantics cool – the user does what makes sense instead of being stuck to what the publisher wanted. If you *must* embed style information, use the style attribute.