Posts in the Tech Category

Since Kat and I were going to be visiting Florida so often last year and this, and therefore we of course had to visit Disney World a lot, we decided to buy annual passes.  I was quite interested that when you buy an annual pass, the Disney folks take the prints of your right hand’s first and second fingers.  That data is associated with the card; whether it’s encoded onto the card’s strip or not, I don’t know.  But either way, some of your biometric data is associated with your Disney pass.  When you enter the park, you run the pass through the turnstile and stick your fingers into a reader.  If the fingers don’t match the card, you can’t get in, so you can’t share an annual pass with anyone else.

Now, suppose the Disney database stores that biometric data.  Now they have that data tied to a credit card number, purchasing patterns in the parks, probably a home address and phone number, and so on.  Interesting.  Guess what?  As of 2 January 2005, Disney is doing that for all passes: day passes, park hopper passes, all kinds of passes.  Every kind of pass.  Get a pass, get your fingers scanned.  (Okay, yes, you can opt out and be required to show photo ID, but how many people will bother?)

That’s a whole lot of biometric data associated with a whole lot of consumer data.  Interesting, don’t you think?

• Mickey Prints was published on Sunday, January 9th, 2005.
• It was assigned to the General and Tech categories.
• There have been twenty-nine replies.

In a fashion vaguely reminiscent of the process by which weeds keep growing back no matter how you try to rid yourself of them, the question of browser market share has once again been rearing its foul, misshapen head.  Dan kicked off a round of it over at Simplebits, but it’s recently been popping up other places as well.  I heard discussions about market share at SES Chicago, perhaps unsurprisingly, but I’ve also been seeing the question on various mailing lists and other forums.

The only thing more frustrating than the persistent recurrence of this unnecessary question is the inappropriate gravity it seems to acquire in so many minds.

Look, I’ll make this very simple for everyone.  If you’re trying to figure out what browsers to support (or not) in terms of layout consistency on a given site, then the answer is very easy.  Whatever the site’s access logs tell you.  End.  Of.  Story!

For example, the stats for the past few days’ worth of visitors to Complex Spiral Consulting tell me the following:

User Agent	Portion of hits
Firefox	43%
IE6	30.8%
Mozilla	8.8%
Safari	8.6%
Opera	2.4%

(For those who are curious, IE5.5 makes up 0.8% of hits.  Various flavors of IE5.x below IE5.5 total roughly 1.2%, but note that Windows and Mac users are lumped together there.)

Those statistics tell me quite a bit about the people who visit the CSC site, and I can use that information to decide what to do about browser support.  You know what those numbers tell you about which browsers to support (or not) in your designs for sites on which you work?  Absolutely squat.  Anyone who uses those access statistics to make decisions for their own work is a fool, and a misinformed fool at that.

In every design, we have to ask what browsers need to have a consistent experience, which ones can be given a reduced experience, and which ones get no design at all.  The user logs from another site are useless in trying to make this decision.  The “global statistics” from firms like WebSideStory are just as useless in this case.  They may be entirely accurate, but they are also entirely irrelevant when it comes to making design support decisions.  The only stats that matter are the ones that come from the site you’re designing.

In a like manner, I don’t care if you think visitors to your site or some other favorite site of yours are an accurate reflection of the overall Internet population or not: that opinion is similarly irrelevant.  It’s rather like me claiming that the people who come to our annual holiday party are an accurate reflection of partygoers in general.  Maybe they are and maybe they aren’t, but either way I don’t think you should plan your all-night rave to accomodate the kinds of people who drop by our house to have homemade bread and soup and chat about babies, politics, science-fiction movies, and the weather.  And vice versa.

(Do remember that your site’s stats may reflect its current behavior instead of your potential audience.  If your site is already broken past the point of usefulness in Safari, then you’re going to see very low Safari numbers.  Make sure that you’re comparing apples to apples, and only compare the numbers in your access logs for browsers that can already use the site.)

As for the related question of “at what percentage level do I decide a browser isn’t worth bothering about”—well, that’s really up to you, isn’t it?  I certainly can’t tell you when it’s worthwhile to stop worrying about IE5.0, or Netscape 4.7, or Mosaic 1.2.  I know what I think is appropriate for the sites I work on—and the process of finding the answer is different for every site.  It has to be, because every site is different.

Now, if you want to share your user demographics with anyone who wants a peek, hey, have fun with that.  If data exhibitionism is your thing, who am I to judge?  Just don’t pretend that the bits of data you’re exposing to the world are representative of everyone else’s, because I guarantee you that they are not.  As for anyone who happens to glance at your data: I hope they realize the same thing.

• Don’t Care About Market Share was published on Monday, December 20th, 2004.
• It was assigned to the Browsers category.
• There have been forty-one replies.

Due to some weather-related travel upheavals, I didn’t get to spend as much time at SES Chicago as I would have liked—I ended up flying in Tuesday afternoon, speaking before lunch Wednesday, and leaving Wednesday evening.  Still, the panel went very well, the speakers were quite gracious, and I didn’t even need a fire extinguisher.

Based on what was said in the panel and the fleeting conversations I was able to have (sometimes from the podium) with Matt Bailey and Shari Thurow, here’s what I took away from the conference:

• Semantic markup does not hurt your search engine rankings.  It may even provide a small lift.  However, the lift will be tiny, and it isn’t always a semantic consideration.  Search engines seem to use markup the same way humans do: headings and elements that cause increased presentational weight, such as <strong> and <i>, will raise slightly the weight of the content within said elements.  So even the presentational-effect elements can have an effect.  They also stated that if you’re using elements solely to increase ranking, you’re playing a loser’s game.
• The earlier content sits in the document, the more weight it has… but again, this is a very minor effect.
• Hyperlink title attribute and longdesc text has no effect, positive or negative, on search engine ranking.  The advice given was to have a link’s title text be the same as its content, and that anything you’d put into a longdesc should just go into the page itself.  (Remember: this advice is ruthlessly practical and specific to search-engine ranking, not based on any notions of purity.)
• Having a valid document neither helps nor hurts ranking; validation is completely ignored.  The (paraphrased) statement from a Yahoo! representative was that validation doesn’t help find better information for the user, because good information can (and usually does) appear on non-valid pages.
• Search engine indexers don’t care about smaller pages, although the people who run them do care about reducing bandwidth consumption, so they like smaller pages for that reason.  But not enough to make it affect rankings.
• A lot of things that we take for granted as being good, like image-replacement techniques and Flash replacement techniques, are technologically indistinguishable from search-engine spamming techniques.  (Mostly because these things are often used for the purpose of spamming search engines.)  Things like throwing the text offscreen in order to show a background image, hiding layers of text for dynamic display, and so forth are all grouped together under the SEO-industry term “cloaking”.  As the Yahoo! guy put it, 95% of cloaking is done for the specific purpose of spamming or otherwise rigging search engine results.  So the 5% of it that isn’t… is us.  And we’re taking a tiny risk of search-engine banishment because our “make this look pretty” tools are so often used for evil.

Reading that last point, you might be wondering: how much of a risk are you taking?  Very little, as it turns out.  Search engine indexers do not try to detect cloaking and then slam you into a blacklist—at least, they don’t do that right now.  To get booted from a search engine, someone needs to have reported your site as trying to scam search engines.  If that happens, then extra detection and evaluation measures kick in.  That’s when you’re at risk of being blacklisted.  Note that it takes, in effect, a tattletale to make this even a possibility.  It’s also the case that if you find you’ve been booted and you think the booting unfair, you can appeal for a human review of your site.

So using standards will not, of itself, increase your risk of banishment from Google.  If someone claims to Google that you’re a dirty search spammer, there’s a small but nonzero chance that you’ll get booted, especially if you’re using things like hidden text.  If you do get booted and tell Google you aren’t a spammer, and they check and agree with you, you’ll be back in the index immediately.

So there’s no real reason to panic.  But it’s still a bit dismaying to realize that the very same tools we use to make the Web better are much more often used to pollute it.  I don’t suppose it’s surprising, though.

Due to my radically compressed schedule, I was unfortunately not able to ask most of the questions people suggested, and for that I’m very sorry.  There was some talk of having me present at future SES conferences, however, so hopefully I’ll have more chances in the future.  I’ll also work the e-mail contacts I developed to see what I can divine.

• SES Chicago Report was published on Saturday, December 18th, 2004.
• It was assigned to the Speaking and Standards categories.
• There have been fifteen replies.

Behold: v1.1 beta 2 of S5.  This version has a few of changes, all of which are being floated as trial balloons.  Feedback on them all is appreciated.

• Change in file structure.  Now the ui/ directory will contain only directories.  Thus, the default theme and scripts live in ui/default/.  The reason for this is so that other themes can be put in the ui/ directory without things getting too confusing.  For example, the current beta version has a v11b2/ directory (the beta’s version of ui/) that contains default/ and i18n/.  Switching between them does require manual editing of the XHTML file, as I decided to punt on dynamic theme switching for now.  This does, however, let an author carry around a single ui/ directory with a number of themes contained inside.  That way, he might have four presentations to give, each one with a different theme, but all of them sharing the same ui/ directory.

  Another advantage to changing the directory structure is that v1.0 presentations won’t be compatible with v1.1 themes.  That’s actually a good thing, since the XHTML structure changed in small but significant ways in v1.1b1.

  I thought about further splitting the default directory into “script” and “style” subdirectories, but this seemed like a bit of overkill.  However, I’m starting to wonder how to handle things like IE/Win behaviors, which I suspect will be needed before too much longer.  Why?  Look at the images in the v1.1b2 testbed: they all have flat white backgrounds.  I’d like to turn them all into PNGs with alpha channels, and I’d like to have those work as intended in IE/Win.  The only way to make that work right now is via behaviors like this one.  I’ll want to drop those behaviors into the default/ directory—my leading candidate would actually be IE7, once it gets close to being stable, mostly because it would add quite a lot to theme authors’ CSS toolkits.  But all those behavior files could clutter up the directory, for which the easiest fix is to drop them all in a subdirectory… you probably see where I’m going with this.

  That’s all for another version, though; v1.1 won’t have any behaviors packaged by default.  It’s just on my radar, and I thought I’d toss it out to see if anyone has bright ideas.

• A “header” file for themes.  You can see an example at v11b2/i18n/00_head.txt.  Briefly, this file contains material destined for the head element of any presentation that’s going to use this theme.  In the case of i18n, the only thing that changes is the link element pointing to slides.css.  Nevertheless, the header file provides all of the link and script elements that should appear in the presentation file.  This should make it easier for an editor program to just grab each block and paste them over the existing block in the presentation file.  It will also reduce ambiguity for anyone doing a manual edit to change themes.  (Open header file, drag-select, copy; open presentation file, drag-select, paste, save, done.)

• Changes to incremental class names.  In earlier versions, incremental-display objects were marked with a class of inc, and any list that should start out already showing the first list item got a class of psf.  I’ve changed those to incremental and show-first.  The new names require a little more typing, but they’re much less ambiguous and therefore much more author-friendly.  I’m interested to see if anyone has ideas for better names, especially for show-first.

As for the issue of licensing, I guess I’m little further along, but not all they way yet.  The discussion did help me focus on what I want.

• Presentation content should be under whatever license/terms the author desires.  I do not want to force all S5 presentation content to be public domain, or GPL’ed, or whatever.  If someone wants to give a highly confidential talk using S5, they should be able to put the most restrcitive license in the Universe on the content… but only on the content.

• Themes should similarly have their licenses, or lack thereof, determined by each one’s author.  If Joe Consultant wants to create a MyCoolCo theme and release it under copyright so that anyone can use the theme for their own presentations but nobody is allowed to re-use his images/look-and-feel/whatever outside the S5 theme, there should be nothing that stops him from doing so.

• The S5 system (JS, core CSS, and the way they’re put together) should be forever free to use by anyone who wants to do so.  It should be open for future development, in the event that I stop developing it and someone wants to keep going.  This would also allow anyone to fork off their own variant on S5 at any time, but that’s okay too.

  Here’s where it gets a little tricky: S5 should be able to be incorporated into any other project, commercial or not, without restriction.  Attribution to the original source is to be strongly encouraged, but not an absolute requirement.  But at no time, and in no way, should use of S5 in a closed environment ever cause a back-flow of restrictions to the original project.

In other words, anyone should be able to use S5 or a derivative work in their for-profit, wholly proprietary, patented software (or in any other circumstance).  They can even make modifications, if they like.  However, there should be no way for their use of it in a closed system to infect the original S5 source, and if their modifications make it into a future version of S5, the same should hold true.  I don’t even know if that’s possible, but it’s in the spirit of the Share Alike terms in the Creative Commons licenses.  You want to build S5 support into your $49.95 fully copyrighted and licensed editor?  Fine, no problem.  You want to extend S5 to do more cool stuff?  Also fine, but freely contribute the changes back to the place you got the code in the first place.  Don’t try to claim the original project has no right to the additions you made to it, or that the addition of those changes to the original project makes the whole thing yours.

(Not that I think any of you would do such a thing, but I have to think ahead to when S5 catches the interest of someone… well, let’s say less scrupulous.)

In a sense, I want to prevent major infection of licensing terms in both directions.  I’m not entirely sure where that leaves me, but I’d like to work it out before 1.1 goes final.

• S5 1.1b2 was published on Thursday, December 9th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been thirty-one replies.

I just stumbled across a browser bug this evening that I thought you all might like to know about.  So we all know that IE6/Win supports text-align: justify, right?  Wrong.  Sorry, but it’s the truth: IE6 does not fully support text-align: justify.  True, it mostly supports that declaration, but if you apply said declaration to a caption element, guess what?  You get centered, non-justified text instead.  It’s very much as though, in the case of caption elements, IE6 replaces justify with center.

I just thought I’d pass this along in case it might help anyone else avoid some furious head-scratching.  And, I’m sorry to say, I don’t know of a workaround.  If anyone finds one, please leave a comment to that effect.

This is a perfect illustration of how difficult it is to do comprehensive CSS testing.  Every CSS support chart I’ve ever seen has marked down IE6 as supporting justified text; I mean, why wouldn’t they?  It clearly did so… for the specific test cases used to create that support chart.  The odds of a test page including a caption element are pretty vanishingly small, unless of course we’re talking about a test page that includes every single XHTML element in existence.  And to test every element known for every property-value combination… well, I’ve talked about that before.  No need to trample the same ground even flatter.

• Unjustified Caption Text was published on Wednesday, December 8th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been twelve replies.

I’ve gotten a few e-mails and comments to the effect that instead of using a Creative Commons license for S5, I should use GPL instead.  One of the reasons given to me was that the Creative Commons licenses are not considered appropriate for software, according to the Creative Commons folks.

My problem is that I don’t really think of a collection of (X)HTML, CSS, and JavaScript as “software”, so the GPL doesn’t really seem to fit.  Yes, the JS is code, and one could argue that it’s software of a kind, but markup?  Presentational hints?  Not so much.  I feel the same way about the Color Blender: it’s not really software so much as a widget.  A fun widget, perhaps even cool to some people, but still not software in the way that BBEdit or NetNewsWire or any given Web browser is software.

My other problem with GPL is that it’s long and stunningly legalistic.  It kind of has to be, and I think that’s great for the purpose for which it’s intended.  To ‘protect’ things like S5 or the Color Blender, the GPL kind of feels like protecting a kitten with the 82nd Armored Division.  What I like about the CC licenses is that they’re easily understandable; even the “lawyer-friendly” versions are compact and mostly understandable.  In perusing the list of licenses over at the Free Software Foundation, I quickly got a headache.  The one license that seemed the closest fit is the Expat license.  But even there, given the way it’s written, I come up against the question: is a confederation of markup, styles, and client-side code really “software”?

So what to do?  Stick with the CC license?  Move to Expat?  Plunge into GPL-land?  Come up with my own variant license based on Expat or something similarly simple?  I’d be interested to hear people’s opinions—especially those of you who have faced the same question, or a similar question, in the past.

I’m still a little bit bemused that it’s even a question, and a little bit dismayed that ours is the kind of world where I really do have to worry about this sort of thing.

• S5 Licensing was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 category.
• There have been forty-one replies.

Okay, S5 version 1.1 is now at beta 1 status.  In the process, I’ve rearranged the S5 sub-site a bit.  The testbed is now in a new location that will let me more easily manage version changes, and also keep test files out of the main directory.  The testbed demonstrates, at least right now, various forms of incremental rendering, including both text and image techniques.

There are some changes to note in 1.1b1:

• The controls div is now a child of the layout div, and is thus no longer structurally confined to the footer.  This makes a few things easier, but it does mean any 1.0 themes are likely to get mangled a bit.  I decided to do this now in order to minimize disruptions.  The structure reference does not reflect this, as it documents v1.0, but will when v1.1 is finalized.  I was able to convert the default theme, I18N, and a new theme to handle this new structure without much trouble.
• I’ve refactored some of the CSS files to make them more compact.  Nothing earth-shaking, but I thought I should mention it.
• The slideshow configuration meta elements have been renamed to defaultView and controlVis, and have slightly different accepted values, but otherwise do exactly what they’ve done since they were added.
• I’ve added an authaffil meta element, with syntax set up to allow multiple authors to be listed.  I’m considering making the value format a little more machine-readable, but we’ll see what you all think first.
• I fixed the Safari bug where it advanced the slide show when opening an external link.  Yay me.

I’m in the process of setting up an archive for ‘official’ S5 versions, so that you’ll still be able to download the S5 1.0 UI folder even when we’re up to 1.725 or whatever.  This will be in place for the launch of v1.1.  Yes, I hear you: use SourceForge!  I’m abstaining for now, because I don’t have time to figure out how to set up a project on their system, let alone how to fix their UI so it isn’t confusing and frustrating.  Mine may not be much better right now, but at least mine’s easy for me to fix (and I’ll get to it soon, I promise).

The other major addition I have planned is to create a set of guidelines for theme packaging.  For example, every theme should contain a file titled 00_head.txt that contains the head-based elements (links and so forth) that should be used in a presentation file in order to make the theme work.  This will make it much easier for presentation authors to use themes without having to understand the ins and outs of the S5 file structure, and for theme authors to only have to package the files they want to change.  Hopefully that will make more sense once I write the guidelines.

And finally, you may have noticed that I’ve stopped superscripting the 5 in S5.  Practically nobody else was doing it, and it was getting to be a pain even for me to type, so I figured I’d go with the flow.  I’ll change the documentation eventually.

So please test out the testbed and let me know if anything goes seriously awry.  If anyone wants to try hooking up the 1.1b1 UI files to their own presentation, I’d be interested in hearing the results.  Remember, though: make sure your presentation file’s XHTML validates!  If you report problems in an invalid presentation, I’m not going to look at it until the validation errors are corrected.  That’s because the DOM routines depend on well-formed markup, and it would be futile for me to try to debug any problems caused by invalid markup.

With luck, we’ll only need one or two beta cycles before 1.1 can go final.

• S5 1.1b1 was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-eight replies.

While I was in Florida with my family visiting both sets of parents, Tristan Nitot published an article titled “How Microsoft can support CSS2 without breaking the Web“.  In it, Tristan points to a comment made by Gary Schare, Director of Windows Product Management at Microsoft, which was:

We could change the CSS support and many other standards elements within the browser rendering platform. But in doing so, we would also potentially  break a lot of things.

(from Microsoft Windows Exec Talks IE, Firefox)

Tristan then goes on to refute this line of thinking.  Generally speaking, I’m entirely in agreement with him.  (As a disclaimer, Tristan and I worked together as members of the Netscape Standards Evangelism Team, and Tristan asked me for feedback on his article before it was published.)

Here’s the thing: in the Windows world, Explorer already significantly upgraded its standards support four different times.  The most recent such upgrade was called IE6.  That was the version that first added DOCTYPE switching to IE/Win.  At that time, there were a great many changes made to the standards support, nearly every one for the better.  For example, in standards mode, you could no longer throw around unitless numbers and have them interpreted as pixels, because that violated the CSS specification.  You couldn’t set a height or width for an inline non-replaced element, because that too was incorrect.  The interpretation of font-size keywords was changed to reflect the CSS specification instead of the HTML font-sizing regime.  The box model was altered to follow CSS instead of the old IE way.  In short, there was all kinds of stuff in there that would “break a lot of things”.

The Web rather steadfastly declined to be broken.  Oh, sure, there were pages whose layout was altered—not many, thanks to the way DOCTYPE switching was implemented, but they were out there.  Anyone who was relying on the IE/Win way of doing things but used a DOCTYPE that triggered standards mode (say, for example, a HTML 4.01 Transitional DOCTYPE with URI) ended up with a “broken” page.  These problems were fixed by their authors, and that was that.  I remember a number of forum posts about how “IE6 broke my design”, and the posts that helped those authors address the problem.  In the case of old, unmaintained pages, they stayed broken, but odds are that next to nobody cared.  Regardless, it isn’t exactly a point of major concern on any radars I’ve seen in the last three years.

Furthermore, IE6 fixed a number of parsing bugs that existed in previous versions.  One of those was the bug on which Tantek Çelik’s “Box Model Hack” depended.  However, the parsing bug was fixed in both quirks and standards modes, so the BMH utterly failed to work in IE6 no matter what DOCTYPE you used.  That actually did break quite a few layouts, if I remember correctly.  I also remember the day I discovered that they’d fixed the parsing bug in both standards and quirks modes.  I swore at my monitor for a moment, and then actually thought about it.  I realized that the inconvenience of removing a few CSS hacks, or at worst changing to different hacks, was a pittance to pay in comparison to the advances IE6 had made in terms of increased standards support.

So I fixed a few style sheets, tossed a hack out of my mental toolbox, and got on with my life.  I contend that exactly the same thing would happen if a service pack were to add increased standards support to IE.

This is particularly true given that most of what IE should add would be, well, additions.  As in, things that IE doesn’t even try to support now, and so almost nobody uses them.  Think generated content.  Think attribute selectors.  Think fixed positioning.  These are all things that, if they were added to IE, would break almost no pages at all.  In fact, they’d make a small number of pages work better in IE.

For that incredibly small number of pages that would break (for whatever value of “break” you care to name) with improved standards support in IE6, I’m willing to bet that nearly all of them would get fixed right away.  Why?  Because they would be pages maintained by authors who actually want to use standards and care about doing things right.

Now, there is one area where I think the IE team would have to be careful about adding support, and that’s selectors.  A lot of hide-from-IE CSS hacks these days are based on its failure to support the child selector; in fact, I use these a few places in the S⁵ style sheets.  It is possible that adding support for child selectors to IE6 would be more harmful than beneficial.  I say it’s possible because I don’t know.  Nobody does—but Microsoft of all organizations has the ability to find out, and to act accordingly.  They have the funding, the personnel, the skills, and the customer base.  As Tristan said:

In its short, 2 1/2 year life, the Netscape Evangelism team helped  literally thousands of authors and administrators of web sites around the  world to improve their support for the W3C DOM and CSS Standards. If such a  small group with limited resources can help change the web, imagine what  Microsoft could do with its resources if it only tried.

Indeed.

Granted, the net stands still for no one, not even Microsoft.  There have already been, and continue to be, efforts to graft better standards support onto IE despite itself:  projects like PNG transparency fixes, whatever:hover, and IE7 take Microsoft’s proprietary behaviors and use them to make it easier to use open standards.  (I adore the poetry of that.)  The people behind those projects are already doing what Microsoft is apparently afraid to do, and they demonstrate why improving standards does not mean breaking the Web.

There’s one other point to consider.  If IE/Win improved its standards support in any meaningful way, believe me when I say that the news would be shouted from the Web site of every standards advocate in the known universe.  Nobody responsible for standards-oriented pages could avoid hearing about it.  Any problems would be quickly explained, and adjustments made.  Life would not only go on, but be better for developers and designers.

To sum up: the “more standards will break stuff” argument just doesn’t fly any more.  Microsoft can figure out what to do that won’t break pages, and there’s a ton of things that are new-to-IE, the implementation of which will no more break pages than did the image toolbar.  In cases that might cause breakage, Microsoft can determine—with community help, if they were to ask for it—how to minimize breakage while maximizing benefit.  To claim that possible Web page breakage prevents Microsoft from increasing standards support makes about as much sense as to claim that possible program breakage prevents them from ever changing or improving their operating system.

Despite this, I don’t have  much hope that we’ll see any improvements before Longhorn debuts.  I think that’s a shame, because I remember when the IE team was gung-ho about standards.  There were a number of very smart people who understood why standards were important, and were committed to doing their best to support standards in IE—not just on the Macintosh, but for Windows as well.

I do hope for Microsoft’s sake that those days return.  Because the Web continues to move, and if they just stand there promising that everything will be better in Longhorn, they may well find themselves left behind.

• Unbreaking the Web was published on Wednesday, December 1st, 2004.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been forty replies.