Posts in the CSS Category

In his most recent post on the underpinnings of the Dashboard, titled Introducing the Canvas, Dave Hyatt said the following:

Another extension we made to HTML is a new element called the canvas. This element is essentially an image element that supports programmatic drawing.

And then, a bit later on:

In addition to the canvas element, we’ve also introduced a new attribute onto the img element. The composite attribute allows you to control how an image gets composited.

Wait a minute.  Did I just get hit over the head and magically transported back to 1994?  New HTML elements and attributes?  What the bleeding hell?!?

[insert sound of forehead banging repeatedly on desktop here]

I hope I’m reading his post incorrectly.  I hope that what Dave is really saying is that Dashboard widgets are actually XML, albeit an XML that looks very much like HTML except they’ve added some nifty stuff to it.  If so, great, fine, no problem.  XML lets you do whatever you want, really.  But if these are widgets that use actual HTML DOCTYPEs, and yet add this stuff, then the throbbing vein in my forehead is going to rupture and spray blood all over my shiny TiBook.  We just left that tag soup party.  I really don’t want to have another steaming, fetid bowl of it plopped down in front of me.  Not even one that exists in a ‘closed’ environment like OS X.

Even if Dashboard widgets are currently built around invalid HTML documents, it seems like there’s still plenty of time to convert them to well-formed XML, thus (largely) solving the problem.  Heck, there’s even time to create a DTD for the widgets, thus permitting the widgets to be both well-formed and valid.  I’m all in favor of that approach.  As a measure of last resort, a new HTML DTD could be written for “Dashboard HTML 1.0” or something like that.

But if it’s all really broken HTML 4.01, not XML, then there’s a serious problem.  From a forward-compatibility perspective, the Dashboard would be no better than Microsoft’s CSS-like extensions, the ones that let authors change the appearance of the browser’s scrollbars and other such wackiness.  In fact, they’d be much worse because there now exists the ability to create the Dashboard within the open framework the W3C has (slowly and painstakingly) created.  To ignore that would be the worst kind of regressive move.

• Wrapped in Canvas was published on Wednesday, July 7th, 2004.
• It was assigned to the CSS, Mac, and Standards categories.
• There have been nine replies.

Recently, I had a conversation with an editor at a relatively well-known and respected publisher about a CSS book concept they’re pursuing.  I don’t want to give too much away about the book itself, since it’s their idea and not mine, but I will say that the concept more or less requires that the book’s author be a recognized name in the CSS and Web design community.

For various reasons, I’m not able to take on the project myself, so we were bouncing around various names of other people who might be a good fit.  I shared some of my ideas, but I felt like I was struggling, and after we hung up I felt like I hadn’t really been a big help.  That bothered me, so I’m going to put this to you, dear readers: tell me who would automatically make you take a CSS book seriously and consider buying it just on the strength of the name alone.  (Remember, I’m not able to take this project, so don’t say, “Why, yours, Eric!” unless you want to be derided as a pointless suck-up.)  You should probably list a couple of names, just in case you all pick one person as your primary and he or she isn’t available to do the book, either.  After a week or so I’ll pass the results on to the publisher.  Even if someone else has already named your top choice(s), list them again.  The most commonly-listed names will be the ones who are at the top of the list.

So the floor is open.  Let’s hear some names!

• Wanted: CSS Luminary was published on Monday, July 5th, 2004.
• It was assigned to the Books and CSS categories.
• There have been one hundred five replies.

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.

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.

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.

Just in case you haven’t seen it yet, John Allsopp posted a nostalgic note about the early days of CSS.  If you want to know who I hung out with back in the day, John’s got most of the names right there for you, and links to many of them.  There’s even a link to the CSS Samurai page, which I thought was long dead, and was greatly amused to read.

To John’s recollections, I would add Chris Lilley, who’s since been much more involved in SVG and other things; and Susan Lesch, who’s now at the W3C but back then was at macvirus.com.  (There’s a reason I didn’t link to that address, by the way.  If you go, make sure you can block popups.)

A more recent event of note is that it was a year ago today that the CSS Zen Garden opened its gates to the world.  Congratulations on an incredible first year, Dave.  I’m honored to have been able to contribute to the Garden in that time, and eternally grateful (and a little jealous) that you created such an awesome resource.  It opened a lot of doors, and a lot more eyes and minds.

• Look Back In Awe was published on Friday, May 7th, 2004.
• It was assigned to the CSS, History, and Web categories.
• There have been no replies.