Thoughts From Eric Archive

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.

• Simplicity Where It Counts was published on Monday, November 22nd, 2004.
• It was assigned to the (X)HTML, CSS, and Standards categories.
• There have been twenty-eight replies.

Hey, we’re moving quickly: S⁵ 1.1a5 is now up.  The current testbed file uses XHTML 1.0 Transitional, the better to accomodate the “allow external links to open in new window” feature I added with prompting from Peter Murray and assistance from Dave Marks.  I’m thinking about generalizing the routines to just mark any link that starts http://... as an external, window-spawning link, but that to me seems a little too intrusive.  I tend to think it’s better to let the author mark which links should spawn new windows, and which should not.  If I’m wrong, let me know.

Among other bug fixes: incremental slides now wind and unwind correctly, and don’t leave the last point on the slide stuck in the “current” state even when you loop through the slide show more than once.  The show/hide for the controls has a slightly different behavior now, so I’m looking for feedback there.

The last bug I want to squash before exiting the alpha stage is that in Safari, when you click on an “external” link, it still advances the slide show one step.  All other browsers I tested (IE/Win, Firefox) didn’t, as was the intent.  I can’t quite figure out how to fix Safari’s problem, which seems to center on the new hasValue() function.

(singing) Beta slide show, here we come…

• S⁵ 1.1a5 was published on Thursday, November 18th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-four replies.

Over the last two days, some… odd pictures of the President and his new appointees have made the rounds.  Here they are:

I could use some cheering up, so if you’d like to help out, write funny captions for one or both pictures.  Extra credit for captions that don’t make sex jokes.  (Anything really foul will be deleted.  You have been warned.)

For those who wish to contribute two captions, I think we’ll be daringly original and refer to the first picture (of Bush and Rice) as #1, and the second (of Bush and Spellings) as #2.  Got it?  Great.  Knock yourselves out.

• Caption Hunt was published on Wednesday, November 17th, 2004.
• It was assigned to the Humor and Politics categories.
• There have been sixty-nine replies.

Hooray, we’re up to 1.1a4!  The only real change here is that I’ve added a “what do you want to hide, the controls or just the popup menu?” feature.  This is handled with the following meta element:

<meta name="controls" content="hide" />

That will hide all the controls.  The default behavior is “show”, which shows the controls but not the menu.  The testbed file is currently set to hide the controls by default.

Only here’s the problem: the modifications I made broke the system in IE/Win.  It returns the ever-so-helpful message “Unknown runtime error” and a line number that doesn’t seem to make any sense to me, so I’m not sure exactly what’s broken, nor why.  Assistance appreciated. Okay, that problem got fixed with a rename suggested by Michael Moncur.  The problem now is the control menu doesn’t appear when you mouse over the lower right corner, although the controls show up okay.  This may be my fault, but help in figuring out how to make IE/Win consistent with Safari and Firefox is needed.  Thanks. Those of you using Safari or Firefox will see things as intended, at least until the IE/Win thing is fixed.  I’m especially interested in feedback regarding how the controls reveal and hide themselves in the testbed presentation.

I suspect I’m getting close to the end of feature additions for v1.1; at this point, I’d like to clear up any lingering bugs, possibly rework how the default settings are represented in the meta elements (but not their intent), and write up a quick guide on creating and using themes.  I think that will be more than enough.  I don’t want to try to tack on too much at once with each revision.

• S⁵ 1.1a4 was published on Wednesday, November 17th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been fourteen replies.

Until a few weeks ago, I’d never heard of John Peel.  Part of this was due to my never having visited the United Kingdom (though I’ve flown over it a few times), and also to my only glancing familiarity with the “music scene” in general.  The news coverage that followed Peel’s sudden, unexpected death made me aware of both his existence and his love of music.  I felt as though news of a hidden treasure had been exposed for all the world to hear about, just when that unique voice had been forever silenced.

Now it’s my turn to do the same for the world.

This past Friday, the staff members at WRUW recieved word that Harold “Ayche” Freshour, host of “Demolished Sanctuary”, had died unexpectedly at the age of 41.  Harold was, in a lot of ways, our own John Peel.  He possessed an encyclopediac knowledge of music from all genres and periods.  It was very nearly impossible to reference a song that Harold had not heard.  He had his favorite classic groups, but he was also on constant lookout for interesting new artists.  A familiar face on the Cleveland punk scene, one of those guys everyone knew, he wrote a vast number of articles, reviews, and other pieces for music magazines.  It was fairly obvious from the first time I met him that Harold loved music to a degree that few people I’ve ever met could even begin to understand.  As an example of his vast musical knowledge, Harold covered my show a few times, and I heard from my listeners that he’d done a fine job.  Mine is not an easy show to cover—some weeks, I fail to do a good job.

Not only did Harold have that vast store of musical trivia in his head, but he was a truly a kind and wonderful man to boot.  He was forever filling in for other station members when they needed it, helping out around the station with cleaning or organizing, doing production work, and generally contrinbuting to WRUW with a smile.  He was always willing to listen and give advice when another person had a problem.  His was an even keel.

Harold was also deeply enigmatic.  Much of his life was compartmentalized, and many of the things I’ve mentioned in this etnry I have only learned in the days since he died.  I am certain that he touched and was an influence in other arenas, in ways we haven’t yet uncovered.  Perhaps we never will.  I suppose that we never really know how much a person changes the world during their life, but in Harold’s case there is an added layer of mystery.

These things will sort themselves out over time.  For now, I mourn the loss of a truly good man, and bring—though in many ways too late—news of him to the world.  In the end, it is the least I can do for him.

Rest well, Harold.

• Our Own John Peel was published on Wednesday, November 17th, 2004.
• It was assigned to the Personal category.
• There have been no replies.

Today, Kat and Carolyn and I spent all day at the Great Big Food Show down at the I-X Center.  This is the Food Network‘s road show, and it was held in exactly two very hip and happening cities this year: Philadelphia and Cleveland.  The show ran here for three days, and every day there were multiple appearances from Food Network stars Marc Summers, Mario Batali, Rachael Ray, and Alton Brown.  Oh, heck, who are we kidding?  The only real star in our personal cooking firmament is Alton, deeply wacky dude and hacker cook extraordinaire.    We stood in line to get our copies of his books signed, and also to thank him for his Thanksgiving turkey recipe, which quite literally changed how we cook.  I also told him his Web site (specifically, the wonderful Rants & Raves) needs an RSS feed.  He told me he had no idea what the hell that means.  That’s all right.  Until Alton explained it on his show, I couldn’t have told you what a Maillard reaction was, let alone how it related to cooking.

So, clearly, I need a TV show, so I can return the favor.

We also saw Alton’s final stage show, where he did a sort of live-action espiode of “Good Eats” involving custards, eggnogs, ice cream, and other foam-based foods.  It was a lot of fun, with probably one or two thousand people in attendance.  I’ve heard that the other live shows were similarly popular, and with six shows a day over three days, that’s a lot of people.  Even if you figure some repeat customers, that’s still well over fifteen thousand.

What wasn’t fun was the show floor, which was far too cramped and therefore choked with crowds of attendees.  The only reason I can imagine things were so tight is that they didn’t want to pay for more floor space, because the show area was completely surrounded by empty space.  Rumor has it that next year they plan to make it even bigger, and I certainly hope that’s the case.  It was clearly a popular event, so I think they can afford to bump up the surface area.  That may mean a slight bump in ticket prices as well, but honestly, they weren’t terribly expensive so I think a small increase would be totally acceptable.  Especially if it yields more elbow room.

There were also vague promises of turning the live shows into a TV special.  I hope they make it two hours long, and call it the “Great Big ‘Great Big Food Show’ Show”.  The name actually rolls off the tongue more smoothly than you might expect.

In all, we really enjoyed ourselves.  Hopefully those of you in less-hip cities will have a chance to see the show next year.

• Great Big Food Show was published on Sunday, November 14th, 2004.
• It was assigned to the Food category.
• There have been fourteen replies.

We’re up to 1.1 alpha 3, with the big news this time around being incremental display.  So far, the way this works is that you can class a ul or ol element, and have the bullets in that list be incrementally displayed.  This is easier to understand by seeing than by reading an explanation, so go check out the alpha testbed.  In the first slide, all the bullets are displayed incrementally; you move through them by using any “next” action (keyboard or mouse).  You can also back up using a “previous” action.  The exception to this is the next and previous controls in the lower right-hand corner of the slide.  These always move forward or backward by one slide.

On the first slide, all of the bullet points are greyed out until you advance through the slide.  On the second slide, the first point is pre-highlighted.  This is intentional; it shows the difference between the two ways of presenting an incremental list.  On the third slide, the main-level points are all normal but the sub-list is incremental.  Again, this is intentional.  The highlight effect is completely CSS-based (using the class current), so every theme can have its own incremental-display look.  I picked red because it was really, really obvious, and I was too lazy to think about what color would fit in better with the default theme.  I’ll get around to tidying that up later.

The one thing I’ve made the system do but am not sure about is that when you back up to a slide that has incremental display, it starts out looking normal and then “un-highlights” as you move backward through the points.  I’m not sure that this is desirable, but at the same time I think it could be very useful.  (Plus you can always skip back a whole slide by using the lower-right controls.)  I’d like to hear feedback on what people think about the way the incremental display works now, and how it could be better.

For those who want to play around with incremental display, you add a class of inc to a list whose items you want to be incremental.  If you want a slide to start with the first point highlighted, add psf to the class value, so you have class="inc psf".  If you want to reveal arbitrary elements one by one on a slide, individually class them with inc.

I don’t have all of the contributed code merged into the JS yet, but I’ve seen everyone’s contributions from earlier posts, so please be patient.  I’m still at a loss as to how to make the intra-slide links work in Safari, and could use help figuring out what’s wrong there.  To test it, hit the “skip to summary” link on slide 1 of the testbed.  For that matter, if you uncomment the li:after rule in pretty.css, you’ll see that Safari keeps adding “NaN” into the classes of incrementally-displayed list items when you move back and forth from one incremental slide to another.  I can’t figure that one out, either.  Help is always appreciated.

So from my original 1.1a2 to-do list, the following are still left to do:

1. A way to choose whether to show/hide all of the navigation controls, or just the menu. Indicating the preferred behavior via a meta tag is starting to feel more like the right way to go, since it means the presentation author can decide whether he wants the controls to be visible or hidden.  The problem of exactly how to manage the behavior is as yet unresolved.
2. Better, possibly more dynamic, theme selection.  I still don’t have a clear idea of how this would really work.  It might be better to simply write a clear description of how to associate a new theme with the presentation file, and write up guidelines for theme authors.
3. A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (and thus make the scaling more intelligent).  I’m actually leaning pretty heavily toward dropping this, because I don’t see a pressing need to include it at this stage.  For the purposes of scaling foreground iamges, it wouldn’t be much more powerful than the author managing scaling via CSS.

And there you have the current state of s⁵ development.  Feedback is welcome.  Ever forward!

• S⁵ 1.1a3 was published on Saturday, November 13th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been twenty-one replies.

Clay Shirky recently published a missive titled “Group as User: Flaming and the Design of Social Software” that I almost dropped into the Distractions list, but then realized I wanted to write about in a little more detail.  Clay talks about mailing lists as one of the oldest forms of social software, and how they tend to become clogged with flame wars.  He makes the case that since flame wars are inevitable in a group setting, there should be mechanisms that help prevent and control the fires.  For the most part, I agree with him that some mechanisms would be a good idea.  I do not, however, accept that flaming is inevitable.

I can draw on personal experience to make this claim.  I’ve been responsible for a mailing list (css-discuss) for almost three years now.  In that time, the list grew so large that it started to overload its home, and had to migrate to a more capable host.  As of this writing, the membership list stands at 5,128 subscribed accounts.  That’s not a typo.  Bear in mind that any account that is disabled due to excessive bounces gets automatically removed after a couple of weeks, so the amount of deadwood is pretty low.

So, yeah, I know what it’s like to be a part of a very large mailing list community.  Over the lifetime of the list, we’ve had very, very few flame wars.  (Most of them have centered around font sizing, unsurprisingly enough.)  And what we call a flame war would hardly even raise an eyebrow in most online fora.  By the standards of the css-d community, any thread that contains more than two agitated posts is considered a flame war.  Posts where list members actually insult each other are rare as moon cheese.  Condescension is a little more common, but not by much.

We aren’t running magic software to make this happen; the list is running on Mailman 2.1b5.  What’s made the difference is me.

Warning!  Ego alert!  Ego alert!

Actually, not at all.  From the very first, I’ve worked hard to make sure list members understand the nature of the community.  It is not a democracy, and it isn’t an anarchy.  It’s a benevolent dictatorship.  This is no secret: I’ve said so on the list at least a couple of times.  I try not to wield the Brickbat Of Administrative Correction unless necessary, and when I do, I do so in as neutral and even-handed a manner as possible.  In the end, though, I make it very clear that within the confines of that community, my word is effectively law.  I decide what’s on topic, and what isn’t, and gently make my decisions known.  End of story.  When I call for a thread to end, it ends.  Or else.  If list members ask for changes to the list’s nature, as happens from time to time, I listen to their reasoning and then make a decision.  That’s it.

Maybe that all sounds like a guy on a massive power trip, but honestly, I’d much prefer that I didn’t have to make those calls.  I’d prefer to have a community where the members keep themselves in line.  That’s actually possible so long as the community is very small, and everyone both listens and is heard.  In a large community, it’s effectively impossible.  Even if 99% of the list membership is adult, the 1% can ruin things for everyone else.  On css-d, a 1% flame rate would mean 50 members were out of line.  In absolute terms, that’s unacceptable.  Thus I actively watch and chaperone the list.  I also wrote some material enumerating the policies, how to avoid being offended, and the right way to answer questions.  People really like that material.  I’ve been asked permission to re-use that material several times.

I also participate in the community as best I can, setting an example for how questions should be answered and list members should act.  Of late, I’ve been too swamped to offer more than token participation on the list, which is why I just yesterday selected four list members to be moderators.  They’ll be helping with administrivia, but more importantly, will be helping to keep things on-topic and civil, although I honestly don’t expect them to have to work very hard at that last part.  Heck, I’ve been an absentee dictator for a couple of months now, and things have stayed mostly on-topic and very civil.  Basically, having put the effort into rolling this massive boulder in a certain direction, it kept going that way even when I stopped actively pushing for a while.  Just recently, things have started to deteriorate a bit.  That was a major impetus to get off my keister and pick some moderators.

So I guess my point is that there’s more to a community than its members.  The founder’s influence is strong, and if the community has someone (or several someones) actively in charge who can make my-way-or-the-highway decisions but still be reasonable about them, it can be kept very nearly flame-free.

Still, some of the ideas Clay discusses would be very useful, even in an already-civil environment like css-d.  He proposes, for example, adapting features of the Slashdot karma/moderation system to mailing lists.  In the css-d context, such a system would probably function more like the eBay “Rate This Seller” feature; for us, it would be a “Rate This Member” mechanism that could communally identify those who are helpful, knowledgeable, and so on.  Similarly, a “Rate This Thread” could be used to identify topics of interest as well as topics that nobody wants to hear about.  (Like font sizing.)  I believe that by getting distributed, evolving community input of that kind, the list would be strengthened and enriched.

It would be interesting to add such features, but in the current environment, I don’t see a way to do so—and, let’s face it, I’m not the world’s most proficient programmer.  Right now it’s mostly something to keep in mind for the future.  Especially if you happen to be working on mailing list software.

• Mailing List Community Care was published on Thursday, November 11th, 2004.
• It was assigned to the Culture and Tech categories.
• There have been two replies.