Posts in the Tech Category

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.

• Preparing For SES Chicago was published on Monday, November 22nd, 2004.
• It was assigned to the Speaking and Standards categories.
• There have been twenty-one replies.

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.

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.

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.

I’ve posted an update to the testbed file that incorporates the new font-scaling routines from Michaël, and also a slightly corrected version of the internal-link slide routines contributed by Henryk Plötz back in the 1.0b2 days.  These routines all seem to work fine, except the internal-link routines don’t seem to work at all in Safari.  I tried several times to fix it, but I can’t figure out the problem.  So fixing that is now on the to do list.

Speaking of which, here’s the current to-do list for S⁵ 1.1, categorized by their importance.  Any of these are, of course, subject to modification, deletion, and so forth.

1. A way to trigger simple in-slide changes by hitting “next”.  For example, having a list of bullet points appear one at a time as the space bar (or other “next” action) is hit, and then moving on to the next slide.
2. The ability to cleanly list multiple authors in the metadata.  I’ll get back to this in just a minute.
3. Better, possibly more dynamic, theme selection.  I don’t know how yet, nor am I sure how it might impact the outline/slide show view toggling.
4. A way to choose whether to show/hide all of the navigation controls, or just the menu.  Ordinarily, I’d say “do it in the CSS!” and you can in fact do that right now… as long as you don’t care that the behavior won’t be quite right in Internet Explorer.  The problem is that I’m not quite sure how to manage this in a fully cross-browser fashion, short of scanning the CSS files for certain rules, and firing JS based on that.  Which, frankly, sounds kind of ooky.  Adding that information via a meta tag doesn’t seem like the right answer, but maybe I’m wrong.
5. A way to indicate the target resolution in the CSS, so that the scripts can use that for scaling purposes (thus making the scaling more intelligent).  I’m not really sure this is needed, and I’m open to being convinced one way or the other.

If there’s anything missing, let me know.  Also feel free to comment on what you think of the above plans.

Now for the metadata situation.  As I understand things, having read RFC 2068, you can have multiple HTTP headers that share a name so long as they’re interpreted as a comma-separated list of values associated with that name.  (Apologies if I’m mangling terminology, but HTTP headers aren’t really my thing.)  So given the following:

<meta name="author" content="Eric Meyer" />
<meta name="affiliation" content="Complex Spiral Consulting" />
<meta name="author" content="Joe Public" />
<meta name="affiliation" content="ConHugeCo Corp." />

…this is an equivalent construction:

<meta name="author" content="Eric Meyer, Joe Public" />
<meta name="affiliation" content="Complex Spiral Consulting, ConHugeCo Corp." />

I find this to be a long way from ideal.  In addition, since commas are the default value separator, if I understand the situation correctly,  I can’t really do something like this:

<meta name="authors" content="Eric Meyer, Complex Spiral Consulting; Joe Public, ConHugeCo Corp." />

…because that ends up as equivalent to:

<meta name="authors" content="Eric Meyer" />
<meta name="authors" content="Complex Spiral Consulting; Joe Public />
<meta name="authors" content="ConHugeCo Corp." />

That’s even further from ideal.  So here’s my current thinking for a way to represent multiple authors and affiliations:

<meta
 name="authors"
 content="Eric Meyer - Complex Spiral Consulting, Joe Public - ConHugeCo Corp." />

Anyone have a better idea than what I’ve proposed?  I’d love to hear it.  As part of said proposal, please keep in mind possible expansion of the information carried in the meta element.  For example, titles might be added, which in my current thinking would go like this:

<meta
 name="authors"
 content="Eric Meyer - Principal Consultant - Complex Spiral Consulting, 
          Joe Public - VP of IF - ConHugeCo Corp." />

It isn’t pretty, but it conforms to my understanding of meta value syntax.  As I say, I’d be very happy to be shown a better way of forming the meta values.

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

I’m working on S⁵ 1.1, and want to keep people involved in moving it forward.  So I’ve put up a testbed slide show file, which is simply a copy of the introductory presentation file that points to a new UI directory.  The current state of things, which I’ll call 1.1a01, adds two new features:

1. An author can indicate whether or not the file should default to slide show or outline view.  The default is slide show.  If you want it to default to outline view, you add:

   <meta name="slideshow" content="no" />
   

   The other possible content value is, obviously, “yes”.  This should be useful to professors who want to present notes in class as a slide show, and then post the same file to the class Web site in outline view.  The toggle key and button will both still flip between outline and slide show views, so you aren’t trapped in one or the other.  You just get to choose how the file will load up.

2. When in slide show view, the font size automatically scales based on the window size.  This means that if you’re expecting 1024×768 and get 800×600, the slides won’t become impossibly long.  Note, however, that this scales text—not images.  I’m not up to that yet, given that I have to think about how to (or even if I want to) handle them.  I’m using an onresize event handler to scale the fonts if you change the window size, as well as firing the scaling function when the slides are first loaded.  In outline view, the scaling is suppressed.

   In adding this, however, I’ve come up against the same problem that prevented font scaling from appearing in S⁵ 1.0: Gecko-based browsers mangle the layout when the font scales.  To see what I mean, toggle the slide view off and then back on.  Text separation, and the widths of inline elements, will not be recalculated when the slide view is restored.  The same kind of thing happens if you change the window size.  Once you’ve settled on a new size or toggled back to slide view, just hit Reload and all is well.  So it seems to be a case of not consistently redrawing element boxes when font sizes change; force them to be redrawn with a reload, and things are drawn as they should be.

   I can’t figure out how to fix this short of firing a reload event in the fontScale() routine, which I’d really rather avoid.  I suppose I could suppress scaling for Gecko browsers on resize (and fire a reload after toggling back to slide view) but I’d like to find a more elegant way to fix the problem.  For that matter, if anyone wants to make my scaling logic more elegant, go for it.  The frustration of cross-browser incompatibilities in manipulating styles came to the fore when I wrote that routine.

There are several ideas and suggestions from the 1.0 release that have yet to be implemented: be patient!  We’re on 1.1a01, remember, and S⁵, for all its promise, remains a “free time” project.  (My editors will no doubt be dismayed to hear that I think I even have free time.)  If I get time, I’ll write up a concrete to-do list so you can see what’s planned.  For now, if you’d like to help, please just focus on the problems I mentioned, or new problems caused by these features that I didn’t find.  Speaking of which, if any of you IE/Mac wizards can figure out what I’ve done that breaks S⁵ in that browser, I’d very much appreciate it.

• S⁵ 1.1a1 was published on Sunday, November 7th, 2004.
• It was assigned to the S5 and Tools categories.
• There have been sixteen replies.