The “unknown runtime error” was at one time a common problem when working with innerHTML in Internet Explorer as for some elements it’s a read-only property. Needless to say, I was a bit surprised to see it this time, especially since I couldn’t spot anything out of the ordinary.

Then I suddenly realised that the source of the problem was probably the dynamically-created HTML5 figure element into which I was asking Highcharts to insert my chart. Rather than mess about with the Highcharts library and a homegrown workaround du jour, I decided to go with a simple div.

As with everything Microsoft, given time things will work out. Updated figure documentation from Microsoft and Caniuse.com confirm that support for HTML5 semantic elements (and therefore read/write innerHTML) should be available in IE9.

This is only a problem, so far as I can see, when you’re using backgrounds on the unfloated element(s), because thr background image or colour will overrun your floated element.

Want to try it? The situation is as follows:

1. Float an element containing either an image or text
2. Continue with unfloated elements so that under normal circumstances they wrap around the floated element
3. Give the wrapped text a background property, such as a background colour or image

The code so far:

/* CSS */
.floated {float: right;}
p {background: #fc0;}
...
<!-- HTML -->
<div class="floated"><img src="/images/tmp.jpg" /></div>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit</p>
<p>Class aptent taciti sociosqu ad litora torquent per conubia nostra per inceptos himenaeos</p>

Up to this point everything’s normal:

So far so good. Now add font-style:italic; to the rule for p.

Here’s Firefox, with no surprises:

But here’s Internet Explorer 7:

The only (il)logical answer seems to be the addition of overflow: auto to the rule with the background.

I was clued in by a slightly different issue with the same fix already discovered long ago. Just to remind you once more, this is IE7 only, folks!

Source: Wikimedia Commons

The virtues of @media print have been explained elsewhere, best of all by Eric Meyer in his seminal A List Apart article Going to Print, whose original publish date (May 2002) makes me feel a bit old!

Yet one of the most annoying aspects of developing CSS for print is testing it.

Now I know that testing print CSS doesn’t take a huge slice of our lives, but it annoys the heck out of me. So if you’re a tolerant sort of person who’s happy to rub along with naff workflows, you might find this article and indeed the fact that there’s a whole article on the subject, just a bit finicky.

Thing is, I hate testing print CSS.

Sure, simple markup and layouts only need buffing to a shine to be ready for print, but an increase in complexity or a requirement for absolute fidelity in printed material can lead to ugly scenes round my way.

Print CSS: browser testing !== Print Preview testing

Developers tend temporarily to substitute their screen CSS for their print CSS, run it in the ordinary browser environment, et voilà. Rinse and repeat.

Yet the actual conversion to the printed page can sometimes lead to unexpected results, as can be seen in the image: different browsers, different Print Preview results – even though in the browser there was nothing obviously objectionable.

Print Preview !== a tool for development

Finding fiddly print CSS issues would be a lot easier if testing tweaks was a smoother process. Every change cycle equates to:

1. Refresh the page
2. Invoke Print Preview
3. Review the change
4. Close Print Preview

Testing print CSS as opposed screen CSS appends two additional steps 2 and 4 – invoke Print Preview (Alt + F + V in Windows for both IE and Firefox) and close Print Preview (correspondingly Alt + F4) . Those two simple steps make the business very laborious, even if you can remember those shortcuts.

Slight workflow improvement: an IE-only trick

A dirty little script in IE only takes care of the task of invoking Print Preview, which slightly shortens the workflow. Yes, it’s IE only, but given that it’s usually IE giving me print CSS grief, every little helps:

<script type="text/javascript">
function printpr()
{
var OLECMDID = 7;
var PROMPT = 1;
var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';
document.body.insertAdjacentHTML('beforeEnd', WebBrowser);
WebBrowser1.ExecWB(OLECMDID, PROMPT);
WebBrowser1.outerHTML = "";
}
printpr();
</script>

This script automatically invokes IE’s Print Preview. Dump it just before the </body> and save yourself a shortcut! You could also call printpr() from anywhere else, of course. And here’s the source of the original code snippet, which also shows a few other unrelated options such as Save As.

Why can’t we refresh the Print Preview?

All of which finally begs the question, why can’t we simply refresh the Print Preview with an F5 shortcut, just like we have in the browser itself?

Probably because I’m the only person in the world who gets genuinely annoyed by testing print CSS in Print Preview. More fool me, I guess.

Proper font embedding in a browser is long overdue. We’ve had to put up with the same old Arial, Verdana, Georgia, Helvetica, Times New Roman for years.

Now that browsers have to some extent caught up with the rest of us, thanks in no small part to a bit of healthy competition, Typekit has finally answered the call: you’ll soon be able to choose what fonts drive your website.

Everyone’s favourite glue

We’ve had sIFR, we’ve had MIR and we’ve had RIR. We’ve probably had enough.

None of these solutions proved to be ideal, but how often is anything ever ideal on the client side?

Well, let’s take a look at Typekit. At the time of writing, there isn’t too much to go on, but what we do know is this:

1. Typekit’s solution uses (quite a lot of) Javascript
2. The solution ‘downloads’ a font feed from a predetermined location
3. A ‘modern’ browser will interpret CSS @font-face correctly and render the desired fonts

So Typekit is merely following in the footsteps of jQuery, Prototype and other JS libraries. It’s about using Javascript as a sort of web glue to make things fit together. However, this time around it’s not being used to cover up for browser naffness.

Typekit will count on consistent support of modern browsers for the @font-face at-rule. This at-rule has actually been around since the CSS 2.0 specification, though a better, verbose description appears in CSS 3.0. An orthodox implementation of the at-rule looks like this:

@font-face {
font-family: "Mike Old Face";
src: url("http://www.mikepadgett.com/fonts/mikefont.otf")
}
/* The .TTF (true type format) will also be supported, as would *any* URL */


Once the font is “instantiated”, it can then be utilised (in Hemingway’s Fiesta sense of the word) normally:

h3 {
font: normal 120% "Mike Old Face", "Times New Roman", Times, serif;
}

Browser support for @font-face is still a bit patchy but things are picking up fast and now the browser people have discovered the joy of automatic updating, we can expect a fairly rapid uptake.

On the bright side, it’ll mean that designers can make more beautiful websites. The dark side is that many other websites are going to get a lot uglier!

But glue can get sticky

Microsoft tried and failed to get their Embedded Open Type solution accepted by the world at large (there wasn’t much of anything ‘open’ about it, of course). Redmond ended up handing it over the W3C as a feeble proposal for CSS 3.0.

One of the itchier reasons for all the fumbling was the issue of proprietary rights to the fonts themselves. This same issue may well cause problems for Typekit, though this time in the reverse sense.

You see, whilst the Typekit solution is likely to appease and perhaps even create uncharacteristic interest from type foundries (it appears to properly respect intellectual property rights), it might not sit well with many designers and even less with developers.

Here’s why:

The story goes that the Typekit script is going to be pretty hefty. It needs to be to do all the processing it would need to do and how long is that going to take? In addition, the font pattern will then also need to be downloaded (some fonts are marvellously chunky themselves).

Next, the matter of the rights. One of the first things I learned about business is that the real value is in contracts rather than sales, especially when you’re selling other people’s products. So it goes without saying that Typekit needs to be a subscription service.

On the one hand, some orgs would sell their chairman to properly and faithfully reproduce their branding online. How on the other, as one commenter suggested, do you now square it with your client that your design will actually attract an ongoing cost? Could this be another opportunity for Open Source or are the foundries on the edge of the precipice into which the music industry has already fallen?

It was published only a couple of years ago (a long time in Web world, of course) and it’s interesting to trace the arc of developments since then.

Whilst much of the methodology described in the book is becoming increasingly normal nowadays, I certainly wasn’t aware of the scale of Zeldman’s achievements with regard to ending the so-called Browser Wars with the Web Standards Project until now.

Web standards implementation as a strategy has exploded into the forefront of my job, so it is now important to put together a strong business case in order to get buy-in from developers and management. It is no longer enough, it seems, to encourage topical best practice from colleagues.

For many people I’m dealing with, the understanding of (X)HTML standards seems to be quite practical – “table avoidance” is one of the most visible concerns and, as Zeldman also points out, the problem of automatically generated code from content management applications.

Time will tell how far I can take it, especially for internal systems, but it looks set to be a pretty lonely path for now!