Posts in the Standards Category

The weeklong break is over.  Now I start a weekend break.  Meanwhile, a few things that flitted across my radar while I was away:

• Please, for the love of all that’s holy, patch your Windows boxes!  Like Zeldman and Kurtz, I too have had an e-mail address filled into forged e-mail headers, and been hit with bounces galore.  Hopefully this will all soon become a lesser problem with a change in server, but still—patch those leaky systems!  Now!
• Some interesting quotes from and commentary on Weaving the Web.
• Thanks to a post by Mark Pilgrim, “‘Considered Harmful’ Essays Considered Harmful” is getting some traffic.  This amuses me.
• Hell yeah.  I’m behind George 100% on pretty much every point he makes, and I’ll just add that we’re a major airline hub so finding reasonably priced flights to just about anywhere is a snap.  ‘Nuff said.

That’s it for the moment, but I hope to have a new site and some new content to share with you on Monday.

• Ketchup was published on Saturday, August 23rd, 2003.
• It was assigned to the Cleveland, Standards, and Writing categories.
• There have been no replies.

Yesterday’s announcement has generated a fair bit of attention, which is certainly a good thing for a new startup.  My deepest thanks to everyone who wrote words of support and congratulations, through all the e-mail and many a weblog.  Your collective enthusiasm has definitely made today one of the best in months, and eased my mind quite a bit about the step I’ve taken.  And those of you who got in touch regarding contracting my services get extra-special thanks!  (What are the rest of you waiting for?)

I mentioned that one of my clients is “a major and highly respected name in the industry,” and I’m proud to say that client is Macromedia.  My work is actually in two different areas, both of which relate to CSS, and I’m looking forward to talking about the projects in more detail once they’ve been completed.  For now, let me just say that Macromedia is serious about using CSS well, and in doing the right thing.

I’m hoping that this weekend I’ll get the consulting site material together and ready for launch—I don’t even have a design yet.  What I may do is use a variant of a meyerweb theme as a first look and then, like Zeldman did earlier this year, redesign in public, commenting on my choices and techniques as I go.  I don’t know if a business site has ever done exactly that kind of a redesign before, and it seems like it would be an interesting experiment.  To be honest, I may chicken out and just jump from one design to another instead of evolving it over time, rather than experiment with a business site.  We’ll see what kind of feedback I get on the idea.

Speaking of feedback, I need to pass along some tidbits readers sent in response to my discussion of governments and open standards:

• Bob Sawyer wrote to say he’s created a discussion forums for Webmasters at the fledgling Built For The Future, which looks like it could be just the kind of resource people need.
• Felix Ingram sent in a link to a fascinating Wired article on standardization and its distinctly political nature.
• Rob Lifford pointed out the Texas Governors’ site is accessible, and even has a dedicated statement about the use of W3C standards.  That jostled my memory and I remembered that the City and Borough of Juneau, Alaska‘s site did something similar a while back.
• Paul Martin speculated that, until recently, standards use and accessibility have been almost entirely the concern of hand-coders, the people who know the nuts and bolts that make a page work.  If that’s so, then the WaSP was absolutely right to concentrate on getting tool vendors to clean up the markup they generate.

I’m going to take the weekend to concentrate on responding to e-mail, doing some writing, and fleshing out the new site, and should be back bright and early Monday morning to regale you with more random stuff.  Enjoy your weekend!

• Feedback was published on Friday, August 1st, 2003.
• It was assigned to the Consulting, CSS, and Standards categories.
• There have been no replies.

In response to yesterday’s musings, a correspondent wrote in to say:

…a local Swiss government [has] switched their site (now 95%+) to structural HTML and CSS and freed the site from font-tags and framesets….  In the meantime, I have found that beginning at January 1st, 2004, a new law will be in force that demands from all official Swiss sites that they be accessible.  So to speak, Switzerland has now [its] own “Section 508”.

I noticed some layout problems in IE5/Mac, but otherwise the site looks pretty good.  The important point is this: there are people working in government sectors who care about accessibility and forward-thinking design.  What we need now is a channel to get them in touch with each other and swap tips on how to advance the cause.  Who wants to set it up?  (I’d do it myself except I already ride herd over a high-volume mailing list, and that’s plenty.)  If someone does create a venue for government Webmasters who are pasasionate about using standards, and is willing to devote the time and energy to making sure that venue is a good one, please tell me where it is via e-mail and I’ll share the news here.

Another reader wrote to say that in the wake of a recent redesign:

…we’ve gotten quite a few letters from people who work for various federal government agencies (especially the DOJ) saying they aren’t even allowed to use any other browser besides Netscape 4.

I can’t say this really surprises me a great deal, having talked to folks at a U.S. government research facility who only recently managed, after much internal argument, to convince their IT staff that running Mozilla instead of NN4.x was an acceptable course of action.  I suspect that a major reason the government sticks with NN4.x is its relative level of security; it may not be bulletproof, but it’s a darned sight more secure than some other browsers I could name.  Then again, this is the same government that uses Windows more or less universally, so I’m not sure how secure they really are.  (Not much.)

Then there was a followup message from my unnamed government source, who said in part:

…none of the other on-staff developers really want to learn new methods, I think, and therefore they’re going to stonewall any endeavor that’s going to require them to take some classes (or, potentially, cost them their jobs, I suppose).

That’s sad, but it’s also not unique to the Web field; you get reactionary behavior of that kind in just about any work situation.  I wonder, though, if perhaps it’s more entrenched in the government sector because job losses are so rare.  Or are they?  I always thought federal jobs, at least, were massively protected and rarely did anyone ever get fired, but I might have swallowed some Reagan-era Kool-Aid.  Someone let me know if I’m wrong.  Too many things to learn, not enough brain tissue…

• Federation was published on Wednesday, July 30th, 2003.
• It was assigned to the Standards category.
• There have been no replies.

Anyone who’s been reading this site for more than a year might remember my rantings last year when the Section 508 Web site went online and proclaimed it worked best in IE5+ for Windows.  The other day, I got e-mail from another developer working for the U.S. House of Representatives, who had some disheartening information to share, and I think it’s worth talking about.  I’m going to quote my source in some detail, but as you might expect, this will be an “unnamed government source.”  I’m going to use the pronoun “he” because it’s technically gender-neutral English, and I don’t feel like saying “he or she” every time I need to use a pronoun.

The e-mail was prompted by this person finding and reading last year’s rants.  Thus, after a short introduction, he said:

…as far as the 508 guidelines go, we use them, but nobody seems to actually be concerned with accessibility. It’s just making sure the InFocus software approves you according to the guidelines, and plod onwards. Nobody cares about the usefulness or lack thereof of the features they’re putting in, nothing is planned out, and the barest minimum to meet the guidelines is all that you’ll get from most developers.

This, of course, is a problem of management: it would seem nobody in this particular shop has made forward thinking a priority.  Rather than plan for the future, they’re stuck in the past.  (Some would say this is unsurprising in a government institution, but never mind that now.)  You might think a quick intravenous application of Designing With Web Standards might be just what the doctor ordered.  However, it turns out there’s a reason the project managers don’t care:

Of course, this is infinitely more preferable to the attitude from the actual Congressmen; I’ve actually had aides ask me if the site has to include accessibility features.

And there’s the problem.  The clients are not only aware of accessibility, but borderline hostile to it.  How do you overcome that kind of hurdle?  We can say, “It’s your job to educate the client,” but at a certain point you have to stop singing to the pigs.

I seem to recall that, some time back, AOL was sued for being inaccessible, and lost.  Will it take a similar suit to bring government sites into the 21st century?  I sincerely hope not; if there’s one thing I think America could do with less of, it’s lawsuits.  (No offense intended to the legally inclined folks I know.)

In such a situation, the best approach to improvement would likely be a back-stage effort by the coders themselves.  They can just do the right thing and not bother their clients with the details of how things get done, right?  Maybe not:

…just about everybody is still coding with FONT soup. This is especially frustrating when people ask me for help to do something which would be trivial if they knew a modicum of CSS, but which is onerous at best given whatever HTML hack they’re using. I’ve broached using more CSS with people, and they all just mutter something about Netscape 4 and stick their heads back in the sand.

At this stage, I’m not sure what can be done for Our Hero, except maybe expressing some compassion and pity.

This is the kind of situation that I think is more common than many of us realize, and it’s a serious impediment to the forward motion of the Web.  The enormous amount of wasted bandwidth and time such coding practices incur would, if translated into dollars, very likely cover a significant chunk of the U.S. national debt.  There are too many Web authors stuck in 1999, and not enough who are looking forward to 2005 and beyond.  What words, what memes would penetrate their shells and point them in the right direction?

This is a deep and serious challenge for groups like the W3C and the WSP, not to mention people like me, who just want things to be better than they’ve been in the past.  Last night I met a guy who expressed incredulity that Netscape had hired me, back in May of 2001, to tell people that standards were a good thing.  “What was your title, Manager In Charge of Repeating the Painfully Obvious?” he asked, laughing.  If only that had been so; in an ideal world, there would have been no need for Netscape to hire me in the first place.  What seems so obvious to so many of us seems to be utterly unknown to so many more—or, perhaps worse, known but disregarded.

What will it take to turn things around?  More corporate XHTML+CSS designs?  A pronouncement from one of those consulting firms who get quoted by the media all the time, but nobody really knows what else they do besides issue semi-useless browser demographic data and charge huge consulting fees?  Another grass-roots campaign like the original WaSP?  Blackmail?

I wish I knew.  This is yet another uphill battle against overwhelming odds, but a battle so much worth fighting that I can’t walk away from it.  I think this is my third such battle in the Web space alone.  Sometimes I wonder how many battles I have in me.  I also wonder why I keep finding new battles to fight.

• One Foot In the Past… was published on Tuesday, July 29th, 2003.
• It was assigned to the Standards category.
• There have been no replies.

There’s been some speculation that Microsoft’s recent browser moves may actually be good for Web standardization, not bad.  It’s a side of the issue I hadn’t considered, and it does make a certain degree of sense.  Suppose you’re a large bank and you want a browser that you can rely on to protect your data.  You might well decide that adopting an open-source browser, one which you can influence and even improve if your staff programmers contribute to the project, makes more sense than being beholden to a glacially developing and poorly secured product.  Ditto for companies who care about security—and now that spam-filtering’s built into at least one product’s mail client, ditching Outlook and IE for Mozilla or a variant makes a lot more business sense.

But there’s a down side to the whole situation, which is effectively that the adoption of standards is limited by the available browsers.  If IE/Win stays in its present state for the next two or three years, then use of CSS, XML, XSLT, RDF, P3P, PNG, and pretty much everything else will be constrained by the support IE/Win embodies—not totally beholden to it, but still definitely affected, in the same way the poor CSS support of NN4.x retarded CSS adoption for years.  When IE7 comes out in 2005 or 2006, it will help determine the standards-use landscape by how far its support advances (or doesn’t).  Maybe that’s a good thing.  Maybe having bigger updates less often is better than smaller updates all the time.  It just feels a little too much like stagnation, especially for an industry as drunk on change as ours has been.

Then again, if we’re lucky and Microsoft’s Web competitors don’t fold their cards just when they have a chance of winning back some of the pot, maybe in a couple of years IE/Win won’t be as weighty a gorilla as it is today.

• Salvation in the Storm? was published on Wednesday, July 2nd, 2003.
• It was assigned to the Browsers, Standards, and Web categories.
• There have been no replies.

Chris Hester wrote earlier to point out the CSS2 Test Suite’s main page was completely unreadable in Internet Explorer 6 if you had the “Text Size” set to “Smaller.”  This was news to me; I’d set my text to “Medium” the day I installed IE6 and never looked back.  So I went to the page, changed my text size, and winced.

The problem’s since been worked around, but to see the problem as well as read about the trigger and the solution, try this testcase.  Note that if you’re using IE6 and your browser is set to “Smaller” the testcase will start out completely unreadable.  Set it to “Medium” first and then go to the page and follow the directions.

The flaws in IE6 continue to amaze me, and now we’re stuck with it for another three years, minimum.  Great, just great.

Dave Hyatt recently made some observations about standards-support charts (starting with Standards Charts and continuing into three posts the next day).  I agree with most of what he has to say, actually.  Charts like the “master grid” are by their nature coarse.  They can do no better than provide support information for whichever tests the chart author happened to run.  In presenting an overview and comparison of CSS support, for example, depth-of-implementation testing is sacrificed.  It has to be.  The CSS support charts I published on Web Review for years, and now on DevEdge, are basically the work of one person: me.  I wrote most of what became the W3C’s CSS1 Test Suite in the creation of the original charts, back in late 1996 and early 1997.  Back then, it was easier—bugs were more obvious, and all implementations were shallow.  The charts could afford to be as shallow.

Now, thanks to years of experience, implementations are getting much, much better, and the bugs harder to find.  To fully test modern CSS implementations requires a far more complex set of tests than I could author in a lifetime of evenings (which is when I wrote the tests and the charts).  To be really comprehensive, you’d need to test every property and value combination on every element in HTML (or a markup language of similar complexity), which I think was once calculated to run into a few trillion combinations.  It’s a lot harder to create tests, to run tests, and to chart results than it used to be.  This fact was driven home to me recently as I worked on (finally!) updating the CSS charts.  For the tests I have at hand, most browsers score perfectly, or close to it.  I know that’s not true: every browser has bugs in its CSS support, some worse than others (*cough*WinIE*cough*).

(Aside: I feel either amused or gratified that there’s support for the concept of penalizing browsers for having bugs, a concept I used in compiling the “CSS leader board,” back in the day.  “Full” support earned a point, partial support got half a point, no support got zero, and a bug lost you half a point.  It was a touch crude, perhaps, but it worked.)

But I only have so many hours in every day, the same as anyone else.  It’s not reasonable to expect one or even five people to meet this challenge.  The only way to handle it is to find a moderately large crowd of CSS experts, all of whom trust the others completely, and distribute deep-test creation among them.  In a few months, they may have gotten far enough to run browsers through their tests.  A month or so after that, they could start compiling results, and eventually publish them.  But even assuming all of that data could be collected and presented, how useful would it really be to the Web community?  One of the keys to the original CSS support charts’ success was that they were easy to comprehend: their very shallowness made them useful.  Authors don’t have time for much more.

Implementors have different needs, of course.  If those needs are strong enough, they’re going to need to fund positions (and I do mean more than one) to coordinate the work necessary to fulfill their needs.  The money could come out of the Quality Assurance budget, even.  In any case, if standards support testing is a serious problem, then we’ll need a serious commitment to address it.  Who’s going to step up to the plate?

• Testing for Flaws was published on Tuesday, June 24th, 2003.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been no replies.

I would have posted about this yesterday, but frankly it was too depressing.  As others have noted, Internet Explorer for Macintosh is, effectively, done.  There will not be another major version: I’ll never get to write about CSS support in IE6/Mac, because there won’t be one.  As I said on Webdesign-L yesterday, and Zeldman quoted in part, I said:

[The IE/Mac team] was truly committed to the best standards support they could muster while working for a corporation that did not always share their ideals.  I wish everyone on the IE/Mac team the best of luck in their future projects, whatever they may be.  They not only paved the way for many of the things we now take for granted, but they fought the good fight, fought it hard, and in many respects they emerged victorious.  It’s tough to imagine a better legacy than that.

I was a beta tester for IE5/Mac, and it’s long been a favorite of mine.  There may be some personal bias stemming from the fact that I know bug reports and suggestions of mine are reflected in the final product, but the wider truth is that it was a groundbreaking browser.  I know DOM scripters find it annoying and substandard, but for those of us on the content-authoring side, it was rarely the worst of our troubles.

Others will analyze this development in light of the recent Microsoft/AOL settlement, the cessation of IE/Win as a standalone product, and so on.  I’m not really interested in all that right now.  Instead, I’d like to take a moment to run down a list of innovations and features that IE5/Mac introduced back in 2000:

• DOCTYPE switching—some would call this a bug, but in my view they’re missing the bigger picture.  DOCTYPE switching was the first mechanism that allowed authors to decide whether their document rendering should look to the past, or to the future.  It permitted browsers to fix bugs in standards support, instead of forever enshrining them for the sake of “backward compatibility.”  This quickly spread to Mozilla, and eventually made its way into Opera and IE/Win.
• Display resolution setting—there’s a preference dialog where you can set your monitor’s PPI value, literally by holding up a ruler to the screen and using a slider to match the ruler.  Some Windows display drivers had this before, but IE/Mac was the first major browser to build the feature into the browser itself.
• Text Zoom—don’t like a site’s font size?  Override it with a simple keyboard combination, scaling all the text up or down, depending on what you need.  Mozilla quickly followed suit and Opera introduced Page Zoom, arguably a better solution.
• Excellent CSS1 support—it’s easy to forget how revolutionary a reasonably complete and bug-free implementation of CSS1 really was.  Yes, there are some bugs, as with anything.  It’s still better than IE6/Win’s CSS1 support.
• Decent (if limited) CSS2 support—not quite as robust as the CSS1 support, IE5/Mac still made good forays into CSS2.  Remember the browser was shipped about two years after CSS2 went final, which means it was being written maybe a year after CSS2.  That may sound weak, but consider that in addition to fixing all its CSS1 bugs and finishing off CSS1 support, the team found the resources to look at CSS2 and take a stab at doing it right.  That’s pretty impressive, what with them also having to do all the other stuff a browser has to support besides CSS.
• XML source tree view—if you load up an XML file, you get a “pretty-printed” view of the document and its source, with collapsible element views.  Mozilla got this ability only recently, and I’ve always guessed that IE6’s similar ability only exists because IE5/Mac gave them an example to follow.
• Full PNG support—including alpha channels and gamma adjustment.  Sure, it was years after PNG was published, but who else was doing it at the time?  Even today, people are still signing petitions to get Microsoft to do the same for IE/Win.
• Customizable toolbar—you could define your own toolbar buttons, create PNGs (with alpha) to represent the buttons, and customize your browser.  It isn’t quite “skins” but it was still pretty darned cool.  Oh, and the toolbar configuration data was stored in XML.
• Page holder—eventually Mozilla came along with the sidebar, into which almost anything can be installed.  IE5/Mac was doing it long before, albeit with a somewhat different feature set.

There was more, I’m sure, but that was all that came to mind.  When it shipped in 2000, IE5/Mac had a feature set that would be respectable if the browser were released today.  I’d always hoped that one day it would be followed up with a similarly impressive new version.  Sadly, not so.

Just to add an extra layer of melancholy to the whole thing, when Tantek says he found out from folks pointing it out to him, I was one of those folks.  It’s at once difficult and all too easy to believe that the man who created such a good layout engine, and put in so much effort to improve the Web, found out about the end of his own project from friends and the press.

• Hail and Farewell was published on Saturday, June 14th, 2003.
• It was assigned to the Browsers and Standards categories.
• There have been no replies.

The W3C‘s HTML validator has a new beta that includes a significant change.  It will now attempt fallback validation if it can’t find a DOCTYPE or character encoding.  In other words, if you run a legacy document through the validator, it will warn you the document is invalid because it couldn’t find the stuff it needed, but make a guess at the right DTD and character encoding to use and try validating against those.  See, for example, the validation run of a “non-DOCTYPE” test page.

Personally, I think this is great.  It makes the validator a lot more friendly without giving people the idea that their invalid documents are okay.  It removes one more annoyance from the path to validation, and that can’t be a bad thing.

I spent the three-day weekend producing a few metric tons of screenshots, pounding my head against the desktop over the inline formatting model (again), blowing up some virtual giant robots, and all the other things that make for a good holiday weekend.  Last night Kat and I went with some good friends to see A Mighty Wind, which we all thought was a hoot.  Or, more properly, a hootenanny.  Eugene Levy’s character, Mitch, was just amazing.

• Valid Relaxation was published on Tuesday, May 27th, 2003.
• It was assigned to the Standards category.
• There have been no replies.