Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 2004

That Disney Magic

For Thanksgiving, we visited Kat’s parents in the West Palm Beach area, where they retired earlier this year.  When we left Cleveland on Thanksgiving morning, it was snowing—the first snowfall of the season for us.  It was clear that it would build up a dusting, and then melt within a day.  Where we were headed, it was in the seventies.  A part of me wished I could have stayed with the snow.

But off we went, and had a wonderful dinner with Kat’s parents and brother Neil.  After dinner, Uncle Neil taught Carolyn how to work the stacking-ring toy we brought along, and his efforts paid off in spades.  She’s been pulling rings off of the toy and putting them back on ever since, although she still hasn’t quite worked out that whole “largest-to-smallest” thing.  It’s pretty amazing to see how fast she went from not understanding to clumsy attempts to get it right to being an old pro.

Best of all, there was a prize embedded in the center of our trip:  we drove up to Disney World to spend the night at the Contemporary Resort and take Carolyn to the Magic Kingdom for the first time.  We had dinner at the Liberty Tree Tavern, an establishment whose name strongly and incongruously reminded me of Thomas Jefferson’s dark aphorism.  After dinner we watched the Christmas parade go past.  Well, actually, Kat and I watched it; Carolyn slept soundly through the whole thing, thus proving my assertion that when she’s fallen into a deep sleep, you can march a brass band past her at full volume and not wake her up.  The parade marched two of them past her.  Snores galore.

The next day, we had breakfast at Chef Mickey’s, rode a few rides, saw the new “Philharmagic!” show (highly recommended), and then headed back to West Palm Beach with my father and his wife, who had met us that morning.

There were two things I observed at Disney that completely astonished me.

The first was that all the children, the same media-savvy world-weary jaded children we keep hearing about in the media, totally buy into the ‘magic’ of Disney.  They relate to the costumed cast members as if they were the real thing; when “Mickey” comes by the table to dance a little jig and pat the kids on the head, they don’t see quote marks.  It really is Mickey, as far as they’re concerned, and even if they know on some level that there’s someone inside a costume, they gladly ignore that knowledge and go along for the ride.

The second thing was that Carolyn, against all my expectations, totally got that the costumed characters were in some way special.  I expected her, even at nearly a year old, to regard the characters as slightly strange people, and not significantly more interesting than anyone else.  Not so.  At first, she was a little hesitant, but with each new character she got more and more excited about them.  You can see in the pictures just how comfortable she became: she’d only learned to give kisses the week before, and by the end of dinner gave Chip (or Dale) a kiss.

At breakfast the second day, she spotted Chef Goofy standing alone near the entrance to the restaurant.  She immediately let go of my hand and toddled toward him.  He sat down, and she went right into his arms for a big hug, then sat down next to him and looked up into his face.  As I took pictures, I heard several people behind me saying things to the effect of it being darned near the most adorable thing they’d ever seen.  A woman sidled up next to me and said she hoped I’d gotten it all on video.  I hadn’t, but that’s okay.  The pictures I did take tell the story well enough.

I don’t know what it is about Disney; maybe they put something in the water.  But it really does create a kind of magic.

All too soon, it was time to head back home.  Like any good parent, we want our child to be as safe as possible, so I was greatly heartened to see her taking the time to look over the important safety information printed on the card found in the seat pocket in front of her.

Carolyn, strapped into her seat on the plane, solemnly looks over the airline safety information card.

S5 Licensing

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

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

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

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

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

S5 1.1b1

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

There are some changes to note in 1.1b1:

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

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

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

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

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

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

Unbreaking the Web

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

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

(from Microsoft Windows Exec Talks IE, Firefox)

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Into The East

Hey, Japan, I’m headed your way and looking for gigs!

I’ve received official confirmation that I’ll be presenting a half-day tutorial at the Fourteenth International World Wide Web Conference, otherwise known as WWW2005, and also delivering a keynote and participating in a panel at the W4A Workshop at the same conference.  WWW2005 will be held in Chiba, Japan, running from 10 – 14 May 2005.  There will be more details on the Complex Spiral Events page in the next week or so.

So here’s the deal: I’m already committed to travel to Japan,  so this is a rare opportunity for any companies, organizations, or other groups that would like to hire me for training, speaking, or other consulting.  My usual fees include reasonable travel expenses such as hotel room and airfare, and as you might imagine, a plane flight from the eastern United States to Japan is just a tad expensive.  (Try somewhere around $1,250 for economy class and $7,500 for business class.)  However, since I’m going to be there anyway, I’ll waive the airfare expense for any consulting engagements.  That’s a pretty notable savings no matter what airfare class I’ll be flying.

Here’s the flip side: I will need to book my flights before the end of January, in order to make sure I can get good flight arrangements.  That means I’ll need to have settled any agreements to consult (in whatever capacity) by that time.  So if you’re in Japan or know people who are there and interested in standards, spread the word!  This is the first time I’ll ever have been to Japan, and I may not be back again for quite some time.  Any assistance in making the trip more productive will be greatly appreciated.

If you have a suggestion on where I could search for leads, feel free to leave a comment or e-mail me.  If you have a business proposal or wish to seriously discuss how we might work together, please contact me via the inquiry address at Complex SpiralDomo arigato!

Preparing For SES Chicago

Some of you may recall that a while back, I let my mouth run sarcastic in the direction of some SEO experts, a topic conference, and by implication an entire industry… and ended up publicly apologizing for same, when it turned out I’d been, if not libelous, then at the very least grossly unfair.  In the process, Danny Sullivan of Search Engine Watch, the guy who organized the conference I was maligning, floated the idea that I might come speak at one of their conferences.  I indicated that I’d be interested.

As a result, I’ll be appearing on a panel at SES Chicago.  The other two panel members are, as it happens, the very same people I bad-mouthed back in August.  So that ought to be interesting.  More information, and links, are available on the Events page at Complex Spiral Consulting.

So what standards-centric question(s) do you think I should ask of these SEO experts?  The one that’s top of my list is: “Exactly what effect, if any, does semantic markup have on search engine rankings?”  A related question: “How does content ordering affect search engine indexing?”  I’m sure there are others, and I’m happy to be a conduit for asking them of people who should know, and getting the answers back to you.  So ask away—and be polite, please.  I’m not going to be talking to comment spammers, but people who learn the ins and outs of search engine behaviors to help clients get wider exposure of their content.  They’re not too dissimilar from those of us who learn the ins and outs of browser behavior to help clients get their content online in the first place.  I failed to respect that before, and won’t make the same mistake again.

Target’s Backdoor Sale

So how long before this gets turned into a boycott campaign by the high-morals crowd?  Because, after all, Target is clearly promoting a homosexual lifestyle by offering this item.  (And just in case they’ve deleted it by the time you read this, here’s a screenshot for your delectation.)

A few quick observations:

  • Only $35.96!  And that’s 10% off!  Plus you qualify for free shipping!
  • The downside, so to speak, is that it won’t be available for another 4-8 weeks.
  • At least it’s been correctly placed in the “Entertainment” section.
  • “no picture available” — that might well be a good thing.
  • Under “Features”, it says ” See description for information.”; under “Description, it says “See features for information.”

Thanks to Alex Kadis for passing this along.  Er, so to speak.

Simplicity Where It Counts

Adam Bosworth recently gave a talk about simplicity in technology, and how it’s far more important to be simple and sloppy than complex and pure.  For the most part I agree with him; my first draft of XFN and FOAF was, basically, “FOAF is complicated.  XFN isn’t.”  While that was a flip way to amuse the reviewers, it also summarizes the core reason I took to XFN when Tantek and Matt explained it to me.  Making things easy is always preferable to making them hard.  As RFC 1925 so correctly states, “In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.”

There are two places where I’d like to take issue with Adam, however.  (And I hope it’s not presumptuous of me to call him “Adam” instead of “Mr. Bosworth”.)

The first is the idea that the Web should never be more complicated than plain old HTML.  Adam says: “I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules – XSLT, and Formatting- CSS) would have had anything like the explosive uptake.”  This is absolutely common sense.  I think it’s also common sense that any truly popular and useful system starts out basic—’primitive’, if you like—and grows in complexity.  The best such systems hide the complexity from the end user.  Automobiles have gone from a few very basic controls (steering, acceleration, braking) to the mobile gadget factories we pilot today.  I still don’t have to know how the engine works to drive one.

So I absolutely agree that HTML caught on because it was simple.  It had to be, because there was nothing to shield us from the system’s innards.  When the popular Web was getting started, I did my best to promote its use by writing a trilogy of HTML tutorials (1, 2, 3).  My entire goal there was to make it easier for anyone to publish their own content.  Want to publish your grandmother’s Apple Pan Dowdy recipe?  More pictures of pets?  Bring ‘em on!  They way I figured, if everyone published what they knew, the best information would slowly rise to the top by virtue of gathering more links.  Years later, Google built an empire around the concept of the best information being the most heavily linked.  Ah well, another fortune lost.

Even then, I did take the time to teach well-formed markup because I knew that malformed markup was likely to cause trouble.  This wasn’t an elitist thing, or some sort of far-reaching clairvoyance: at the time, it was possible to break browsers with incorrect nesting of inline elements.  So it only made sense to tell readers, “Hey, if you nest elements, make sure they actually nest instead of just closing them at random.  Otherwise your page might not get displayed.”  Eventually, browsers got more tolerant of sloppy markup, and those kinds of warnings weren’t really needed any longer.

So anyway, here we are ten-plus years later, and we’re still arguing about table layout and XHTML being lower-case and blah blah blah.  In the first place, table-driven layout isn’t simple.  It’s flexible and sloppy, but not simple.  The vast majority of table-layout authors have never touched a tag in their lives.  They’ve just told some tool “do this”, and it did it.  They don’t care how.  They shouldn’t have to care how.  So whether the tool generates 50KB of table-and-spacer markup, or 15KB of semantic markup with another 5KB of CSS, is wholly irrelevant to the user.  As it should be.

It is, however, relevant to those of us who ply the back end of the Web.  I’m not going to go over the arguments now; you probably know them, and know how you feel.  But my feeling has always been that once word processors stopped fighting over file formats, and got on to fighting over ease of use and features while all reading the same formats, that’s when word processing software took off.  I feel the same about the Web.

Now, I’m kind of a fan of CSS.  Have been for a while.  I like it because it lets the design (largely) happen away from the markup, where changes are easier, and it allows all kinds of stuff that HTML layout never managed.  (Two examples right off the top of my head: letter-spacing and border-style.)  I also like JavaScript and the DOM—not because they’re pure, but because they do what they need to do.  Inspired by the work of others, I put all those pieces together recently and created a lightweight slide show system.  It isn’t perfect, and because there are DOM actions it doesn’t always tolerate sloppiness, but it’s pretty simple.  Once editors exist to let people just point, click, and type slides (and I suspect that such editors may exist in the relatively near future), it will be even easier.  And the underlying format will not matter to 95% of its users.  Nor should it.

Anyway, this brings me round to the other thing I wanted to talk about.  Early in the talk, Adam says:

…in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it.

First off, I think that Tim Berners-Lee might have a slightly different perspective on what HTML was intended to do, but let’s skip that.  The part I don’t get is the perception that “CSS fanatics have been trying to bind” HTML.  Personally, I’ve been trying to free Web design from the limitations it’s long experienced.  I’ve been working in that direction for years now.  I won’t argue that the job is finished: far from it.  But a big reason I’ve long been an advocate of using CSS is that it loosens the straightjacket, not tightens it.  The work I did within the context of the CSS Working Group was intended to loosen the bonds even further.

Maybe that means I don’t meet Adam’s definition of a “CSS fanatic”, I don’t know.  Maybe I’m not one of the “hordes” of jackbooted geeks, seeking to impose my tyrranical notions on the unwashed.  Either way, this does bring me to the question I want to ask:  where does this perception come from, that CSS is promoted a way to make the Web harder and HTML more difficult?  I’m not trying to belittle the idea by asking; I’m genuinely curious, and a little dismayed.  I know I’ve worked very hard to clearly describe what’s good and bad about CSS, just as I have about table-based design.  I’ve put a lot of effort into helping people who want to learn CSS do so, and explaining to those who ask why I think using CSS is a good idea.  Most of the other CSS advocates I know have done the same.  What is it that we did or didn’t do that got across this idea of inflexibility, or intolerance, or just plain elitism?

Because when you get right down to it, I’m still all in favor of people putting their stuff up for the world to see.  These days, I’m also in favor of making it easier for everyone else to see that stuff, and for tools to collect and analyze that stuff.  Standards make that easier—CSS makes that easier, although not as a standalone savior, but as part of a mosaic.  If someone as well-regarded and experienced as Adam Bosworth doesn’t see that, then I can’t help but feel there’s been a failure to communicate.

April 2014