Posts in the Tech Category

After I threw out my two cents on ID naming conventions, Andy Clarke revisited the subject and made some more detailed proposals.  As I said before, I think this is a good conversation to be having.  However, the reactions of some people make me think that I wasn’t entirely clear about why.

A standard nomenclature offers the ability to restyle sites, sure.  That’s kind of cool in an übergeek kind of way, like making jokes involving TCP/IP terminology or wearing a T-shirt that says SELECT * FROM users WHERE clue > 0.  That isn’t really the primary reason why I support the exploration of ID naming conventions.  I’d like to see those conventions emerge because they will serve as a useful starting point for beginners in the standards-oriented design field.  It would help reinforce the idea of structural naming, as opposed to presentational naming.

We’re all familiar with presentational naming.  It’s things like id="leftbar" and id="pagetop".  In terms of layout, it’s the equivalent of <b> and <font>.  Structural naming, on the other hand, encourages the author to ask “what role does this piece of the document play?”  Rather than obsess over the visual placement of the navigation links, structural naming gets authors to consider the document structure.  This can’t be anything but good, at least for those of us who want to promote improved structures.  To pick one set of examples from Andy’s recent post:

#branding

Used for a header or banner to brand the site.

#branding-logo

Used for a site logo

#branding-tagline

Used for a strapline or tagline to define the site’s purpose

While #branding is described as “Used for a header or banner…” you may note that the actual ID name has nothing to do with visual placement.  It’s all about identifying the (dare we say it?) semantic role of that bit of the document.  By encouraging that thinking, a structural-naming convention keeps the author in that frame of mind when he has to go outside the common set of names.

I see this as being much like the often-promoted ‘rule’ that link-state styles should go in the order link-visited-hover-active.  I even wrote an article explaining why that order is important.  Here’s the thing: once you understand why the order is important, you can break the ‘rule’ in creative ways.  For example, suppose you want your hover effect to apply only to unvisited links, whereas visited links should get no hover.  No problem!  Just put them in the order link-hover-visited-active, or even link-hover-active-visited if you want visited links to get no active styles, either.

(Side note: if you chain pseudo-classes, such as with a:visited:hover, then the ordering problem goes away.  If Explorer supported that syntax, we could all move on from the LVHA rule.  Too bad it doesn’t.)

Conventions and ground rules exist for a reason: to provide a lower barrier to entry, and to help guide those new to the field.  Once you become experienced, you can break the rules in creative ways.  It’s been said that the key to good jazz improvisation is a thorough understanding of the rules of music.  In other words, once you really know those rules, then you know how to break them.  In order to know the rules, though, there have to be rules.

That’s why I’m glad to see them starting to emerge in blog postings and the public thinking of people in the field.  The development of these rules is not a barrier to creativity, but an enabler of it.

• Structural Naming was published on Saturday, June 26th, 2004.
• It was assigned to the CSS and Web categories.
• There have been thirty-eight replies.

A while back (so I’m slow), Andy Clark did a bit of digging and compiled a list of the most common ID names used to label pieces of layouts.  I’m out of step on every count except for the footer.  Does that mean I march to a different drummer?  Probably, given my musical tendencies.

Andy’s work interested me quite a bit, not least because he actually sifted through the markup of forty sites (this one among them) to compile his list.  I was also happy to see someone taking a practical approach to the question of naming conventions.  From time to time people ask me about CSS best practices.  While Andy’s conclusions aren’t necessarily the final word on naming best practices, they are a useful starting point for such inquisitors.  Some complained that by listing the ‘best’ (read: most common) names, Andy is stifling creativity, which strikes me as being faintly absurd.  Does the existence of blueprints for ranch houses stifle architectural creativity?  I mean, yeah, maybe sometimes they should, but in general I think the world is safe for Dutch Colonials and skyscrapers.

There’s certainly room for more detailed and extensive work on the subject of naming conventions, as well as other best practices (apparently people are souring on that term, but until I hear something better I’ll stick with it).  I just hope that more people do work like Andy’s, looking at what’s been done as opposed to endlessly theorizing.

Andy also mused:

Is it right to stick to ‘content’ and ‘main-nav’ for the sake of our users’ control or is that just too boring? And do we want to make it easy for others to change our precious designs on a whim?

I’m all for it; giving users the ability to restyle this site on a whim is what led me to propose CSS signatures, and employ one on this site.  Does my site design not serve your needs, or bore you?  Create something better suited to your tastes!  I promise I won’t mind; in fact, I’d like to see what you devise.  If a set of ID naming conventions does firm up, I’ll likely adopt it here so visitors can restyle my site consistently with others that use the same nomenclature.  This is, it seems to me, the least I can do.

• Elemental Nomenclature was published on Friday, June 18th, 2004.
• It was assigned to the CSS category.
• There have been twenty-one replies.

I hate (American) sitcoms and soap operas.  That’s a sweeping generalization, a trend that seems to be sweeping the Web of late.  No choice but to continue.

The majority of American sitcoms derive their humor—or, from my perspective, “humor”—from characters getting into embarrassing situations and then trying frantically to get out of them.  The laughs are generated by watching this person be humilated, often at length.  Generally, the humiliatee is receiving some form of just desserts: they got themselves into the situation through selfishness or arrogance or some other form of hubris, and end up paying the price.  In any event, they get to squirm and flail before our eyes and it’s funny!  Only it isn’t.

I dislike American soap operas not because they’re harshly lit and seem like community theater writ large.  I have no issues with the acting, which is actually fairly impressive in terms of the quality-to-quantity ratio.  I dislike soap operas because they’re nothing but sturm und drang, one melodramatic setpiece after another.  The number one rule is, nobody gets to be happy for long.  Anyone who does find happiness is just being set up for a major, major trauma, likely at the hands of whoever is currently making them happy.  (Although death is far less traumatic in soap operas than in real life, as people come back from the dead and aren’t even zombified when they do.  Which I suppose is good news for the power grid.)  There’s only so much of the constant chest-heaving, garment-rending dramatics I can handle before I glaze over and start to closely contemplate my cuticles.

Now why would I be talking about this when everyone else is talking about validation?  It’s a mystery, I agree.

• Valid Concerns was published on Thursday, June 17th, 2004.
• It was assigned to the Standards category.
• There have been three replies.

Chris Adamson has an interesting post over at the O’Reilly Network about code in books and articles.  In summation: should code be given a special license, separate from the actual text?

While CSS isn’t code, exactly, the same basic questions apply to the stuff I’ve written.  Let’s take my most recent title, More Eric Meyer on CSS.  It contains a copyright statement that says, in effect, you can’t reproduce the book’s text, in part or in whole, without permission.  There is no distinction there between the explanatory text (“Margin collapsing is an interesting problem in some cases, and here’s why, blah blah blah…”) and the styles.  Taken literally, the copyright statement says that you can’t re-use any of the CSS I created in your own designs.

This is clearly in opposition to what I think most of us would agree is the expectation, which is that you can use styles (or code) as you see fit but you can’t take the ‘narrative’ text and pass it off as your work.  But where’s the dividing line?  Suppose that, for whatever reason, you really like one of the designs in Project 4.  We can agree that you should be able to re-use the styles presented, but a whole design?  Is that fair?  I can imagine many arguments both for and against, many of them variants on the classic slippery-slope argument.

In my particular case, the situation is even less clear.  As anyone who drops by the book’s site will discover, the project files are freely available for anyone to download.  You aren’t even expected to own the book as a condition of using them.  That makes them less protected, I would think, than if they were on a CD that accompanied the book—but how much sense does that make?  Again, I can envision several arguments on both sides of the issue.  The same questions would arise for any author that provided code samples for download, as many do.

There’s also the question of what rights can or should be granted to the reader with regard to code.  I might hypothetically make the styles all freely available to anyone, but only under the condition that attribution be given to the source (either me, the book, or both).  Wouldn’t you, as a reader, find that rather annoying?  I would.  “You mean I have to give Eric credit just to use two CSS rules that create this cool effect?”

I’ve always operated on the principle that any markup or CSS I write about is fair game, because otherwise what would be the point of writing about how to use it?  I can see it now: “use of the CSS presented in this tutorial, including any derivative works, without the written consent of the author is prohibited.”  Yeah, right!  That would be something like a dictionary prohibiting you from using any words you look up, including all modifications and misspellings.

So should books contain an explicit license regarding use of the code?  If so, what kind?  I expect readers and publishers will have different viewpoints, although the more clueful publishers probably won’t be too far away from the typical reader perspective.  There’s a part of me that wonders why we even have to be explicit about this at all—after all, there’s been a sort of tacit acceptance of code re-use to date—but in a litigious DMCA world, this is an issue that probably has to be addressed sooner or later.

As I ponder the subject, I’m currently contemplating putting all my code samples under a Creative Commons ShareAlike 1.0 license, both now and into the future, just to make sure the bases are covered.  Then again, perhaps an explicit Public Domain license would make more sense.  Which one would be better, or is there a superior approach I haven’t considered?  Let me know.

• Code Constraints was published on Monday, June 14th, 2004.
• It was assigned to the Books, CSS, and Tech categories.
• There have been eighteen replies.

Andrei fired off round two of “Gurus vs. Bloggers”, and good news!  I played on the guru team by proxy, and was defeated by Dave Shea‘s proxy, more or less as I’d hoped I’d have the chance to do after round one was played.  Andrei was nice enough to hem and haw about which one ought to win, but honestly, there wasn’t much contest.  The Zen Garden won two SXSW Web awards including Best In Show, after all, not to mention the awe and respect of Web design folks the world over.  css/edge, at best, earned awe and respect.  In any case, I am honored to have been so thoroughly owned by the man Andrei calls “one of [my] best students.”  Mr. Shea, I bow to you.

In his tongue-in-cheek commentary, Andrei said:

Maybe if Meyer had used orange for CSS Edge, because orange is after all the new black, I would be able to swing the vote the other way.

I don’t know—low-contrast orange doesn’t really seem much better than low-contrast blue, does it?

• Edged Out Of Contention was published on Friday, June 4th, 2004.
• It was assigned to the CSS and Web categories.
• There have been eight replies.

A week ago, I published an entry that was two parts exploration and one part experimentation.  The experiment was to see how readers commented on a post of that nature, one that was potentially very inflammatory even though was not at all its intent.  The commenting ability is still new for me, and I’m working out how open I want to be about comments.  When I was writing the entry, I had in mind to not permit comments, realizing that it could easily draw a metric ton of flames, accusations, and other sundry ickiness.  At the last minute, I decided that it would be better to open comments and see what happened.  I’m well satisfied with the results, but have now closed comments on the entry (you can still ping it if you want).

I do want to follow up just a bit on some of the comments that were posted.  A few people said or implied that I should have picked a less volatile subject than intimate partner violence (IPV).  That’s just it, though: I didn’t pick the subject with an intent to post.  I was doing my own research, for my own information, and at the end of the process decided I’d share the results rather than just sit on what I’d learned.  Why?  I’ll quote myself:

…I was able to do some in-depth fact checking of my own in less than an hour, using nothing but Google and some well-chosen search terms, and obtain a more accurate picture of the world than I’d had before. I believe that this ability to self-inform is one of the most important and often underappreciated benefits of the Web. If nothing else, I’m glad I went on this particular search because it reminded me that the Web really is something worth fighting for, and that improving the Web is always an effort worth undertaking.

It was an aspect of the Web I’d rediscovered, and thought it was also important to share.  I’ve been doing this stuff for more than a decade now, and when I started my whole goal was to help put information online.  That’s why I wrote the HTML tutorials at CWRU—to make it easier for people to share information about whatever they knew best.  I’ve seen a resurgence of that impulse recently, with people blogging obscure fixes or problems they’ve encountered so Google will pick it up, and it will be there for the next person who needs it.  (See, for example,”Writing For Google” over at Daring Fireball.)  So if I can forget that the Web is an astonishing source of information, and need a reminder, maybe others could use the same reminder.

And why did I share so much detailed information on such a potentially sensitive subject?  I don’t think my points would have had the impact without the details.  That probably sounds like I was trying to use a touchy subject to raise my exposure, but that’s not it at all.  If I’d just posted to say, “I was curious about something and dug up a lot of information about it, and that’s what’s cool about the Web” it wouldn’t have had the same resonance.  Walking through the process and pointing to the sources I quoted established a context for my final points.  It was also the case that I believe I found some useful information about a very important subject, and was able to disseminate it further.

My thanks to everyone who contributed comments, especially those of you who pushed back a bit.  I’ll close with a favorite David Byrne lyric; make of it what you will.

Facts are simple and facts are straight
Facts are lazy and facts are late
Facts all come with points of view
Facts don’t do what I want them to

• Self-Referential was published on Wednesday, May 26th, 2004.
• It was assigned to the Culture and Web categories.
• There have been no replies.

I was back in the training groove this week, and on Monday morning one of the attendees had to duck out at one of the breaks.  “I have to talk with Brian, who’s consulting for us.”  I must’ve looked blank, because he said, “Brian Foy.  Do you know him?  Works with Randall Schwartz.”

I’ve been reading Brian‘s missives from Iraq on the O’Reilly Network for a year now, and was really psyched to meet him.  As it turned out, we both were planless on Monday night, so I picked him up at his hotel and blundered around the neighborhood until we found a Thai restuarant.  Over appetizers, Brian told me his wife (an opera singer) has been doing her own Web design for a while now, and was getting into CSS.  Then he mentioned buying the O’Reilly CSS book for her, and as he talked about why he’d bought it, I quickly realized that he’d picked it up because it was an O’Reilly book, and recommended.  He literally didn’t know he was having dinner with its author.

After a couple of minutes, I finally told him who’d written the book.  I should probably feel bad about not admitting it right away.  I wasn’t going to say anything here either, but he already blogged it, so… what the heck.

It was very interesting to talk about Iraq with someone who’d been there.  I was able to ask him the question I’ve wanted to have answered for a while: “How does the news coverage compare to what’s really going on over there?”

“It’s horrible,” he said.  “We got CNN and Fox on the Armed Forces Network and they were both just terrible.”  He said that he’d literally been present for things that were being covered on TV by the time he got back to the barracks, and nobody ever accurately represented what had happened.  Not even close, apparently.  Brian made the observation that images are so overwhelming, so powerful, that the story was always driven by whatever footage had been shot.  Not by the actual event in its totality, nor the context.  Just the visual.

It wasn’t surprising to hear that, but it left me saddened and frustrated.

• My Dinner With Brian was published on Tuesday, May 25th, 2004.
• It was assigned to the Culture, Politics, and Web categories.
• There has been one reply.

Through a winding chain of links—it was, of all things, the result of an extended surf on the Web, and who does that any more?—I came across Cameron Moll‘s “80/20 and the design blogosphere“, where he listed the 20 people from whom he feels 80% of vital new media design information flows.  I was deeply flattered to be on the list, although I again feel weird about it.  I don’t give out design information, and meyerweb is certainly nowhere near as well-designed as many sites (including Cameron’s).  Heck, I don’t even talk about CSS all that much any more, despite numerous vows (public and personal) to do otherwise.  I suppose all the books and other writings allow me to coast into these lists, and that’s a nice feeling, but I’m starting to seriously ask myself what I’ve done for everyone else lately.

So I’ll throw it open to the crowd: what kind of information, new media design or otherwise, would you like to see from me?  What do you feel would earn me the right to stay in Cameron’s 80/20 list?  Post and ping, or contribute a comment.  Your choice!

(I have to shoot down one potential request now: I’m not going back to browser support charting.  Westciv does a decent job already, and as I wrote a while back on www-style, going any further is a massive undertaking.  And, to be honest, it’s mind-shatteringly dull and incredibly time-consuming.)

• Earning A Spot was published on Monday, May 24th, 2004.
• It was assigned to the CSS and Web categories.
• There have been twenty-six replies.