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.

Not for the first time, I was happily authoring CSS and Dreamweaver CS3 crashed. Turns out, it doesn’t have to be specifically CSS, but that was my situation anyway.

The crash

It’s all too familiar: this is DW after all, and those of us who have used it from the start will know the pedigree. But I try to restart the program anyway: it’s 1am and I don’t need this. Nope, fail. Dreamweaver CS3 won’t start on Windows XP. In these times of quad processors and 32-bit colour, has the long-exorcised ghost of DW’s buggy past returned to haunt us?

The following options were available:

• Abuse someone at Adobe
• Reinstall Dreamweaver
• Try to clean out the config files so that Dreamweaver has to create new ones on restart (an old and occasionally successful solution)

And the answer? None of the above.

The fix turned out to be simple, though somewhat obscure. I shall elaborate in a moment, but first I must attribute my source. In August 2007, Adobe Community Expert and author David Powers sussed out this profoundly ugly problem in the Macromedia.Dreamweaver Google Group. At the time, it was undocumented elsewhere and not particularly easy to find with bland keywords in search engines.

The cause of the crash

Apparently, an install of Dreamweaver CS3 (mine is currently v9.0 Build 3481) crashes if you edit a file to exactly a multiple of 8,192 bytes. Not a byte more, not a byte less. The chances of this happening are probably fairly small: to edit a file to the exact size at the same moment that DW does some processing and gets upset.

Don’t believe me? I wouldn’t have either in your position. But here’s what happened: I’m editing a document of any supported format, I’m just about to change a particular value and suddenly it crashes. So I checked out David’s comment above and, lo and behold:

So now what?

If you have this bug, from here it’s quick and easy to escape. Don’t bother trying to do anything with Dreamweaver CS3 because as long as your file is a multiple of 8,192 bytes, you ain’t going nowhere.

Step 1. If you were working within a Site, you can test if this bug was behind the crash

If you were editing your file within a defined Site, read on. Otherwise, you can skip to 2.

In Windows Explorer, temporarily rename the folder that contains your Site, so that Dreamweaver CS3 starts successfully, asking you to Manage Sites… because of course it can’t find your original folder.

If you were to point Manage Sites… to the new folder name, Dreamweaver CS3 would crash again, so just exit the app for now. You can now be pretty sure you’ve encountered this filesize bug.

If DW doesn’t start properly after this step, then you have some other problem and I’m sorry your visit here didn’t help.

Step 2. Edit the file that caused the crash outside of Dreamweaver CS3

Next, in a different text editor such as Notepad, increase the filesize of the file that you were editing when DW crashed – just by adding a bit of whitespace, for example – and then resave it. You could also decrease the file size by deleting whitespace, but of course you risk repeating the bug when you work on the file again later or indeed, you might not have anything to safely delete, so I’d recommend increasing instead.

Now, having altered the file, be sure to check that your filesize is indeed no longer a multiple of 8,192kb.

If you were working within a Site as described in Step 1, you can now rename the folder of your Site back to its original name in Windows Explorer.

Restart Dreamweaver CS3 and you should be back in action. I hope it worked for you too!

Afterthought

As you can probably see, there are quite a few satisfied customers in the Responses below, from Denmark to Chile. So why not let me know if you had this problem too and if your situation was a little different, please add to the knowledge.

And finally, this incident jogged my memory of another oddball software behaviour I encountered once in the early days of Office 2007 for Windows, because it too was about processing bytes and coming out with the wrong result. Check out this anomaly with Excel 2007: if you multiply 850 by 77.1 you get 100,000. The real answer? 65,535 of course, a juicy, meaningful number for aficionados of binary computing! [15 April 2008: I tested this again recently and it appears to have been patched - Mike]

Microsoft applies accessibility best practice fairly solidly on the desktop, but the same couldn’t be said of its recent online efforts.

Redmond has often been seen to lag behind the rest of the online industry and resentments have built up over the years, particularly fuelled by the development of Internet Explorer.

So it’ll be welcome news from Microsoft that Sharepoint 2003 – a release pockmarked by deficiencies in both usability and accessibility – has been replaced by Microsoft Office SharePoint Server (MOSS) 2007, complete with numerous interface improvements.

However what we’re seeing are quick wins rather than big changes: some attention has been given to (easily altered) markup and the visual styles of out-of-the-box skins.

For better or for worse?

MOSS: hasn’t aged so well

The origins of Sharepoint’s critical accessibility issues – and these are still more or less the same in MOSS 2007 as they were in Sharepoint 2003 – lie in Microsoft’s dogged commitment to delivering the functional equivalent of WinForms in a browser.

The practical result is a sort of Frankenstein’s Monster of desktop and web paradigms, onerously dependent on client-side scripting to hold it all together.

Closer inspection of this scripting suggests that MOSS 2007 is in fact potentially less accessible than 2003.

An uphill slog

If we can do without bells and whistles on the front-end, it’s not especially difficult to publish a semantically valid, usable and accessible Sharepoint intranet.

It’s just that we have to customise to comply, to the extent that the cost-benefit of Sharepoint is much diminished by the considerable resources required to make it seaworthy.

Administrative concerns

Assuming we’re ready to receive visitors to our newly-compliant Sharepoint front-end, let’s turn to that Microsoft speciality: the delegation of administration. Here’s where the complexity of transferring WinForms literalism to the web starts to take its toll.

The technology required to leverage the power of the Sharepoint’s administration interface is also the heartbeat of the product, but some assistive technologies won’t support it. An assistive technology user can access a carefully modified website, but she won’t feasibly be able to administer it. Unless, it seems, we’re prepared to put our hand in our pocket again.

The cost of concessions: “More Accessible Mode” and the Accessibility Kit for Sharepoint

In his article on expected accessibility improvements for MOSS 2007, Microsoft’s Lawrence Liu envisaged a “‘more accessible’ mode that allows users with special needs to identify themselves so that we can change the way some of our dynamic content is rendered” (note the choice of the phrase “more accessible”, rather than plain “accessible”).

Indeed, now that we have the finished product, Liu’s follow-up remark is more accurate, with the ‘more accessible mode’ being made available “… so that third parties can create solutions catered to screen reader users”. The implication being that “more accessible” properly equates to “more development”: this mode still appears to depend upon at least some out-of-the-box client-side scripting to function properly.

A requirement for extra development in MOSS 2007 is honestly acknowledged by Microsoft, though Redmond obviously stops short of seeing that as a potential negative.

Some organisations have made the investment: there is a collection in the public domain today of websites (numbers still in single figures) that have been created to meet accessible standards. And it’s clear that in these examples, MOSS 2007′s rich functionality is missing. Nor can we guess whether or not these examples are capable of being administered accessibly.

As the respected creator of accessibility test engine CynthiaSays, provider and vendor HiSoftware has partnered with Microsoft to develop an Accessibility Kit for Sharepoint (AKS), which will target MOSS 2007. AKS will “deliver a kit that can significantly reduce the time, knowledge, and effort required to implement a Sharepoint-based web site”, say Microsoft and HiSoftware in a joint statement.

There are at the time of writing no published release dates.

While-U-Wait: Master Pages, User Controls and Web Parts

In the meantime, general experience of .NET development has already raised the issue of how to guarantee good markup from programming, a task that has become slightly easier since the release of .NET 2.0.

Developers must first produce accessible, valid Master pages. Rather than out-of-the-box Master pages, this process should start with a minimal template, such as an example made available by Microsoft.

Thereafter the quality of markup output by .NET 2.0 user controls can be improved upon quite significantly using delegate controls or CSS-Friendly Control Adapters.

Unlike many of the widgets and plugins of other, comparable products, MOSS 2007′s own Web Parts are rarely configurable (presumably because of their proprietary nature), which contributes to the issue of accessibility, since these same Web Parts typically spit out execrable markup.

Most such Web Parts exhibit one or more of the following issues:

• HTML tables for layout, or improperly marked up for data
• Obtrusive Javascript that fails to provide alternatives
• Inline styles rather than applying external CSS by class or ID
• Multiple instances of ID attributes instead of unique IDs
• Fixed rather than relative units

Accordingly, it is essential that simple semantic markup is used in order to achieve maximum flexibility and optimal accessibility, otherwise all the hard work done on fine-tuning the Master and other user controls will be compromised.

Conclusion: fit for purpose?

Web-based groupware promises much for the future: information architecture, findability, collaboration and a single point of origin for access, audit and workflow.

The debate on how far Sharepoint achieves the definition is open. At the time of writing (October 2007) the Intranet Benchmarking Forum published a report on the suitability of Sharepoint for an organisation intranet and its findings were mixed, while earlier in the year respected analyst CMSWatch considered MOSS 2007 inappropriate for web publishing scenarios.

Whether or not Sharepoint does the job in a general sense, organisations for whom a high level of accessibility is important (in an ideal world, that would be all organisations) should be concerned about MOSS 2007.

Organisations looking to develop an accessible MOSS 2007 solution for both visitors and administrators will need to make significant investment in development and to accept the probable loss of much of Sharepoint’s richer functionality.

If Microsoft Office integration (or lock-in, depending on the reader’s interpretation) isn’t a key deliverable, then consideration could be given to a content management platform with a lighter footprint that wraps in a high level of accessibility as standard and offers plenty of flexibility at the front-end.

The old RouteOne website

A new website for RouteOne, the leading publication in the Coach and Bus industry, is set to go live shortly.

My job was to turn the old offering – primarily a storefront for new registrations – into an accessible, readable editorial site to reflect the investment in design.

RouteOne was a great opportunity for me to follow up on my recent interest in the area of editorial design and I did a lot of research into what works.

The business of designing for a readership turned out to be a process of experimenting with subtlety, since content and continuity are the most important factors in getting the site to sit well with users. I think we’ve certainly achieved this, based on the results of the testing I did.

The new RouteOne website homepage

As ever, the site is put together with a CSS-based layout and on this project, a full stylesheet was devoted to the provision of the numerous editorial styles that should make RouteOne distinctive and highly readable.

I really enjoyed working on the new site, my first under the banner of our new business. I look forward to the desired results being achieved!

The Memorabilia show features appearances from actors and actresses, sports personalities and stalls selling collectibles from film and television. There’s often a particular bias on sci-fi.

Past guest appearances have included Verne Troyer (Mini-me of Austin Powers fame), Anthony Daniels (C-3PO) and Bond-girl Britt Ekland.

The new site sports a broader, more attractive layout in keeping with the direction in which the event organisers Expo Management are pushing.

Check it out at http://www.memorabilia.co.uk!

I had written a brief article before MikePadgett.com was so kindly hacked about the work I’d done on templates.

In common with most blog software, the idea is to separate content from presentation, so it’s just a matter of writing decent CSS.

Here are the two previous ‘skins’ that have graced these pages:

Japon – the first blog style I used in 2005

Woollen – a Norwegian sweater to keep the blog warm for winter

If anyone would like some help with their templates, let me know.

Getting this problem?

Example:

<div style="background: red; padding: 2%; border: 1px solid #000;">
<div style="border: 1px solid #000000; background: #e2e2e2; float: left; width: 45%;">Left<br />Left<br />Left<br />Left</div>
<div style="border: 1px solid #000000; background: #e2e2e2; float: right; width: 45%;">Right<br />Right<br />Right<br /></div>
</div>

There are generally two ways of dealing with this and you shouldn’t usually need to hack it.

Hack-free approach

Normally, you can apply something like the following to the outer div:

height: 1%; overflow: hidden;

In most modern browsers, the container will now stretch to fit the floated contents.

<div style="background: red; padding: 2%; border: 1px solid #000; height: 1%; overflow: hidden;">
<div style="border: 1px solid #000000; background: #e2e2e2; float: left; width: 45%;">Left<br />Left<br />Left<br />Left</div>
<div style="border: 1px solid #000000; background: #e2e2e2; float: right; width: 45%;">Right<br />Right<br />Right<br /></div>
</div>

PIE clearfix hack

In some circumstances, especially when support for ancient browsers is required, there’s also a generally trouble-free hack.

PIE Clearfix works like this:

.clearfix:after {content: "."; display: block; height: 0; clear: both; visibility: hidden;}
.clearfix {display: inline-block;}
/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */

Now simply add:

class="clearfix"

… to the outer div or apply it to the actual elements/classes you’ve already written.

I wrote this short article because it took me a painfully long time to find the original PIE article. The reason being that searching for this particular CSS problem with keywords is difficult: how do you describe it? I’ve seen “nested div float problems”, “clearing nested floats” and simply “container div won’t float” and all of these mean the same thing!

J recently pointed out to me a website she’s been looking at called Heavy Backpack. It’s billed by its makers as a “Creative Catalogue” – in other words a mini portfolio for each of its contributors and there are some outstanding examples of graphic design in there with the usual derivative stuff.

Heavy Backpack

But the site itself is what interested me first. It looks attractive, along similar lines as K10K or any number of those horrible awards sites that all present us with a cutting edge mostly made out of Flash.

Now, of course I realise that the right way to do this kind of magazine (or catalogue or whatever) site is to mute your design so as to let the content do the talking, but being a person interested in the details, I couldn’t help but notice as the site slowly loaded that there were so many images on the page.

My interest was piqued and I dived right into the source code to see what efforts had been made.

Few. 27 validation errors in HTML 4.01 Loose. A cherry pick of the accessibility issues includes those perennial favourites tiny type, iframes and almost no alt attributes.

The team that put Heavy Backpack together is Wade Studios, an Australian business with a good client list. Very talented graphic designers, clearly, but as web designers they ain’t.

In the last year, I have become increasingly convinced that to call yourself a web designer today means that you are a proficient XHTML/CSS coder, a standards evangelist and well-versed in usability and accessibility best practices. So says Zeldman, so says O’Shea and all that lot, so says Nielsen, and so say I. A graphic designer is not a web designer.

Quote:

“Too many graphic designers have tried to force the Web to be what it is not, in the process creating ineffective and sometimes unusable websites. Quality web design is driven by information architecture design principles. Graphic design should support these principles.” – Gerry McGovern

Graphic design houses ignored the Internet. It was low culture for a long time and there was no money in it. But today, interactive projects can rival those in other media in scale and value and now these same graphic design houses are selling their web capabilities where they can’t get through the door on the back of print alone.

But in truth, the fuddy old Art Directors don’t understand websites. Just as some design houses tried to stay aloof when DTP was adopted by all walks of employee (even though the product was crap, it was certainly cheap) they also missed the boat with the Internet.

Hence why the code is neanderthal, or worse, art program-generated.

Hence also why it’s pretty but without practicality.

[See also: Design Choices Can Cripple A Website by Nick Usborne, 08/11/2005 A List Apart]

I recently discovered a CSS hack that has come in very handy indeed since.

The problem arises in both Firefox and IE (though the solution is different for each) when we try to wrap a div around one or more divs with float.

You want your wrapper to stretch vertically with your contained divs, but instead, you find that your wrapper gets behind when your floated content divs go stretching off down the viewport and beyond.

The development community is all but silent on this issue, though I would think it’s a common enough problem to have encountered.

I tried and tested an IE solution, but it was thanks to Big John and Holly at positioniseverything that the NS / Firefox side of things could be cleared up. The full article with the whys and wherefores is here, and the code we need is as follows:

.clearfix:after {content: "."; display: block; height: 0; clear: both; visibility: hidden;}
.clearfix {display: inline-table;}
/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */


Now we get the result we want!