Posts from December 2004

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.

• That Disney Magic was published on Monday, December 6th, 2004.
• It was assigned to the Carolyn and Travel categories.
• There have been eleven replies.

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 Licensing was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 category.
• There have been forty-one replies.

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.

• S5 1.1b1 was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-eight replies.

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 S⁵ 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.

Indeed.

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.

• Unbreaking the Web was published on Wednesday, December 1st, 2004.
• It was assigned to the Browsers, CSS, and Standards categories.
• There have been forty replies.