Angry thoughts about IE7 and IE8

So much has been written about how IE7 b0rked the user experience for a lot of users... and everytime I see that comment, I get pissy.

Why?

Reasons I get mad about IE7’s twitchiness

1. If so many folks hadn't used IE6 as their dev platform and ignored everything else, these problems never would have developed.
2. If the rest had used proper filter rules, their sites would’ve been easier to fix.
3. If people would take the time to stay current with their skills and learn new ones, the breakage would’ve made more sense at the time (and thus caused less uproar).
4. Did Microsoft's senior management honestly believe that the rest of the world would stand by idly while it let the Internet Explorer property go to seed? Pshaw! (Insert saltier words of one syllable here. Yes, I'm still all manner of pissed off about that.)

By my way of thinking the furore over IE7's “breakage” is from people who treat their jobs like sinecures.

…And the horse they rode in on!

My own experience

Perhaps I’m being a hardass; goodness knows that I’ve got a reputation for it. My bottom line, however, is that when IE7 came out, I probably spent 10-15 minutes per site getting things into shape. IE7 supports standards far better than its predecessor, and I was developing to standards, so I had few problems. Most of those were caused by vestigial hasLayout issues, though more recently I see that the fuzzy selector problem hasn't yet gone the way of the dodo.

If I could do it, why was it so hard for so many other people?

The answers I get to that question speak more than adequately to my anger.

Meta tag mishmash

This will make no sense unless you’ve read the following:

• A List Apart #251
• Compatibility and IE8 @IEBlog
• Jeremy Keith: “Broken”
• In Defense of Version Targeting
• Microsoft’s Version Targeting Proposal

If you know what all of these places are, care what they have to say, and haven’t read them, do so now. I’ll still be here when you come back.

This approach amounts to, “require Web operators to opt-in if they intend to stick to the latest and greatest.” Five years out, this is going to result in a lot of rendering engine bloat and the bugs that go along with that, but Microsoft has plenty incentive to avoid that without badgering from standards advocate. They probably also have some insitutional memory with respect to solving that problem (though the question of whether or not they put it to use is another matter entirely).

Who wins, who loses

This situation begs a game analysis.

• Good for Microsoft: customers don’t yell so much, and are more likely to accept version upgrades of IE (along with their security benefits)
• Bad for Microsoft: improperly used, the recommended change in practice ultimately leaves Microsoft open to the same charges of deliberate somnolence they faced as a result of letting IE6 rot outright for something like four years: why improve your browser if no-one’s using its features? Given Microsoft’s track record, the possibility of this outcome needs to be taken seriously.
• Good for professionals: there will be a mechanism by which developers can avoid passing on sudden and gratuitously fortuitous labor charges because oops! IE was updated and changes were made to the rendering engine
• Bad for professionals: it becomes necessary to keep track of which sites are tethered to which versions of Internet Explorer, which is very close to the outcome WaSP was founded to avoid
• Good for users: version upgrades will no longer result in the entire Web experience going wonky all of a sudden one morning
• Bad for users: sitebuilders and their sponsors now have a perfect crutch for keeping their sites in the Stone Age

Is the good worth the bad?

In the long run, I believe so… especially if guys like me step up to the plate and keep on educating people.

Opera and Microsoft: whither standards?

…Ummm, what Eric Meyer said.

Notwithstanding the very real progress made by IE7 in the bug resolution department¹, and notwithstanding Bill Gates’ very public declaration that IE.next is every bit the real thing, it would seem that Håkon Lie wants to pile on.

The part of me that’s still pissed off at Microsoft for three years of resting on its laurels — and only being stirred to act after uncounted Web standards advocates began attacking Microsoft publicly — is gleeful, not unlike the Normal Kid who feels some satisfaction after seeing someone stand up to the Class Bully.

However, this complaint misses the point. Forcing Microsoft to ship install binaries of its competitors’ titles (which is what I would do in their place, if ruled against and interested in good faith compliance) is the worst possible subversion of the marketplace. And then there’s what Eric said.

¹ I use conditional comments, but the stylesheets linked therein tend to number in the low dozens of lines (notwithstanding a production style that is generous with vertical whitespace). If I had to name two habits that make testing so easy, they would be box zeroing — i.e. * { margin: 0; padding: 0; } — and an approach that resolves hasLayout issues as a matter of course.

How many tags can I name?

A quickie online HTML tag quiz has been making the rounds. I got about half of the tags on the first pass, and almost three-quarters on the second — while forgetting many of the elements I listed during the first pass.

For guys like me challenges like this verge in some respects towards irrelevance, because…

When you’re using CSS for your presentation layer, you don’t need that many elements in your markup

Solid knowledge of CSS obviates a lot of elements, leaving the producer with only a few that are essential:

1. Document structure: html, head, title, and body
2. Document metadata: link and script
3. Headings: h1…h6
4. Containers: div, span, and p
5. Lists: ol, ul, dl, li, dt, and dd
6. Links: a
7. Emphasis and de-emphasis: em, strong, big, and small
8. Forms: form, input, select, option, and textarea

To that producers working on diverse projects might add a few more:

9. Images: img
10. Plug-in content: object and param
11. Quotes and sources: blockquote, q, and cite
12. Data tables: table, tr, th, td, and col

Once you open the book of document usability and cross-media accessibility, things start to telescope a bit:

13. Parent element metadata: legend and caption
14. Form control helpers: fieldset, label, and optgroup
15. Table containers: thead, tbody, and tfoot
16. Acronyms and abbreviations: acronym and abbr

…These three lists comprise 50 of the 91 elements officially supported in HTML 4, and the core of the namespace occupies only a third of the total.

What I omitted altogether, and why

• base and style

  You only truly need these elements if the behavior of your publishing platform encourages or requires it.

• applet

  The inline-Java train left the station in 1998, boys and girls.

What I relegated to the secondary lists, and why

• img

  A picture may be worth a thousand words, but it’s been my experience that on most sites, images rarely comprise principal content. Getting full mileage out of the CSS background attributes is often more structurally/semantically appropriate.

• legend and caption

  If you’re on top of your editorial game, these roles are often (though not always) handled by headings.

• fieldset

  This is too easily abused … hell, even I abuse it because there’s no easy way to sequester label-control pairs. I’m not convinced that the design oversight doesn’t make div equally applicable.

• label

  Have you ever noticed that this element is only truly useful if you have a pointer input device? Yeah, me too.

• optgroup

  Though not actually obscure, the scope of this element is limited to situations in which the best alternative would be to use empty options as separators.

• Table containers

  As currently implemented, these acquire their greatest usefulness in paginated media — so using them is simply a signal that you’re really on top of your cross-media accessibility game.

• acronym and abbr

  Between their relative obscurity, their uneven implementation across user agents, and their limited scope, these really cannot be considered part of a core toolset.

The point to this dissertation (other than the fact that I’ve often thought of prettifying it and submitting that prettified version to A List Apart) is that… folks, HTML ain’t rocket science, folks. At least, not by itself.

Thence the Email Standards Project?

Over the past 24 hours everybody and their first cousin seems to be talking about this e-mail thingy per the title. I'm going to read up on it in a bit, but…

It occurs to me that as a proverbial Neanderthal who still believes HTML has no place in e-mail, I find the whole idea to be a non-starter.

Let them eat attached PDF’s, I say.

Update, 45 minutes later:

I scribbled more (similar) opinions on the subject over at Zeldman’s.

Google as the new Microsoft, and what it might mean

[Much of what follows is speculative and based on my memory of things I’ve read online, mostly in blogs but less frequently in personal communications.]

I should be working, but a thought finally coalesced with respect to Google: they suffer from the same hubris that makes Microsoft so intolerable, similar not only in degree but also in character.

[As if to support my point, this item just turned up on my Twitter stream.]

By all reports Google is a great place to work, and despite its size still retains a hothouse vibe. Their decision to open a data center in the Columbia Gorge warms my native-Oregonian heart. It’s undeniable that some Really Cool S--t is finding its way out of Menlo Park. As it stands, the Web is better for the fact that Google’s in the marketplace.

However…

Google’s recent business moves, their defensive silence toward the community of Web standards advocates, the tone of their press and public relations — not least Eric Schmidt’s conniptions after he was thoroughly made by c|net on the strength of data provided by Google itself — and a small number of personal communications leave me feeling uneasy about the stamp that Google is bound to put on the Web.

Whether they realize it or not, Google’s gone out of their way to convince me that they know what’s best for the Web, doing so in a tone so paternalistic and annoying that my reaction can be best summed up in words of one syllable.

While I may be part of a tiny minority now, I’m certain that I’m not alone — and that I’m likely to be among climbing numbers of distinguished company as time goes on, if current trends remain in place.

A List of Bad Things I Don’t Want: Google Edition

• A monopoly market in the Web ad brokering space

  Yes, I know that there are other vendors out there, and some of them are doing quite well. I’ve even had one of them as an end client. However, Google stands by silently while the press insinuates that they’re in direct (and hostile) competition with Microsoft and Yahoo for brokerage market share — a silence which speaks quite loudly.

  This is a problem because: as the clear leader in search, and being the only one of those Big Three whom I can count on to really Get It and innovate (sorry, Yahoo, but that’s the writing I see on the wall, hooray for overly-deep orgcharts), I reckon it’s a matter of time before they have a commanding market share. With that outcome supposed, consider further that Wall Street loves revenue, and that Google’s rank and file have a personal interest in the health of their stock holdings. Given this intersection of interests and the lack of transparency about Google’s ad revenue payments to publishers, I’m discouraged by the thought of what might happen over time.

• Ubiquitous — if not inevitable — single-source toolkits

  For those of you who haven’t been paying attention, Google’s been working overtime to make pretty new toys for us Web developers. Google’s people are smart, and their tools are terrific, but what happens when those tools achieve ubiquity? I would think that all hell will start to break loose, security-wise.

  This is a problem because: monocultures are bad, yet Google seems quite happy to try and create some.

• Process opacity

  Google refused to yield on privacy issues. They maintain strict silence about details of subjects such as blacklisting and revenue payments to publishers. Despite experience and contacts, I know exactly squat about their application beta test process, and not for lack of keeping in touch. To be honest, when I consider those things I wonder if I’m looking at a company that has a Politburo rather than an executive team.

  This is a problem because: in a future where a single company has its hands into every page request, that company ought to be transparent to a point for the sake of the public good… but Google’s culture militates toward secrecy, a fact which is unlikely ever to change.

• Horizontal integration and/or presence to the point of absurdity

  Rather than focussing on “killer apps” Google is getting its fingers into every-damn-thing, and they’re not terribly shy about their intention to plaster their name on as much online real estate as possible. Whether we realize it or not, we as users are already forced to deal with Microsoft’s omnipresence on our desks. The last thing I want is for any company, even Google, to homogenize the Web in the spirit of Microsoft’s example.

  This is a problem because: in the long run it will hold the Web back by limiting the avenues along which innovation and creativity can move.

• Significant privacy-destroying design flaws in critical applications

  This is related to the fear of toolkit ubiquity outlined above, and to a degree my feelings on this matter are due to Google being a victim of its own success. People rely on GMail to conduct business, and in fact I may be cornered into doing the same thing before long. The prospect of Yet Another GMail Hole is the one thing that’s stopped me, though.

  This is a problem because: at the bottom line, it’s the same problem suffered by Microsoft — get enough valuable data or resources in one basket, and some unscrupulous and/or attention-whoring shitbag will go out of his way to ruin the days of several million people… in this case, using Google’s platforms and infrastructure to do it.

• A market environment in which one company can be coerced by any authority into surrendering personal data by the metric boatload

  Search, GMail, Desktop, Maps, Blogger, Analytics, and AdSense all provide data that in appropriately intelligent and resourceful hands can be used to conduct all manner of surreptitious surveillance. When I consider the attitude toward civil liberties of the sitting Presidential Administration, and further the precedent set by Yahoo when it rolled over for the Chinese government, I am deeply discouraged about Google’s ability — even given the best of intentions, and its public interactions with the U.S. Government to date — to protect its users’ right to privacy.

  This is a problem because: societies without effective safeguards of personal privacy melt down eventually, and Google is going out of its way to be part of the problem — in part because of the market it’s in, but also because of its own strongly-hewn culture of secrecy.

• “The standards are what we say they are, ’n y’all can just f--k off.”

  Microsoft’s already doing this, and has been for years with its foot-draggin’, platform-embracin’, interface-extendin’, market-assimilatin’, monopoly-havin’ ways. And here’s Google, twisting-spindling-mutilating the Web toolset and screaming from on high that that’s just they way it has to be.

  After more than five years of being called upon to live up to the requirements of being attached to the best-known Web standards advocacy organization on the planet short of the W3C itself, I am here and now calling Google’s position a steaming heap of lies — all the more because in search and ads, they are clinging to lowest-common-denominator implementation methods that actually retard market adoption of up-to-date platforms… in spite of the fact that they have literally hundreds of people in their organization who are far smarter than I ever dreamed of being. If I can make it work, and if I can imagine ways in which it can be made to work in environments I haven’t worked in, why can’t they?

  This is a problem because: the evolution of the Web will only move at a glacial pace (with respect to its potential) until both Microsoft and Google wise up. So, why is a company for which the first standing order is “don’t be evil” being part of the problem, rather than being part of the solution? In all cases save destructive mutation. evolution is a good (i.e., not-evil) thing, yet as part of the problem Google is stunting that evolution. Good job, guys!

• All of the above, plus willful ignorance of the wisdom of crowds.

  I’ve heard tell of many smart people who’ve been recruited by Google, which should not come as a surprise. What will surprise you is that the potential roles for these prospects were worked out by management before they were ever contacted, to the point that they were told in great detail what they would be doing if hired — not unlike a military officer being sent to a new billet. This speaks for some sort of grand vision on which the public’s not being let in, and that’s the part that really scares me.

  This is a problem because: any company that seems inclined to ignore its customers, preferring instead to follow an analogue of a Five Year Plan, is not a company I want anywhere near the Web that is my living and my link to the outside world. And I don’t give a damn how smart the people at that company are, if that’s how they wanna play it.

And before you cry “Godvinski!”

The more thoughtful among you have probably noticed that I’ve made two archly-put comparisons between Google and the Soviet Union. Part of that editorial position is by way of introducing an additional element of fear into my rhetoric, for sure. More to the point, however, years of private and academic study of post-1812 Russian history make the comparison too easy for me to make. Maybe I’m just seeing Sergey Brin’s stamp on Google’s culture and freaking out¹, but on consideration I see that as a bit of a stretch. There’ve surely been a lot of changes since Google brought aboard professional managers.

However, that Google reminds me of Russia² for any reason should by itself be instructive, even without the quasi-political subtext.

Conclusion

All of the points I outlined above, especially the last, leave me under the inescapable impression that Google thinks it knows what’s good for us, better than we do. Thanks to Microsoft we already deal with one company that’s foisted that view on its market, and we’re all familiar (to a greater or lesser degree) with the manifold consequences of that attitude. The thought that we’re letting it happen all over again is bothersome, to say the least.

Footnotes

¹As cultural traits go, mania for secrecy is pretty well a Russian one. All generalizations, comparisons, and contrasts aside, I really do hope that I’m looking at an absurdly misplaced but mostly harmless cultural artifact, and not some flaw in an important system (Google as a company) that could bring down the full smash to the detriment of the entire Web.

²Yes, I know better than to conflate Russia and the USSR, but in this instance I’m referring to Russia as the latter’s predecessor and successor state. Yeah, that’s me, being pedantic so that you don’t need to. You’re welcome.

Scribbles: benefits of Web standards

One of the ongoing discussions in The Biz has to do with the business benefits of {x}. Since I’m formally attached to the Web Standards Project, the {x} on my mind today (as on many days) is Web standards. (Betcha didn’t see that comin’.)

So… there are three ways I can think of to improve a process or deliverable:

1. make it faster,
2. make it better, and/or
3. make it cheaper.

For the sake of note-taking and reading aloud as much as any other, I’m writing to answer the implied questions as they relate to standards-friendly site development.

Web standards are faster because…

…The reduced overhead of standards-friendly markup improves load times — sometimes a little, sometimes a lot.

…That same markup improves the signal-to-noise (i.e., content-to-markup) ratio, resulting in content that’s easier to maintain.

…Given effective project management and sufficiently trained operators, standards-friendly processes and tools allow for narrower specialization by virtue of separation of content, behavior, presentation, and business logic. This in turn makes it possible to throw more people at projects in parallel.

Web standards are better because…

…They make feasible technologies such as Ajax and third party applications which can add depth to the user experience.

…The same separation and cleanliness benefits that can improve time-to-delivery and load times also simplify modularization and thus provide greater facility for extending sites and applications in lieu of redesigning them from the ground up to account for new features.

…Well informed use of CSS makes possible layout techniques that table-constrained producers and designers can only dream of.

Web standards are cheaper because…

…The same parallel production approach outlined above can be eschewed in preference to a serial approach involving smaller teams, reducing capital investment in projects down to a manageable rate. (This is one of the more important reasons behind my preference for small teams.)

…Modularization and cleaner production values at the code-and-markup level reduce maintenance requirements.

…Improved load times result in incrementally reduced investment in bandwidth and hardware.

Sounds great, but why the hard sell?

The only reasons these plusses do not make a slam-dunk case for Web standards are:

• increased testing requirements, and
• the need to re-train.

The more important of these issues is re-training, which is usually difficult, but not always difficult.

A wealth of resources such as w3schools, the MSDN Library, CSS Zen Garden, and A List Apart (among many) exist to bring along those who are just starting to learn about the current state of Web technology.

For those who need ongoing support in their education, css-discuss and other communities keep the fledgling learner in good company.

The rest of the re-training task is taken up in the course of actually doing, a process which culminates in the production of a site built entirely to the spirit, and quite possibly the letter, of established W3C Recommendations and other recognized best practices… entirely from arbitrary design documents.

Once an operator is properly trained, testing is simplified, because he or she will already have become quite familiar with many of the bugs and other pitfalls faced in the course of undertaking standards-friendly development. The others can — as a rule — be sussed out in community/form threads and, as a last resort, via search engine queries. I can speak for the effectiveness of both of these avenues for avoiding and working around browser bugs.

This leaves the conscientious project sponsor with two questions:

1. Who bears the cost to train my people?
2. How can I best make the switch?

The answer to the first question is somewhat academic, in part because your people will learn in the course of applying knowledge to their work on your projects, and elsewise because the added skill will make them more valuable to the marketplace. Either way, operators will rightly expect you to share some of the wealth gained from your improved bottom line. If you do not pay for formal training, you’ll only be putting off raises demanded either by your operators directly, or by the marketplace.

However, the share you give up from the improved bottom line will only be incremental; your organization will still enjoy the lion’s share. This is a fair expectation because among other benefits, your people will experience fewer hassles and less tedium in their jobs (all other factors being equal).

The answer to the second question is more complicated, because you've essentially got two choices: either go cold turkey from one approach to the other, or travel slowly.

Of these the latter offers the least aggravation for all participants. If you can start with some smaller projects — e.g., product marketing microsites and internal applications — you can set up your operators to act on what they’ve been learning, while simultaneously reducing the risk to your bottom line.

The reduced risk does not automatically translate to reduced hassle or delays, but when people are being trained, when is that ever the case?

One other contingency: transitioning from the contract build to ongoing maintenance

Let’s suppose you hire some hotshot hired gun (like, uhhh, meeeeee!) to equip your site with the newest, shiniest standards-friendly bells and whistles. Let’s suppose further that your fulltime Web team can’t tell asses from elbows when it comes to Ajax or CSS. What then?

This scenario requires multiple remedies.

Excellent documentation

Exhaustive explanation of the template, stylesheet, and code structures used during the design of the project is a must-have.

Onsite training

Somebody should come onsite and put your team through an ad hoc boot camp. Alternatively — if your hired gun isn’t especially facile at public speaking — there should be an internal forum or mailing list set up for the benefit of maintainers, along with contractually defined support requirements. This turns your contract team into little more than a glorified helpdesk, and they may choose to refer some other team for the job. The bottom line is that untrained people will have questions — and lots of them. Someone should be on tap to answer those questions.

Effective management

Project and department managers with the communication skills required to successfully track and define problems at the appropriate level — who have a clear idea of the obstacles their people are facing — can make the best use of the time and other resources spent to ensure that the problems are solved.

In short, Web standards adherence is an endeavor that rewards those with initiative. Why not become one of them?