CSS best practice : bold and italics

CSS is a marvel. Separation of content and layout is almost a life-saver.

But somehow, somewhere along the line, a big bunch of programmers have gone overboard into CSS stupidity.

Consider blogger.com. They shun the <em> and <strong> tags in favour of <span> tags with inline CSS.

Yes, it's true that in the bad ol' days, programmers used the <strong> and <em> tags to mark headers, and yes it's true that that should stop (and should have stopped some years ago). If you're making a header, use a header tag, and use CSS (not <strong> and <em> tags) to define the visual appearance of your header.

But <strong> and <em> have a proper use as content-bearing tags. The use of bold and italics is as intrinsic to the writing process as the use of all-caps was before bold and italics came on the scene. The <strong> and <em> tags, correctly used, are not formatting tags. They are content tags.

Now here's where things get really interesting. Suppose you want to quote someone, and you want the quote to appear italicized, but suppose the quote already contains italics. Doing things my (sane) way, no problem. Doing things Blogger's way, and you are stuck down the creek without a paddle.

e.g. suppose I'm building a sales site for XYZ company, and they have a few customer testimonials in the righthand sidebar.

Here's fictitious testimonial #1 :

"You guys are awesome! Your product has changed my life!"

Now, let's do this the proper CSS way, and create a class named "Testimonial".

<span class='Testimonial'>"You guys are <em>awesome</em>! Your product has changed my life!"</span>

Obviously, we define the Testimonial class in our CSS file as follows :

span.Testimonial
{
font-style:italic;
}

All well and good, until someone notices that there is no difference now between the word "awesome" and the other words. Everything's italicized. What to do? Ah! Simple solution! CSS to the rescue! Add another definition to the CSS file :

span.Testimonial i
{
font-style:normal;
}

Voila! We have now preserved the "content" embodied in the <em> tag. Remember, <em> doesn't so much mean "make this italic" as much as it means "emphasize this". With the simple CSS given above, we have retained the emphasis of the enclosed <em> tag, by actually making it non-italicized.

In contrast, here's what Blogger does when you italicize some text :

"You guys are <span style="font-style:italic;">awesome</span>! Your product has changed my life!"

Can you see the problem? We can wrap it in our Testimonial span :

<span class='Testimonial'>"You guys are <span style="font-style:italic;">awesome</span>! Your product has changed my life!"</span>

... but we have completely lost a piece of content - being the emphasis on the word "awesome".

Now you might think you're really clever and point out that you could always make a CSS definition like this :

span.Testimonial span
{
font-style:normal;
}

... but if you'd given it a few moments more thought, you would have realized that this only works if you limit content to one type of emphasis only. Suppose a different testimonial used bold instead of italics, and still another used both bold and italics. Bummer. You're done for.

In short? <strong> and <em> are content-bearing tags. Sure - they've been misused and abused as formatting tags (e.g. where header tags should have been used instead), but the misuse doesn't change the fact that there is and always will be a very vital content-bearing role that these tags must carry. Many programmers think they're oh-so-clever and oh-so-standards-aware and oh-so-CSS-knowledgeable by replacing <strong> and <em> tags with <span>s that have inline styles, but in the process they are actually violating the very intention of CSS - they are replacing a content-bearing tag with what (in the way they use it) is actually a formatting element! Separation of content and formatting demands that ONLY <strong> and <em> tags be used to accomplish emboldening and italicization in the flow of content. Replacing them with spans that have inline styles might make you feel clever, but it violates the coremost principles of CSS. And it makes your pages bigger.

So there. :o)

Tune in next week for another episode of "CSS Bloopers" - the exciting program where your coding practices are mercilessly ripped to shreds. :o)

When ASP.NET support isn't ASP.NET support

1and1.com offer cheap hosting deals and I was quick to sign up. I needed ASP.NET hosting and they fit the bill. Or so I thought.

Some of my ASP.NET apps sit atop Microsoft Access databases. (Scream and holler all you like, but there are good reasons in the cases it is so.) 1and1 sales material says their Microsoft hosting accounts support ASP.NET, SQL Server, Access, etc, etc. All fine and dandy, right?

What they didn't tell me in advance (or else I would have gone elsewhere) is that Access support is only available for old-style ASP. That's right : if you have an ASP.NET app, it cannot use Access. It has to use SQL Server. That might not sound so bad, but if you signed up expecting otherwise (and reasonably so on the basis of their sales material), you'd be in for a shock.

I bought a "professional" hosting package, which comes with 5 sites, etc, etc. But it only allows one SQL Server database, with a size cap of 100MB. So switching certain apps over to SQL Server wasn't the answer either.

And finally, I just discovered today that they don't support setting up your 5 sites as separate ASP.NET web applications! Crikey! They could at least have told me this at the start. In other words, you can have one web app with five domain names pointing at it, but you can't have five discrete web apps. So much for their "professional" package.

So if you have only a single site and a 100MB SQL Server database is more than enough, get one of the low-end 1and1.com packages. Or if you need a zillion sites, maybe one of their uber-high-end packages will do the trick, but this so-called "Professional" package stinks. It looks good on paper, but 1and1.com have severely limited it's usefulness, and without adequate pre-sale disclosure.

So, when you're going for cheap ASP.NET hosting, whether 1and1.com or elsewhere, and you have a handful of sites you want to host (e.g. in my case, a business site, a blog, and a freebie language-education website on the side), then beware you don't get suckered in to this same trap.

I hope this saves someone else the frustration and wasted time I've had to go through. That's all folks. Tune in next week for another episode of "And They Told Us Computers Would Make Life Easier...". :o)

Set Arbitrary Text To The Clipboard Using Javascript

You want to set a value to the clipboard, using javascript in a browser window.

And it needs to work in Internet Explorer and in Mozilla/FireFox.

You'd think it would be simple. It is, after all, the 21st century.

Think again.

The nearest to simple is a script by Krikkit. The very very short of it is that after over three hours of wasted time, I have a much simplified version of the script. Kudos to Krikkit for getting the script to the point he did - without it, I would have gotten nowhere. But this version is definitely superior because a) the comments are in English not Dutch :o) and b) it is very roughly only half the lines ('coz I found an alternative and much simpler way to accomplish the same thing).

So here's the code. It works in Internet Explorer and Mozilla/FireFox. Sorry - no Opera and I don't know about Safari.

function CopyStringToClipboard(s)
{
  if (window.clipboardData)
  {
    /* Internet Explorer does things this way */
    window.clipboardData.setData("Text", s);
  }
  else if (window.netscape)
  {

    try {
      netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
    } catch (ex) {window.alert("Mozilla is not configured to allow this script to set the clipboard data.");return;}

    var ClipboardHelper = Components.classes["@mozilla.org/widget/clipboardhelper;1"].getService(Components.interfaces.nsIClipboardHelper);
    ClipboardHelper.copyString(s);

  }
}

However, life ain't quite that simple. FireFox will refuse to allow clipboard access (even just the humble lowly setting of clipboard data) unless the user makes a config change. Argh! That's ok-ish for techies like me who are making an app for internal use (as is the case right now), but if you're doing it for wider distribution...

Anyhows, the folks at Febooti have done a wonderful job of explaining exactly which setting needs to be changed and how.

Credits :

Krikkit's version - comments are in Dutch and it's much more complicated than necessary, but bravo, it does the job, and that's the main thing that matters, so definitely kudos in that direction

The broken Dutch version but with the comments having been translated from Dutch into English - and that's where I got the English comments I've used in my version, except that it also wasted me a slab of time because for no apparent reason, this version added square brackets around some numbers in the javascript, which caused it to not work, and it took a while to figure out what on earth was happening... Nonetheless, kudos for speaking both Dutch and English, or at very least, for taking initiative to pump the comments through an automated translator. :o)

... and thanks to the Mozilla Developer Centre where I finally found a much simpler way to accomplish the same thing. (But I still credit the Dutch version for part of the solution 'coz without it, I would never have known about that obscure "UniversalXPConnect" setting.)

That's all folks! Tune in next week for another episode of "And they told us computers would save time...". :o)