Posts in the Tech Category

A fair portion of the feedback I get whenever I talk about microformats runs along the lines of “How is this any different from stuff like RDF, besides it being written using a far less structured vocabulary?”.  Tantek has laid down the basics of the answer to that question.  In a severely limited nutshell: the more visible the data, the more likely it is to be made relevant and to be kept that way.

What about search engine spamming?  Well, it’s usually easily recognizable as such by a human, so that’s in keeping with visibility and human friendliness.  If we suppose a spammer uses CSS to hide the spam from humans, as many do, it’s become invisible—exactly the same as traditional metadata, and exactly what happened to meta-based keywords before the search engines started ignoring them.  Some day (soon?) the search engines may start ignoring any content that’s been hidden, and as far as I’m concerned that would be just fine.

Now, what about farther down the road—will semantic information always have to be visible?  An interesting question.  Tantek and I have had some pretty energetic arguments about whether the kind of stuff we’re putting into microformats will eventually move into the invisible realm of Semantic Web-style metainformation.  As you might guess from his post, Tantek says no way; I’m more agnostic about it.  Not every case of structured data lends itself to being visible, and in fact making some kinds of strucuring data visible would be distinctly human-unfriendly.  There’s a reason browsers don’t (by default) display a page’s markup.

Besides, to some extent there’s invisible information in microformats, although it’s pretty much always tied to visible information (dates in hCalendar being one such example).  Sure, the class names and title values are there in the markup as opposed to off in some other file, but from a user point of view, they’re as invisible as meta keywords or RDF.  Usually it’s stuff we don’t want to be in the user’s face: markers telling which bits of content correspond to what, ISO versions of human-readable dates, that kind of thing.

Then again, the truth is that the kind of information most people want to consume and manipulate is the kind of information that lends itself to being visible.  Structuring that data in such a way that the same data is useful to both humans and machines—turning the stuff you’re showing to people into the stuff that machines process—is a much more elegant approach, and one that frankly stands a higher chance of success, at least in the short term.

(A quick example: as Andy Baio says, “If hCalendar gets popular, Upcoming.org could scrape events off of websites instead of people entering them directly into Upcoming”.  Bands, who are already maintaining their own touring pages, could mark up said pages using hCalendar, and Upcoming would just suck in the information.  The advantages?  The band’s webmaster doesn’t have to set up the tour page and then go enter all the information into Upcoming; he just creates or updates the page and can then ping Upcoming, or wait for its spider to drop by.  The visible information, which is structured in a machine-parsable way, only has to be updated once.  Of course, the same would be true with regard to any event aggregator, not just Upcoming, and that’s another advantage right there.)

But will the semantic information stay baked into the visible information?  That’s a harder trend to forecast.  I remember when presentation was baked into the structure, and it’s been a massive struggle to get the two even partially separated.  On the other hand, it makes sense to me to pull presentation and structure apart, so that the former can rest upon the latter instead of having them bolted together.  I’m not sure it makes sense to do the same with semantics and structure.  Of course, what that really means is that I don’t think it makes sense to argue for their separation now.  Perhaps we’ll look back in a decade or two and, with new approaches in hand, chuckle over the thought that we’d ever bolted them together.  Alternatively, perhaps we’ll look back from that vantage and wonder why we ever thought the two could, let alone should, be separated.

In either case, it seems clear to me that the way forward is with visible data being used both for human and machine consumption; that is, with the microformat approach.  It’s a lightweight, easily grasped, infinitely extensible, and infinitely flexible solution, totally in keeping with the design principles that underpin the Web itself.

• Long-Term Visibility was published on Friday, June 10th, 2005.
• It was assigned to the Microformats and semantic web categories.
• There have been two replies.

I go to England and Apple launches the switch campaign to end all such campaigns: moving from IBM’s PowerPC chip to Intel architecture.  Coincidence?

Pretty much, yeah.

I know that a zillion electrons have been spilled on this topic, and I’m going to add my own thoughts without the benefit of having actually read what anyone else has said about it.  So if everything I say here is a duplication of everyone else’s writing, it’s at least an original duplication, if you see what I mean.

At the core (Ha! I kill me!), it shouldn’t really matter what chip sits at the heart of a Macintosh.  Did it bother me when Apple switched from Motorola’s chips to the PowerPC?  No.  I’ve historically been far more bothered by changes in interface, like the jump from OS 9 to OS X.  I have made that transition, but it took me a long time and I still sometimes pine for the old days.

Regardless, it does seem to bother me at some level that I could be running an Intel-based system in the semi-near future.  Maybe it’s all those old jeering comments I made about fundamental addition bugs and excessive heat production coming home to roost.  Maybe it’s that the hipper-than-thou, apart-from-the-crowd semi-cultishness of the Mac extends down to the hardware layer: now instead of having l33t hardware that I paid good money to get, I’m merely going to have a different OS on the same basic computer as all those boxes out there running Windows, pardon my French.

These are emotional reactions, and I admit that freely.  But emotion is bound up in anything we take seriously, and given that it’s the tool with which I create personal wealth, I take my computer very, very seriously.

I’ll step back from that, however, and look at this with a larger field of view.  Apple has apparently been maintaining Intel versions of OS X for years now, so it isn’t as though they still have to undertake that conversion.  There’s a PowerPC chip emulator called Rosetta that should smooth the transition of software to the new architecture.  Sure, the stuff running on the emulation layer won’t be as efficient as software written natively for Intel architectures, but it’s a whole lot better than nothing.  (And also makes me wonder why it’s been such a long, hard trip getting a Mac emulator for the PC.)

Here’s the thing, though: this potentially brings the ability to run OS X to the ninety-plus percent of the computing world that has an Intel machine, of which ninety-plus percent are running Windows.  The success of iTunes for Windows has demonstrated that Windows users don’t give a flip who wrote their software, as long as it gives them something they want and is easy to use.

So the move has the distinct potential to play to Apple’s strengths as a software developer.  It could put the whole iLife suite on desktops everywhere through Intel-compatible OS X or even some other route.  It could make it easier for Apple to create a Windows-compatible version of iLife.  It might (though I can’t be sure, not being a developer) make it easier for Windows applications to be ported to OS X, thus making switches between Windows and Mac OS a lot less painful.  It might even make it possible to have Windows running on Apple hardware, and it’s darned sure going to make VirtualPC a lot less virtual.

I freely acknowledge that most users, even given a choice, will pick the classic Wintel combination—how many buy Linux-driven Intel machines these days?  (Yes, it’s more than before, but still not that many.)  How many more would buy non-Apple OSXtel machines, even assuming such a thing to be possible?  Not many.  A lot of the cachet of being a Mac user is having the super-fine hardware, all sleek and well-designed and a heck of a lot sexier than the guy running a Dell Latitude or whatever.  (Yes, some PC makers do go sexy, but they’re usually either trampy ripoffs of Apple’s designs, tricked-out Alienware gamer boxes, or Sony Vaios.)

As I said at the outset, intellectually I don’t care whose chip drives my Mac, so long as my programs still run and the performance isn’t slower than I’d have gotten with the PowerPC chip.  Emotionally, though, I’ll be breaking my long-standing rule against decorating my computers.  After all, I’ll need something to put over the “Intel Inside” sticker.

• Apple Intel was published on Wednesday, June 8th, 2005.
• It was assigned to the Mac category.
• There have been ten replies.

I think that, overall, the workshops went very well indeed.  Probably the most frustrating thing was that the hotel lacked net access for the entire time I was there.  Oh, they had a network, with drops in the rooms and a first-floor wifi cloud.  It’s just that the network was completely broken for the entire five days, save a two-hour window in the middle of one of the days.

But that annoyance aside, everything else was great.  The attendees asked a lot of interesting questions and soaked up the firehose of information I was blasting their way.  There was some good (and good-natured) give-and-take on the subject of tables versus CSS for layout, with plenty of examples of where each approach might be better or worse than others.  And hey, I wore a tie!  Both days!  Ryan has the picture to prove it!

He also has the British spelling of “favorite” to prove that he’s been away from Colorado for too long.

Anyway, I’d like to send a huge thank you to everyone who attended for making it a great experience.  I had fun, and I think you did too.  Now for two bits of trivia about the attendees:

• The quiet, bearded man who sat house right in the third or fourth row on Saturday was none other than Michaël Guitton, a significant and early contributor to S5, the slide show system I used to present the morning notes.  I didn’t find this out until the end of the day, or else I’d have made him stand to take a bow.  (Which might be why he waited until the end of the day to introduce himself.)

  He was also the only person at lunch to order the salmon, although I came very close to doing so myself.

• On Friday, as a number of us headed up the street for social hour, one of the attendees mentioned he’d been in Cleveland and Columbus many years ago.  I asked what had brought him there, and he said he’d been touring with a band.

  “Oh, really?” said I.  “That’s cool.  Um, any chance it’s a band I might have heard of?”

  “The Jesus and Mary Chain”, he said.

  “WHAT?!?!?”

  I had to ask him three times if he was having me on.  Turns out he wasn’t: I was talking to Dave Evans, who was their guitarist in the late 80s.  Seriously.  I could not make this up even if I tried.  I really had a former member of the Jesus and Mary Chain in my CSS workshop.

  That’s so far beyond incredible that I can’t even describe where it ends up.

• Workshop Wrap-Up was published on Wednesday, June 8th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been six replies.

The other day I hit a situation that pushed me to come up with a way to simulate the child selector in a way Internet Explorer could understand using two rules.  I doubt I’m the first to think of it, but I’d never seen it before, so I thought I’d document the solution here.

The deal was that I had a column of text featuring white background with some black flecks in it.  On top of that went some near-black text.  All fine, except where the text sat on top of a fleck, which made it next to impossible to read.

To counteract that effect, I decided to set the background of the various descendants of that div to be white, so they’d mask any flecks they were overlapping.  Thus I wrote:

#main * {background: #FFF;}

It worked great for about a second.  That’s when I realized that I had links in the column, and some of them were sitting inside table rows with a non-white background.  The rule I’d just written was giving the links white backgrounds, which had the visual effect of punching holes in the row backgrounds.  That was no good.

What I really needed was a way to just set white background on elements that were children of #main.  CSS has a child selection combinator (>) but neither version of Internet Explorer supports it.  After a few moments’ thought, I realized that I could add a rule that would make transparent the background of any element that was at least a grandchild, but not a child, and it would still work in Explorer.

#main * {background: #FFF;}
#main * * {background: transparent;}

The end result is that there is a way to simulate child selection without actually using the child combinator.  The general pattern is to use a normal descendant selection in your first rule, and then “undo” the first rule with a second that has a universal selector in the middle.  Suppose you want to boldface any p element that’s a child of a div, but no others.  The solution:

div p {font-weight: bold;}
div * p {font-weight: normal;}

It might not be something you use every day, but if it’s needed, there you go.

Update: Lachlan points out that you’ll need to watch out for specificity conflicts when using this technique.

• Universal Child Replacement was published on Tuesday, May 31st, 2005.
• It was assigned to the CSS category.
• There have been thirty-five replies.

Okay, so it’s been almost three months since the last time I updated S5.  During that interval, I’ve been quite busy, but I still feel disappointed that I haven’t put more energy into the project.

As a partial salve, I’ve made a few changes to the S5 information pages.  The main page now has links to the latest official version and latest revision, as well as quick links to useful information.  I updated the FAQ a bit as well, to clarify the licensing situation.  At some point, I hope to create a separate page that contains a feature list, but that’s on a back burner right now.

What I really want to do is finally make S5 1.1 a full, final reality.  Therefore, I’m pushing it to version 1.1rc1 with the knowledge that there’s a new bug to be addressed.  In Safari 1.3 (and I assume 2.0 as well, though I haven’t had a chance to install Tiger yet to find out) the arrow keys double-advance, or even more.  So if you hit the “right” or “down” arrow keys, you’ll jump forward two slides; “up” or “left” moves you back two slides.  On incremental slides, you’ll advance to the end of the slide, or the next incremental element.  The space bar doesn’t evince the same problem.

I assume this is a keystroke handling problem, but I’m not entirely sure—the behavior of incremental slides makes me wonder if maybe it’s something else.  Either way, if we can get that fixed and don’t uncover any other major problems, I’d be happy to call this bad boy done.  Help, as always, is welcomed and appreciated.

Update: Pritt left a comment on another post providing a solution for the Safari bug.  Look for 1.1rc2 shortly!

• S5 1.1rc1 was published on Monday, May 30th, 2005.
• It was assigned to the S5 and Tools categories.
• There have been nine replies.

Since I’m going to be arriving in London a week from today, I wandered over to the Professional CSS / XHTML Techniques Workshop site to see how things were going.  I discovered that there are only three seats left for the Friday session, Saturday having sold out long ago.  So if you’ve been hesitating, might be best to overcome that hesitation in a timely fashion.  I’m just sayin’.

• Limited London Seating was published on Thursday, May 26th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been eleven replies.

While I was in Japan, my old APC BF 250 UPS up and died.  I’m not sure if I unplugged it without turning it off and thus killed the battery, or what exactly, but the end result is that it was dead dead dead.

Once I got back, I checked around to find out what I might do for a replacement.  Over at the APC site, I discovered that they sell replacement batteries and charge kits, even for old units like mine, but both options are more expensive than a brand new unit.  Even better, they have a trade-in program.  You tell them what unit you have, and then you get up to a certain number of  volt-amps in replacements.  Seriously.  You can pick multiple low volt-amp units, or one higher-rated unit.  Or maybe one higher and one low.  Whatever works for you, apparently.

So in my case, I traded in a 250vA unit for a 500vA unit, and got 10% off the replacement.  And here’s the best part: part of the trade-in process is that you can send in the old unit for free.  They generate a shipping label for you to print, and once the new unit arrives, you send them the old one.  The disposal of the lead battery is thus their problem, not yours.

If you have an APC unit you’re thinking about replacing, I’d definitely recommend the trade-in program.  You’ll pay more than you would at some on-line stores, perhaps, but what you’ll save in having them take the old unit off your hands more than makes up for it, if you ask me.

• Power Conversion was published on Sunday, May 22nd, 2005.
• It was assigned to the Tech category.
• There have been five replies.

Over at Complex Spiral Consulting, I maintain a list of upcoming appearances at conferences, workshops, and the like.  These are the “public” events; that is, events which are accessible by members of the public, assuming they pay whatever registration fee is being charged by the people in charge of the event.  This is in contrast to “private” events; that is, client work that isn’t open to anyone except employees of the client.

Occasionally I’m asked if I have an RSS feed of those events, or send out e-mail updates, or otherwise provide any sort of notice other than just changing the web page.  For a long time, the answer was basically “no”.  Now it’s “yes”, and it’s an example of a microformat in action.

If you’re using iCal on OS X, or any other webcal:-aware calendaring program, then all you have to do is hit the following link: Complex Spiral upcoming events calendar.  Your calendar program should come to the foreground and let you add the URI as a subscribed calendar.  And hey presto!  You’re done.  Any changes to the web page will be reflected in your calendar the next time the subscription is refreshed, and iCal lets you set your refresh interval to be 15 minutes, once a day, once a week, and so on.

What’s happening there is you’re pouring the home page of complexspiral.com through an XSLT recipe called X2V written by Brian Suda.  His XSLT pulls out the hCalendar markup and turns it into an ICS file, one fully conformant with RFC 2445.  So I don’t have to figure out how to produce and provide my own ICS file.  Providing the hCalendar markup is enough, thanks to Brian’s work.

Of course, the number of people who would want to subscribe to my professional appearances schedule is fairly small.  This is just a demonstration, though.  Suppose a site like, oh, upcoming.org were to publish their event calendars with hCalendar markup?  Then all you’d have to do is find the page that corresponds to your city, run it through Brian’s script, and you’d have your very own regularly updated local events calendar, just like that.

Guess what?  You can do that right now:  upcoming.org is publishing its information using hCalendar markup.  For example, here’s the calendar for Cleveland, Ohio, ready for one-click subscription: Cleveland events calendar.  If you just want the ICS file to be downloaded to your hard drive, then you can use this link instead: Cleveland events ICS file.  The only difference between the two links is that the former uses the webcal: scheme identifier, whereas the second uses the more familiar http:.

I personally think there needs to be some work done on their hCalendar markup, like properly marking up location information.  The time information for some events seems to be a bit wonky as well, although the dates are accurate.  The great thing is that the hCalendar information could be fixed in very short order.  In fact, from what I’ve heard, they added basic hCalendar markup to the site in under an hour.  Adding more, or fixing any problems in what they have, shouldn’t take much longer.

Imagine how much further this could go.  Suppose Basecamp marked up its project calendars with hCalendar, and used a script like Brian’s to turn it into ICS information.  Its users could have project milestones right there in their personal calendar programs.  Ditto for the To-Do’s lists, because that sort of information is all defined in the iCalendar specification.  The TiVo site could provide customized schedules, like all the showings of American Idol or Masterpiece Theater.  The IMDB could publish movie opening dates in hCalendar format; studios could do the same.  Want a calendar schedule that shows what DVDs are coming out, when?  Or what new albums are being released for the next month?  All it takes is a little slice of a webmonkey’s time.

The point being, there’s nothing for which said webmonkey has to wait.  The tools are already here.  No browser has to be upgraded.  In fact, in many ways this bypasses the browser to send information directly to the calendaring program… but the information is provided in a browser- and search-engine-friendly way, so they can access and use the same data in their own ways.  No alternate files.  Just a single set of information, made more rich and useful through easily understood mechanisms.

How cool is that?

• Getting Onto The Calendar was published on Wednesday, May 18th, 2005.
• It was assigned to the (X)HTML, Microformats, and semantic web categories.
• There have been eleven replies.