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.

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?

Web pet peeves

[I first posted this on 21 October to Chapel, where I’ve blogged sporadically for quite some time. It belongs here, too. I’ll still be posting the really weeeird stuff over there, because that’s what it’s for.]

I ran into a major Web pet peeve and posted it to Twitter, in the process remembering that I have several others (a few of which I spent all afternoon working around)…

• Web sources cited by mass media outlet content that don't link directly to them
• e-commerce sites that break at ANY point when you’re using a browser other than Internet Explorer
• e-commerce sites that don't create a semi-permalink to a customizable cart item
• any application that breaks the instant you press the Back button, without warning you in advance of the consequences of doing so
• failure to provide range selection support (beyond “check all”) for series of checkbox selection inputs (e.g. mail inbox)
• applications that crash on purportedly tested platforms
• process-critical services and applications that do not have a System Status resource
• sites and applications that treat content sections like static search results
• project sponsors who fancy themselves graphic designers despite a total lack of training and experience
• ads with sound on otherwise silent sites
• categorically, ads that talk
• news and social linking sites that toss resources down the memory hole without consequently returning a 410 (Gone) status code along with the title of the clobbered resource (or at least some indication that something formerly lived there)
• applications that enforce user behavior by limiting choice in a bizarre way (here’s looking at you, Facebook Status)
• sites that are only useful if you pay, yet imply otherwise in their create-an-account pitch
• anyone anywhere in any context asking how to “hide” source markup and things of the like
• anyone anywhere in any context believing that because their fucking nephew can “make a web page” in twenty minutes, they’re entitled to a full custom e-commerce site for a few hundred bucks…
• …and contrapositively, anyone who bilks the clueless out of thousands at a time for crap they build in twenty minutes with Flash or Dreamweaver
• anyone who thinks that just because they’re entitled by the right to free speech to an opinion, they really just ought to share it, despite the stench of banality and/or thoughtlessness it emits
• anyone who mistakes ignorance for willful malice
• anyone who mistakes obstinacy for courage
• anyone who thinks it’s okay to be narrow-minded about the narrow-minded

Aaahhh. Now I’m done.

If you bear any witness to irony, by all means bask in it.

Web 2.0, traditional IT, and Chicken Little ledes

From InfoWeek by way of Slashdot, there's word that Web 2.0 technologies threaten the control IT has traditionally had over info management in the enterprise. The content’s solid, though the editorial slant’s annoying,

For the first time in three years, I’m actually blogging under my own banner.

Maybe I’m being impulsive, but what the hell.

It's time for me to start writing again without delay... mostly about Web-related topics, but there are others on my mind, too.

The item at the bottom of my to-do list for the past three years has been a publishing platform far more sophisticated than the one I built for my Illuminati Online site from back in the day (disable JavaScript before going to the actual content, if you’re really that curious), and my intent has been to write it before going back into regular blogging.

Meanwhile, life is — as they say — what happens when you’re not paying attention.

The good news is that I now have a client willing to finance that work in part (I think). The bad news is that my urge to bloviate has overtaken the march of time.

...So here I am.

Where is that, exactly?

First, some background

There was a stretch of about eighteen months where I had my heart ripped out of my chest repeatedly if only proverbially, most significantly by the unexpected death of my mother from cancer.

Nearer to the end of this spell I moved from Portland to the much different (if not necessarily greener) pastures of Lawrence, Kansas, encouraged by a few now-erstwhile friends.

A move away from Portland was something I was already planning when Mom fell ill, though how ill she’d become wasn’t at all understood until a week before she died.

In Portland, memories would be redolent on the air at every turn.

I have a good enough memory that I do not need to be reminded of the stretches of the lower Valley where I spent the years of my childhood that passed before interacting with my mother became an exercise in supreme patience. All I need to do is close my eyes and concentrate. The sights and sounds of memory will return on demand, vividly enough to make me cry.

No less difficult is recall of the sights and sounds of the afternoon during which I travelled to the hospital, trudged up to the ICU, told Mom — by that time so immersed in pain and the drugs meant to manage it that she could no longer see — that I would be okay and that she could let go, and then only moments later watched her do exactly that.

[...And the conversations I had with my grandparents that afternoon were even more poignant. Let’s not go there.]

That I would willfully choose to remove myself to the oh-so-cosmopolitan place known as Kansas was a mystery to practically everyone with an opinion. Everybody asked what my deal was, so to speak, and my response to everyone was if it was good enough for William S. Burroughs to die in, it’s good enough for me to live in for a while.

Apart from the previously mentioned encouragement and personal considerations too private to lay out in detail, there was the fact that at the time of my decision, I had an outside hope of obtaining a job with the online division of the local paper.

Northeast Kansas had (and still has) the virtues of being 1500 miles from my mother’s family, which became far less dysfunctional after her death but still has more issues than I want to deal with.

[...And lest you wonder, yes, I would move back with dispatch — and some ambivalence — if asked to do so.]

I had attended both high school and college in Columbia, Missouri (during and after my father’s graduate study in American history at the latter institution), which gave me insight about the values and virtues of the area. I knew Lawrence quite well by reputation.

To me, the choice seemed like it had possibilities.

The whole point was to get over myself already in a place where I would be able to steer clear of drama.

...And now?

After more than three years, I know I need to gear up and move on. As years go, 2007 has been full of questions and fears in full measure: is this all there is to life? For the sake of my own health, the answer to that question needs to be a resounding NO! If I stay in Lawrence too long, however, that's not the answer I’ll get in practice.

Having an apartment that I can stand to live in by myself has proven to me how far into my proverbial shell I can go, and at the heart of the matter I am neither young nor parochial enough to get the most out of Lawrence.

I need badly to raise my bill rate (or so I’m told). I need to go legit on software and paperwork. I need a car. But most importantly I need to start connecting with people around me, and starting a new blog is part and parcel of that task.

Beyond the demands of maintaining my own good mental health, I am forced to concede that so much has changed in the past three years. RSS and social networking have come into their own, which makes resource collection fractionally as difficult as before. The maturation of production processes for latest-gen browsers has begotten a lot of conversation in which I’d like to take part, and the evolution of Wikipedia has reduced the hassle of link research. All of these things together mean that blogging is a lot more fun and productive than when I was last into it.

So... "Hello, World!"