meyerweb.com

As noted on the WaSP site, the IE team is asking developers to clean up their CSS hacks because they’re causing sites to break in IE7 builds.

I have to admit that this call elicited an arid little chuckle from me, because it’s a case of chickens coming home to more than one roost. There’s the fact that bugs in older versions of IE led us to use hacks, and so they’re making life harder for the IE team. And then there’s the fact that the use of hacks is an inherently risky and fragile process, so the release of IE7 will make life harder for those who used them. No smug self-superiority should be read into that second point, by the way: I quite firmly include myself in that crowd.

So—now what? Personally, I’m not going to make a move until an IE7 beta with new CSS behavior is released. Why change hacks just to have to hack more? Put another way, if the ground is going to start shifting, there isn’t much sense in trying to guess how. Wait until it does, and then adjust your footing.

Still, it might pay to consider ways to cope once the ground shifts. This leads to something I’ve been pondering for a bit, and now’s a good time to bring it up. When IE7 (the browser) comes out, it will make IE7 (the script) even more useful than it is now.

Here’s why: all the stuff that IE7 (the script) does, IE7 (the browser) is supposed to do as well. That is to say, the script can bring IE6 up to par with IE7 the day IE7 is released. See where I’m headed with this? Instead of being chained to the fat tail of IE6 installs while being unable to use parser hacks in IE7, we can clear away the hacks and have IE6 and IE7 act basically the same.

They will of course not act exactly the same, and yes, there are drawbacks. IE6 users will have to download the extra script, and those with JavaScript disabled will have problems. Not every site will be able to accept those costs—but I’d wager the vast majority will.

In the main, it will be a lot less painful to clear out the hacks with IE7 (the script) available than without it. A lot.

Oh, and before people start exhorting the use of conditional comments instead, it’s still too soon to know how good an idea that might be. Doubtless they’ll come into play, but exactly how is completely unpredictable until we know what IE7 actually does. Perhaps we’ll start using conditionals around the call to IE7 (the script). Perhaps not. Time will tell.

As I said before, it’s too soon to know which hacks to clear away or how to rework our code, but thanks to Dean Edwards’ efforts, I’m feeling a distinct lack of stress over the impending shifts.

Okay, ALA fans, we’ve deployed a print style sheet on the articles. I don’t know if I could call it done, but it’s a big step. Why wasn’t it online sooner? Say it with me: “browser bugs”. Just when the convergence of screen CSS handling had me feeling good, I had to go and mess with print styling. Good feeling’s gone.

At the moment, the print styles seem to work quite well in modern browsers except for Firefox 1.0.6 (which is what I have in OS X). There, when I call up a print preview, any article is fine until page 4. Then things go off the rails in short order. Content disappears, margins go wild, all kinds of fun stuff. Here, try previewing or printing Nick Usborne’s “Helping Your Visitors: a State of Mind. Now try it with J. David Eisenberg’s “Validating a Custom DTD” or (somewhat ironically) Ross Howard’s “High-Resolution Image Printing“. Pages 1-3 are fine for me, but after that, no good. When you get a nice long article like Joe Clark’s “Facts and Opinion About PDF Accessibility” or (completely ironically) my own “Going To Print“, you’re just asking for trouble.

I tried searching Bugzilla for some report, but my skills over there are not what once they were. So while I got a bunch of results, I don’t know if any of them described this problem. Could some kind soul let me know if there is a report on this sort of thing already? If not, I can submit the report. I just don’t want to add yet another DUPLICATE to the database.

And hey, if you can work out a solution to the problem, I have a factory-fresh ALA T-shirt all ready to send out—you even get to choose which one you want. Let me know.

Update: Dan Wilkinson is our winnah!

As a followup to my entry about id="tags" causing problems in IE/Win, here are four five test pages for IE/Win:

• IE Keyword Testing (length)
• IE Keyword Testing (item)
• IE Keyword Testing (namedItem)
• IE Keyword Testing (tags)
• IE Keyword Testing (urns)

These are based on Kevin Hamilton’s observation that it’s highly likely the problems are caused by the tags method in IE/Win’s document.all DOM interface. As he says:

[I]f you have an element with an id=”tags”, then document.all.tags is now a reference to that element, and no longer a method of the document.all object.

Such states would completely shatter any IE DOM scripting that relied on the document.all methods, and at least in the case of tags causes problems like crashing on print (probably because of the aforementioned conflict between the ID value and the DOM method). The other keywords of concern are chronicled in the test pages listed above. I’d test IE/Win myself, except I don’t have a printer handy for IE/Win to use, and besides, bug-hunting is best conducted in large groups.

Basically, load up each test page in IE/Win and do anything you can think to do. Try to print, view source, save a local copy, et cetera, et cetera—the more obscure and offbeat, the better. Let us know via the comments any problems you run into with said pages (trying to print them is a good first step, since that’s what messed up on tags) and I’ll add notes to each page based on what’s found.

In the meantime, I’m personally going to avoid using any of those words as ID values, and heartily recommend the same to you.

Update: I’ve added a test (for length) to the above list, and have another that’s not on the list due to its unfinished nature. It’s a test of id="all"; the problem is, I don’t really know how to test it, or if it’s likely to be a problem at all. Suggestions are welcomed in the comments. I added some JavaScript links to some of the test pages as a secondary test, but I’m not sure how much good they do, to be honest. As with suggestions, your feedback is welcome.

For those in search of more background, or trying to find new ways to test possible conflicts, or whatever, feel free to look over Microsoft’s documentation of the “all Collection”.

Here’s a fascinating little tidbit: on some users’ machines, attempts to print out Joe Clark‘s ALA article “Facts and Opinions About PDF Accessibility” would crash Internet Explorer. The error message mentioned a script error in line 1401: “Object doesn’t support this property or method”. Funny thing: we weren’t doing any scripting. The error was actually occurring shdoclc.dll/preview.dlg, which is of course a piece of the operating system.

Jason did some sleuthing and traced the crash to this line of markup:

<h2 id="tags">Tags and structure</h2>

Honestly, that was it. So Jeffrey renamed the ID to read:

<h2 id="structure">Tags and structure</h2>

So far as we know, no more crashing in Explorer.

Ain’t browsers a slice?

(And yes, we’re aware of the clamor for a print style sheet. More on this later.)

Update: Marten Veldthuis from Strongpsace points out that 37signals ran into a very similar problem in Backpack. Details can be found in Jamis Buck‘s June 3rd post ie-is-teh-3v1l. Spread the word: “tags” is effectively a reserved keyword, even though no such concept exists in (X)HTML. Use it at your (users’) peril.

One of the first rules of life is that first-hand information is always better than second-hand information. You can be more certain of something if you’ve seen it with your own eyes. Anything else is hearsay, rumor, conjecture—an article of faith, if you will. At the very minimum, you have to have faith that your source is reliable. The problems begin when sources aren’t reliable.

No, this isn’t a rant about the intelligence screw-ups previous to the invasion of Iraq. Instead, it’s a warning that inspector programs and saving as “Web page, complete” features can lead you astray.

One such example came up recently, shortly after I mentioned the launch of the new Technorati design. A question came in:

I did want to ask about the use of -x-background-{x,y}-position as opposed to background-position. If I understand correctly, the -x prefix indicates an experimental CSS attribute, so in what circumstances should one use this sort of experimental attribute instead of an official one?

I’d have been glad to answer the question, if only I’d known what the heck he was talking about. Those certainly weren’t properties I’d added to the style sheets. They weren’t even properties I’d ever heard of, proprietary or otherwise.

Just to be sure, I loaded the CSS files found on the Technorati site into my browser and searched them for the reported properties. No results. I inquired as to where the reporter had seen them, and it turned out they were showing up in Firefox’s DOM Inspector.

Now, the DOM Inspector is an incredibly useful tool. You can use it to look at the document tree after scripts have run and dynamically added content. You can get the absolute (that is, root-relative) X and Y coordinates of the top left corner of every element, as well as its computed dimensions in pixels. You can see the CSS rules that apply to a given element… not just the everyday CSS properties, but the stuff that the Gecko engine maintains internally.

That’s where the problem had come in. The DOM Inspector was showing special property names, splitting the background-position values into two different pseudo-properties, and not showing the actual background-position declaration. This, to me, is a flaw in the Inspector. It should do two things differently:

1. It should show the declaration found in the style sheet. There should be a line that shows background-position and bottom left (or whatever), because that’s what the style sheet contains.
2. It should present the internally-computed information differently than the stuff actually taken from the style sheet. One possibility would be to show any internal property/value pair as gray italicized text. I’d also like an option to suppress display of the internal information, so that all I see is what the style sheet contains.

The person who asked why I was using those properties wasn’t stupid. He was just unaware that his tool was giving him a distorted picture of the style sheet’s contents.

Don’t think Firefox is the only culprit in unreliable reporting, though. Anyone who uses Internet Explorer’s save as “Web page, complete” feature to create a local copy for testing purposes isn’t getting an actual copy. Instead of receiving local mirrors of the files found on the Web server, they’re getting a dump from the browser’s internals. So an external style sheet will actually be what the browser computed, not what the author wrote. For example, this:

body {margin: 0; padding: 0;
  background: white url(bodybg.gif) 0 0 no-repeat; color: black;
  font: small Verdana, Arial, sans-serif;}

…becomes this:

BODY {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px;
BACKGROUND: url(bodybg.gif) white no-repeat 0px 0px;
PADDING-BOTTOM: 0px; MARGIN: 0px; FONT: small Verdana, Arial, sans-serif;
COLOR: black; PADDING-TOP: 0px
}

Okay, so it destroys the authoring style, but it isn’t like it actually breaks anything, right? Wrong. For some reason, despite IE treating the universal selector correctly, any rule that employs a universal selector will lose the universal selector when it’s saved as “Web page, complete”. Thus, this:

#sidebar {margin: 0 74% 3em 35px; padding: 0;}
#sidebar * {margin: 0; padding: 0;}

…becomes this:

#sidebar {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px;
MARGIN: 0px 74% 3em 35px; PADDING-TOP: 0px
}
#sidebar  {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px;
MARGIN: 0px; PADDING-TOP: 0px
}

Oops. Not only can this mean the local copy renders very differently as compared to the “live” version, it’s also very confusing for anyone who’s saved the page in order to learn from it. Why in the world would anyone write two rules in a row with the same selector? Answer: nobody would. Your tool simply fooled you into thinking that someone did.

Incidentally, if you want to see the IE-mangled examples I showed in a real live set of files on your hard drive, go save as “Web page, complete” the home page of Complex Spiral Consulting using IE/Win. And from now on, I’ll always put “Web page, complete” in quotes because it’s an inaccurate label. It should really say that IE will save as “Web page, mutated”.

So if you’re Inspecting a page, or viewing a saved copy, remember this: nothing beats seeing the original, actual source with your own eyes. If you see something odd in your local copy, your first step should be to go to the original source and make sure the oddness is really there, and not an artifact of your tools.

With the debut of the WSP‘s ATF, a vigorous conversation has gotten underway. Joe Clark weighed in with some suggestions, Andy Clarke got some rousing comment action, and more have spoken up. This follows some recent and widely-cited thoughts from Matt May on WCAG 2.0 (with opposing view from Gez Lemon), and from Andy Clarke regarding accessibility and legislation (which inspired the publication of a different view from Andy Budd, not to mention another from Chris Kaminski). I’ll join the chorus with some points of my own. (Apparently, my recent post Liberal vs. Conservative was taken as a contribution to the discussion, which it wasn’t meant to be, although the points raised there are definitely worth considering in this context.)

This past May, I delivered a keynote at the 2nd International Cross-Disciplinary Workshop on Web Accessibility in Tokyo, and one of the major points I made was basically this: “Screen readers are broken as designed, and need to become speaking browsers”.

The problem is that screen readers are just that: they read what’s displayed on the screen for a sighted user. In other words, they let Internet Explorer render the Web page, scrape the visual result, and read that. I will acknowledge that in the tables-and-spacers era of design, this made a certain amount of sense. That era is ending; in an important sense, it’s already over and we’re just cleaning up the mess it left. Which is not to say that table markup is never and should not presently be used for layout purposes, nor is this to say that such markup should be used. Okay?

What I’m saying is that screen readers need to become speaking browsers: they need to ignore how the page is visually displayed, and read the content. Use semantic markup when it exists, and otherwise ignore the markup in favor of the actual words, whether it’s plain text or alt text. Go from the beginning of the document to the end of the document, and ignore the CSS—at least that CSS which is meant for visual media, which these days is pretty much all of it.

You might wonder how a speaking browser should deal with a table-driven site, of which there are still quite a few, he said with some understatement. One distinct possibility is to do what I just said: ignore the non-semantic markup and read the content. I can accept that might fail in many cases, so I’ll present a fallback: DOCTYPE switching. If a document has a DOCTYPE that would put a visual browser into standards mode, then be a speaking browser. If not, then be a screen reader.

DOCTYPE switching has been, despite a few hiccups, incredibly successful in helping designers move toward standards, and allowing browsers to permit standards-based design without sacrificing every page that’s come before. The same, or at least a very similar, mechanism could help audible-Web tools.

The WaSP has done great things in their efforts to show vendors why Web design tools should produce standards-oriented markup and CSS. I sincerely hope they can produce similar results with audible-Web vendors.

There’s been some comment recently about how Ajax programming requires a different approach to UI and user notification. What Jeff Veen wrote about Designing for the Subtlety of Ajax, and Alex Bosworth‘s post on the top 10 Ajax Mistakes, are just two examples.

I pretty much agree with both pieces. I’ve missed upates more than once on Ajax pages, just because I’m too used to how pages usually work. I’ll click on something and then my attention will, out of habit, instantly go elsewhere—another window, another application, another computer, whatever—and keep subconscious track of what was happening in the window where I clicked, monitoring it in my peripheral vision for the flicker of a page reload. Eventually there will be a little tickle in the back of my brain that says, “Hey, didn’t that site ever do anything?” When I finally look straight at it, I realize that it did something quite a while ago, probably a split second after my mental focus moved away. Instead of being efficient, I was wasting time waiting for a refresh that never came.

One might think it’s time for an “Ajax enabled” badge on pages so we know “better pay attention, ’cause this ain’t your father’s Web page”. I don’t think that’s the way to go, however. I think what’s needed is a more mature HCI design sense. Web design has long relied on the page-update refresh to tell the user something has happened; this was such a part of the Web’s fabric that designing around it was almost unconscious. There hasn’t been a need for sophisticated HCI considerations… until now.

In other words, Web design is going to need to grow up, and become more HCI-oriented than it has been. The usability of a Web site will become as much about how you let the user know they’ve done something as it is about getting them to the thing they want to do. In addition to getting the page to look inviting and present the information well, it will be necessary to obsess over the small details, implement highlights and animations and pointers—not to wow the user, but to help them.

In this endeavor, it’s worth remembering that there is a very large and long-standing body of research on HCI. For years, many HCI experts have complained that the Web design field is making all sorts of errors that could be avoided if we’d just pay attention to what they’re telling us—a criticism which was not totally inaccurate. Some Web design experts shot back that the Web was a different medium than the sorts of things HCI people studied, and anyway, the Web was not an application—and that rejoinder was also not totally inaccurate. But with Ajax, the Web-application dichotomy is disappearing. The retort is becoming less accurate, and the criticism more accurate.

I don’t claim to know what should be done. The simplest update notification would be to set the visibility of the body element to hidden for half a second, and then back to visible, thus visually simulating a page refresh. Crude, but it would play directly to users’ expectations. The fading yellow highlight in Basecamp gets a lot of attention (and imitators), and that’s a good way to go too. We could envision tossing a red outline onto something that changed, or animating a target-reticle effect on the updated content, or any number of other ideas. Again I say: the decades of work done in HCI research are a resource we should not ignore.

From my perspective, there are at least two good things in the Ajax world. First is that the need for understanding and using CSS, XHTML, and the DOM has never been greater. Okay, it’s a slightly selfish thing, but it leads directly into the second good thing: that the need for standards support has never been more critical. If a browser wants to play in the Ajax space—if it wants to be a serious platform for delivering applications—then it’s going to have to get along with the others. It’s going to have to support the standards.

So it turns out that crackers can mess up your Web site with nothing more than a malformed HTTP packet. You might think something as simple as HTTP would be basically risk-free, but no, I’m afraid not. All it takes is interaction between programs that handle HTTP data slightly differently, and hey presto, you’ve got a security hole.

Ben Laurie weighed in on this:

“It is interesting that being liberal in what you accept is the base cause of this misbehaviour,” Laurie says. “Perhaps it is time the idea was revisited.”

That’s a reference to the late Jon Postel‘s dictum (from RFC 793) of “be conservative in what you do, be liberal in what you accept from others”. This is done in the name of robustness: if you’re liberal in what you accept, you can recover from data corruption caused by unanticipated problems.

Laurie’s right. The problem is that being liberal in what you accept inevitably leads to a systemic corruption. Look at the display layer of the Web. For years, browsers have been liberal in what markup they accept. What did it get us? Tag soup. The minute browsers allowed authors to be lazy, authors were lazy. The tools written to help authors encoded that laziness. Browsers had to make sure they could deal with even more laziness, and the tools kept up. Just to get CSS out of that death spiral, we (as a field) had to invent, implement, and explain DOCTYPE switching.

In XML, it’s defined that a user agent must throw an error on malformed markup and stop. No error recovery attempts, just a big old “this is broken” message. Gecko already does this, if you get it into full-on XML mode. It won’t do it on HTML and XHTML served as text/html, though, because too many Web pages would just break. If you serve up XHTML as application/xml+xhtml, and it’s malformed, you’ll be treated to an error message. Period.

And would that be so bad, even for HTML? After all, if IE did it, you can be sure that people would fix their markup. If browsers had done it from the beginning, markup would not have been malformed in the first place. (Weird and abnormal, perhaps, but not actually malformed.) Håkon said five years ago that “be liberal in what you accept” is what broke the Web, markup- and style-wise. It’s been a longer fight than that to start lifting it out of that morass, and the job isn’t done.

Authors of feed aggregators have similar dilemmas. If someone subscribes to a feed, thus indicating their interest in it, and the feed is malformed, what do you do? Do you undertake error recovery in an attempt to give the user what they want, or do you just throw up an error message? If you go the error route, what happens when a competitor does the error recovery, and thus gets a reputation as being a better program, even though you know it’s actually worse? That righteous knowledge won’t pay the heating bills, come winter.

“So what?” you may shrug. “It’s not like RSS feeds can be used to breach security”.

Which is just what anyone would have said about HTTP, until very recently.

In the end, the real problem is that liberal acceptance of data will always be used. Even if every single HTTP implementor in the world got together and made sure all their implementations did exactly the same strictly correct conservatively defined thing, there would still be people sending out malformed data. They’d be crackers, script kiddies—the people who have incentive to not be conservative in what they send. The only way to stop them from sending out that malformed data is to be conservative in what your program accepts.

Even then, it might be possible to exploit loopholes, but at least they’d be flaws in the protocol itself. Finding and fixing those is important. Attempting to cope with the twisted landscape of bizarrely interacting error-recovery routines is a fool’s errand at best. Unfortunately, it’s an errand we’re all running.