A heading solution you haven’t seen before

Sometimes I see such gems in my daily work, I just have to share…

Currently, I’m working on upgrading a home-brewn Content Management System for a customer, and it has been around for a fair number of years. While it’s naturally old and outdated, it’s in pretty good shape given its age and IE-only support (initially built back in 2002 or so).

However, one thing really caught my attention the other day: how to select the desired font size for headings for pages. It was made up of an input field and a select element, to write the desired heading text and choose its size. Like this:

<input type="text">
<select>
	<option value="11">Small</option>
	<option value="12">Medium</option>
	<option value="13">Large</option>
</select>

Please notice the value 11, 12 and 13 for the option elements. In the first version, these were the actual font sizes used in pixels. So far, so good, all in order with how things were built before.

Darwin?

But then, at some point in time, something wonderfully entertaining happened! They decided that hard-coded font sizes wasn’t a good thing and not very semantic, so they went for using proper heading elements. Great! But, how did they ensure backwards compatibility (well, sort of) and avoid updating the CMS in any way?

This, my friends, you will not believe. Someone got the great idea of deducting the number 10 from the value set in the above depicted drop-down, and then in turn make into a corresponding heading element. So, a heading with a set size of 13, minus 10, turned into a h3 element with this magic formula:

13 (set CMS font size) - 10, then add h before it = <h3>Heading</h3>

The result of this is that the set size of 11 suddenly was h1 elements, 12 was h2 etc. The headings were thrown around a bit, but (sort of) backwards compatible.

When I saw this solution, I really didn’t know what to say. What do you think? πŸ™‚

20 Comments

  • Richard Fink says:

    CUTE SOLUTION. A perceptual thing. It writes itself once you notice that there's a correlation between the second digit in 11, 12, 13 and h1, h2, h3. But I'm willing to bet the developer didn't see it right away and tried other ways before the "Aha!" moment arrived. It would be so nice to be a fly on the wall and watch those kinds of things evolve.

  • Wow, the amount of trouble people go to, to create something really complex from something really simple … truly a nice find Robert πŸ™‚

  • Niek Kouwenberg says:

    So if I'm correct, the value "Small" would result into a <code>h1</code>, whereas "Large" would result in—the much smaller—<code>h3</code>? Is this an error in your example code, or the actual behavior of the CMS?

  • Jonas MyrenÃ& says:

    Creativity takes interesting turns. Truly amusing.

  • Andreas says:

    Was going to point out same thing Niek did, that seems kind of strange? Part from that I think it was kinda cool.

  • Robert Nyman says:

    Yes, it's a very interesting example. πŸ™‚

    Niek,

    It's not a typo, that's the mixed solution they went for… πŸ™‚

  • <table>Chair!</table>

  • Richard Fink says:

      Your example reminds me of a problem I had to solve in the development of ZoomPerfect. (Also an IE-specific thing.)

      In dealing with older tag-soup pages, I found font-sizes being set using FONT tags, CSS, or – most problematically – a mixture of the two. So, in one module I had to convert – if it existed – the value of the SIZE attribute of any FONT tags into pixel values.

      While looking for a way of doing it, I discovered that IE's currentStyle.fontSize property would return "1" or "2" or "-1" or "+1", etc… for the FONT element and it's children. And if there was no SIZE attribute specified it would report the inherited default. Nicely, this meant I didn't have to check for the existence of the SIZE attribute at all.

      And it also allowed me to speed things up because – and here's where it gets weird – I could branch my code based, not on the value being reported (-1, +2, etc.) but only on the length of the string. If the length of the string is 1 or 2, it must be a FONT size. If it's greater than 2, it must be CSS because nothing less than a string with a length of 3 is legitimate and will be applied by the browser.(8px, 2em, 9pt, small, bigger, etc…)

      Once again, a perceptual thing that writes itself as long as you know that a valid font-size set via CSS can't be a string with less than a length of 3.

    Crazy problems demand crazy solutions, I guess. Whatever works.

  • mdmadph says:

    Ha! I think it's brilliant.

  • Robert Nyman says:

    Adrian,

    Yeah, that's the next natural step… πŸ™‚

    Richard,

    Oh, it's all about being pragmatic. πŸ™‚

    mdmadph,

    It is, isn't it? πŸ™‚

  • as spotted before, I miss the relation between "more semantic" and h1 as small font … what I mean, they could have done something like:

    14 % 13 (set CMS font size), then add h before it = [h1]Heading[/h1]

    so that Small, Medium, and Large would have been semantically correct as h3 for small, h2 for medium, and h1 for large.

    Summary: this was a quick and dirty hack without thinking at all? πŸ˜›

  • Robert Nyman says:

    Andrea,

    But that's the beauty of it, that's the correlation is messed up! πŸ™‚

    But yeah, it could have been solved more…

  • They missed a trick that would have allowed them to map 11 to h3, 12 to h2 and 13 to h1:

    <code>tagName = "h" + (((value – 10) ^ 3) + 1);</code>

    πŸ™‚

  • Robert Nyman says:

    Nick,

    Beautiful! πŸ™‚

  • Beautiful!

    I came across a nice one (not directly related to your post), when hired to fix a CMS:

    <table>

    <tr>

    <td align="center" class="h1">Header</td>

    </tr>

    </table>

    – to achieve center-justified headers (also with corresponding solutions for h2-h6).

  • Robert Nyman says:

    Michael,

    Oh, nice! I don't know how many heading classes I've seen over the years, but far too many, I can tell you that much…

  • Devon Young says:

    That's pretty slick. They kept it simple and compatible.

  • Robert Nyman says:

    Devon,

    Well… πŸ™‚

  • GUnnar says:

    Haha. Beutiful coding

    Looks like a thing I could have done.

    But I hope I would have inverted the order though..

  • Robert Nyman says:

    Gunnar,

    If I know you well enough, I think you would have fixed the order. πŸ™‚

Leave a Reply to Richard Fink Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.