October 2003
Wednesday, 1 October 2003
I think I've been semi-Slashdotted. Having one's site mentioned in the comments associated with a post isn't as good as having a whole post about your book, but it's probably still driven a lot of traffic this way. So howdy, Slashdotters! Hopefully this will also drive a little more traffic to my standards-oriented consulting business, Complex Spiral Consulting. Ser Zeldman is right on about the shift in tone over at Slashdot when it comes to standards issues. It's a nice change to witness. This may be one more bit of support to my claim that Microsoft didn't win the browser wars: standards did.
Mac OS X folks should delay not a moment longer their introduction to xlab, which I found thanks to Jeremy Keith. xlab is chock full of tips and pointers, and it looks clean and attractive to boot. And is that a CSS-driven layout I spy? Why yes, I believe it just might be.
For those who were thinking about asking, I won't be sharing with you what's in my Dock. This is partly because I keep it on the left and so it's very tall, and I don't want to waste that much space. It's also because I'm getting very close to dumping the Dock in favor of a registered copy of DragThing, which I use on my Classic OS machine and sorely miss in OS X. The Dock just doesn't have enough features to be an effective replacement. If people indicate an interest, I suppose I could talk about OS X tools and widgets I find useful. Otherwise, I'll stick to the usual foolishness that passes for witty discourse 'round these parts.
Thursday, 9 October 2003
Today I received my first Complex Spiral paycheck. Yay! I've done several paying jobs by now, and more are underway, but this is the first check to actually show up for deposit. Let that be a lesson to those of you who might be thinking about striking out on your own: if you can't cover all of the expenses you'll incur between leaving your old job and the point two months after you finish your first project at the new job, you can't afford it.
Yesterday, the mail brought to me a package from New Zealand. It contained a copy of the Digital Life episode on Web standards. That was especially fascinating since this morning an article on standards support (and the limits thereof in Internet Exporer) was published on c|net quoting me, Zeldman, and others. With Explorer's development at an apparent end, it's becoming a heavier and heavier millstone around the necks of designers. Let's assume that there are no advances in Microsoft's Web standards support between now and Longhorn. That's close to three more years of the millstone getting heavier. By then, we'll all have serious back problems.
(Yes, I can count: Microsoft's Longhorn launch date of 2005 says to me it'll actually launch in 2006. I'm just drawing a historical inference here.)
Of course, the whole Eolas situation probably doesn't have the Microsoft folks in a benevolent frame of mind regarding standards. If they just abandoned the public Web and moved everything into a closed, proprietary sandbox of some kind, they might be able to avoid these sorts of problems altogether. That's exactly what I expect them to do in Longhorn, and the expectation worries me. If the whole world moves into the sandbox—and let's face it, in an e-commerce sense, IE/Win is the whole world—what reason would there be to pay any more attention to the Web?
We might say hey, fine, let's get Microsoft and its partners the hell off the Web so we can go back to developing it the right way; let's take back the neighborhood. That would make about as much sense as rooting for Flash to be the technology used on every Web site in existence. When one company owns the medium, everyone else loses. Thus far, the Web has been a community asset, with no one company calling the shots. How can we make sure that situation continues past the next few years?
Monday, 13 October 2003
I often wonder how much effort goes into picking the music played in public spaces. Do the people who assemble these societal soundtracks just pick their favorites, or a random assortment of whatever they can find, or is there an enormous amount of thought and effort and psychological analysis put into the selection?
And if there is, in fact, a lot of thought put into the process, then who in the name of Bob thought it was a good idea to have the song "Knockin' on Heaven's Door" played through the speakers at the Cleveland airport? And then, half an hour later, "Sunday Bloody Sunday"—on a Sunday?
I thought it was hilarious, but there are those who are already so stressed about flying that they'd probably verge on having a coronary.
Wednesday, 15 October 2003
Doug Bowman's observations on the separation of presentation and content are well made, and illuminate an oft-overlooked corner of the whole standards debate. Even with some semantic correction, we still have room for discussion.
My semantic correction is that we aren't trying to separate presentation and content, but presentation and structure. Doug makes this point throughout the latter part of his post, but I think this is the important thing to state right up front. Without content, it's very difficult to have any presentation, except maybe a blank browser window (very minimalist, but not necessarily useful).
Even there, however, the divorce is not complete and never can be. I've been saying this in public presentations for a while now, and it bears repetition here: you can have structure without style, but you can't have style without structure. As Doug observes, you have to have elements (and, also, classes and IDs and such) in order to apply style. This is absolutely the case, and it should come as little surprise, really. If I have a document on the Web containing literally nothing but text, as in no HTML or other markup, just text, then it can't be styled. Presented, yes, using the browser's defaults for showing raw text. But not styled.
This is also why I've argued that the document structure is dependent on your presentational needs. Document structure is like the support beams for a building. The final layout and appearance of the building will depend very heavily on the shape those support beams create. If you ignore that, and assemble the beams with no thought toward the final product (not following the blueprints, as it were), the best you can hope for is an inefficient, almost unusable building. In the worst case, the building will utterly collapse as soon as you try to add anything useful to the structure.
This has been a minor issue in HTML, but XML throws the issue into sharp relief. Consider the following fragment of XML:
<city name="Cleveland" state="Ohio">23</city>
Okay... any idea what that number represents? No, probably not. What's worse is that if I hand that element to a user agent, it will display the element's content: 23. The user won't even have the attribute values to give them what little hints you got by looking at the source. They just see the number 23.
That's because attribute values don't get displayed, while element content does. Yes, we can use CSS generated content to make the attribute values show up, but how crazy is it that the following would be needed to make the display more useful?
city:before {content: attr(name) " " attr(state) ": ";}
And then, if you wanted to make the bits of data lay out like a table—you can't. Oh, sure, you could get the generated content into one layout piece, and the element content into another, but you can't get the city name and the state name into separate cells. Even if you could apply display: table-cell to the generated content, you can't split it into different cells.
We can argue that this illustrates limitations in CSS, and to a degree that's true, but to do so misses the point entirely. There will always be some limitation we can't overcome, something the styling language of the moment can't make possible. What I'm talking about is the fact that presentation is inextricably bound to structure, and document authors ignore that connection at their peril. Let's return to that XML fragment and restructure it to be more intelligent:
<city region="midwest">
<name>Cleveland</name>
<state>Ohio</state>
<hightemp scale="c">23</hightemp>
</city>
Now, not only do we have more actual content to be displayed by default, but we have more elements to actually style. So we might turn the above into a table-like structure, complete with some useful cues for the user, like so:
city {display: table-row;}
city > * {display: table-cell; width: 33%;}
hightemp[scale="c"]:after {content: " degrees Celsius";}
hightemp[scale="f"]:after {content: " degrees Fahrenheit";}
Now, thanks to our structure, we can make the display much more useful for the user, and understand it better ourselves. We can even style the city and state differently now, whereas before that was impossible. We've also been able to use an attribute value to affect presentation. I included the attributes to show that attributes aren't at all useless, or even have to stay completely out of the presentation. They can be quite handy. However, the region attribute is a good example of data that has to be carefully considered. If we ever want to display a city's region next to its name, then it's probably a good idea to use an element (like <region>...</region>) instead of an attribute. If we just want that information in the data structure for purposes of transformation, or to style descendant content without actually displaying the region's name, then an attribute makes far more sense. For example:
city[region="midwest"] {background: green; color: white;}
city[region="northeast"] {background: purple; color: white;}
If we're going to do that kind of thing, treat the region almost like it's a class, then we definitely want it as an attribute. If it were an element, with the region name as content, we'd have no way to style it (or anything else) based on its content.
What it comes down to is that structure is critical to presentation, with or without the style—although intelligent structure makes styling lots easier. Contrary to what some may have claimed or implied, you can't just create an arbitrary structure with no consideration toward its presentation. If you want something on the screen, it needs to be element content. That may not be ideal, but it is inescapable. Structure may be able to break up with style, but style still needs and depends on structure in a big, big way. Personally, I'm not sure it can ever be otherwise.
Wednesday, 22 October 2003
Off the road again: I'm back from User Interface 8, where a good time was (once more) had by all. Especially me. I don't know exactly how I ended up with good-looking women in my lap so often, but I don't think I'll complain about it too much. I have a huge collection of pictures that cry out to be shared, and a huge lack of time to assemble a gallery. I could use iPhoto's export-to-Web function, except I hate it. I'll have to dig up one of those cleaner plug-ins I've been hearing about and give it a whirl.
To catch up things that happened while I was away:
-
A List Apart is back. That in itself is cause for celebration, even if my article "Going To Print" no longer makes sense in the new template. However, the real news from where I sit is the publication of "Sliding Doors of CSS" by the always brilliant and readable Douglas Bowman. Check out the presentation, HTML source, and text-zooming robustness of this demonstration page from the article, and then read the article if you're impressed—as I suspect you will be. I'm seriously thinking about publishing a followup article to "Rounding Tab Corners" using Doug's Sliding Doors technique, and comparing it to the techniques presented in the the original article. Some have said that Doug built on my article, but that's not true. He came up with his approach independently, and if anything I'll be building on his ideas, not the other way around.
-
Russ Weakley published the Floatutorial, which "takes you through the basics of floating elements such as images, drop caps, next and back buttons, image galleries, inline lists and multi-column layouts." It does this with a simple yet powerful step-by-step approach that reminds me a bit of Eric Meyer on CSS, except it's much more concise. The Floatutorial joins the Listutorial in Russ' oeuvre.
- The House of CSS (not to be confused with the House of Style) opened its doors, and the crowd went wild. I like it. Sure, it's a whole lot of structural hacking to achieve a purely visual effect, but so what? I didn't think of it, and neither did you. Or if you did, you didn't bother to assemble it. Chris Hester did, and he deserves recognition for the creativity and skills it took to do so.
- Apparently Microsoft's recently started admitting that Longhorn will launch in 2006, as I predicted a few weeks ago. A few people wrote to ask if I'm always so prescient. The truth is, it didn't take an oracle, a guru, or a clairvoyant to figure out that Longhorn was likely to be delayed by a year or more. As I've been known to say every so often, the best predictor of future behavior is past behavior.
- In a possibly related move, Microsoft has apparently decided to save time by releasing their critical-flaw fixes in groups, or what I'm going to start calling "patch batches." You know what to do, right?
For no apparent reason, I've had the song "Rhinestone Cowboy" stuck in my head all day. Even a potent cocktail dosage of Ministry, Joe Boyd Vigil, Crystal Method, The Prodigy, and DJ Z-Trip has failed to dislodge it. I'm starting to think that a power drill is my only hope.
Friday, 24 October 2003
I was going to talk about the CSS class I start teaching tonight at Cuyahoga Community College. That's been trumped.
Microsoft blogger Ryan Dawson spent a little time talking about XAML last night. What's XAML?
The quick and dirty: XAML is a way to create applications in the browser (or out for that matter). For example, imagine a text editor with the rich UI of Windows, but portable in the browser. XAML doesn't even have to be an application; it could be your existing website in a more structured manner.
The quick and dirty (2): It is basically an XML structure with CSS and JavaScript. The CSS defines the appearance and the JavaScript dictates behavior.
Go read it. I have some thoughts, many of which have been stewing for a while, so come back if you're interested.
(...pause to idly wonder if XAML is pronounced "zammel" or "camel"...)
Okay. This all looks fantastic, although it's less groundbreaking when you realize Mozilla already did it with XUL ("zool," in case you were wondering, just like in Ghostbusters). Think of it: a rich development and Web services environment built entirely out of open technologies like XML, CSS, JavaScript, and so on. It's like a dream come true.
Then again, maybe it's a nightmare. I said in "Checks and Balances":
...the whole Eolas situation probably doesn't have the Microsoft folks in a benevolent frame of mind regarding standards. If they just abandoned the public Web and moved everything into a closed, proprietary sandbox of some kind, they might be able to avoid these sorts of problems altogether. That's exactly what I expect them to do in Longhorn, and the expectation worries me. If the whole world moves into the sandbox—and let's face it, in an e-commerce sense, IE/Win is the whole world—what reason would there be to pay any more attention to the Web?
We might say hey, fine, let's get Microsoft and its partners the hell off the Web so we can go back to developing it the right way; let's take back the neighborhood. That would make about as much sense as rooting for Flash to be the technology used on every Web site in existence. When one company owns the medium, everyone else loses.
These thoughts were largely fueled by rumors I'd been hearing over the last few months; those rumors were obviously about XAML. I also wondered if Dave Winer had been hearing similar rumors when he made his famous "locked in the trunk and going over the cliff" comment about the Web.
Remember, this is a very large corporation we're talking about here, never mind that it's Microsoft. They will develop technology in a way that increases profits. Their goal is pretty obviously is to build rich capabilities directly into Longhorn, so that Windows users get all kinds of cool stuff for "free." Picture it: when you open the "Search" application and type "flights from Cleveland to New York," it returns airfares for you right there in the search results box. But from where are those airfares going to come? Orbitz? Not bleeding likely. How about Expedia? Yeah. Just maybe.
Now, think about searching for a band like Our Lady Peace. You get links to fan sites as well as links to buy their albums. Who's going to supply those e-commerce links? If I were a betting man, I'd say a Microsoft partner. In hotly contested e-commerce sectors, the bidding wars over those partnerships will be outrageous. Microsoft gets the best of both worlds: a transaction fee for purchases their OS users make in the Longhorn Corral, and whatever money Amazon or Buy.com or whoever pays them just to have the chance to pay them transaction fees on those sales.
Now consider the issue of who will supply news links, which can lead to major ad revenue when users follow the link to a story. MSN is the obvious venue, of course, and whoever's partnering with them gets their ads on the Longhorn desktop. So when it comes to sports scores and headlines, for example, ESPN is pretty set up—as long as they can stay a partner. How much will that privilege cost them in five years?
And where will AOL be then, now that Netscape is effectively dead and Mozilla's been spun off? As Dave Shea wrote from 2009, "AOL executives surprised to discover 'foresight' carelessly crossed out of their dictionaries." More recently, Simon Willison said:
On the negative side, this looks set to represent the ultimate browser lock-in - in a few years time when IE 7 comes as standard on new PC s I wouldn't be surprised to see the corporate software development world moving almost exclusively to this technology - after all, it's going to be extremely easy both to develop and to distribute and it will have all of the benefits of a web application without the downside of the restricted GUIs offered by HTML.
Exactly so. Microsoft, having learned what it needed to know from playing in the public Web space, is now positioning itself to pick up all the e-commerce and go home.
Permit me to repeat myself: "When one company owns the medium, everyone else loses." Everyone from design firms to tool vendors to browser makers will have to dance to Microsoft's tune. We have until about 2007, maybe 2008, to prevent that from happening. Can it be done? How? By whom? If XAML lives up to its potential, Microsoft won't need the W3C any more. Why should they play by the open community's rules when they can create their own very lucrative and highly controlled gated community?
I want to be wrong. I want to think that XAML will be open, interoperable, available for anyone to hook into whether or not they're a partner or Longhorn developer. I want to believe that Safari and Mozilla will be able to surf the XAML sea just as effectively as Explorer. I also remember my history, and the past behavior I recall doesn't bode well for the future.
I'll admit that a lot of my concern is self-interested. If XAML locks up the Web, then I've got a lot of scrambling to do. I can very likely stay employed, since CSS is apparently a big part of XAML, and probably do pretty well for myself. I'm not sure if my heart would be in it, though. One of the things I love about the Web is its big, sprawling, open nature. I've fought against fragmentation for years; I've been fighting the open standards fight for longer than I care to remember—for longer than a lot of you have been working with the Web, in fact. That all stands in jeopardy now. I may, at long last, be caught in the crushing, extending embrace.
If that's so, I suppose I'll have plenty of company.
Saturday, 25 October 2003
Robert Scoble has said that Ryan Dawson isn't a Microsoft employee, which I all but said he was in my last post. Robert also said that Ryan hasn't seen Longhorn, and thus can only be making guesses about it.
My apologies for the misunderstanding concerning Ryan's affiliation, and the nature of Longhorn Blogs, which I had taken to be a Microsoft-sponsored site. It isn't; it's a community site where anyone can get a blog and start posting. Presumably about Longhorn.
As for the rest of my post, where I expressed my concern over what might happen in Longhorn and how that might affect the Web, my thoughts were not based solely on Ryan's post, but were instead the end product of several months of thought and information from a number of sources. If anything, Ryan's post was simply the trigger that got me to fully express them in public. I hope to one day be able to point back to that post and say, "Wow, was I ever off the mark there." The nature of speculation is that it is often proved incorrect, and I can accept that if it happens. I'd far, far rather be wrong than right in this case.
Regardless, we'll get our first taste in a few days. It will be interesting to see what people think. It'll be even more interesting to see if Longhorn is limited to Intel architectures or not.
Sunday, 26 October 2003
I'll return to the Longhorn/XAML thing when we know more, hopefully tomorrow, from Microsoft itself. In the meantime, I have two more license plate sightings to share, because that's the kind of thing I do. The first was another shade of purple: AA65EA. I realize all the standard Ohio plates that correspond to hex colors will be varying shades of purple. They're still rare enough to merit my attention. I keep hoping I'll see a web-safe license plate, but that's a fairly long shot.
As for the second plate, it was J CHRIST. Turns out the Big J drives a black Pontiac Grand Am GT. Who knew?