Thoughts From Eric Archive

Okay, apparently that wasn’t the rest of the story.  In part, that seems to be because I didn’t express what I was trying to say very clearly.  In others, it’s because people reminded me of points I should have made, or else brought up good points I didn’t address (or consider).  Time for some follow-up.

A few people said “who cares about three/six bytes?”  Me, obviously.  On many pages, such as the archived entry, it’s not going to be a big deal.  On the home page, it will be a slightly bigger deal.  On a monthly archive page, it’s common to see twenty or more dates on a single page.  There we start to measure weight reductions in tenths of a kilobyte.  If I take a similar approach in five other cases, that’s half a kilobyte.  It adds up over time, especially when you get several hundred thousand page views a month.  The difference is even more fractional when using gzip encoding, as I am.  But a gzipped 10.4KB page is still smaller than a gzipped 10.5KB page.  It will always be smaller.  Why not take the improvement, if nothing else is harmed?  (As I believe to be the case here, although obviously not everyone agrees.)

The most common objection to what I wrote is that using b violates “semantic purity”.  I disagree entirely.  span has no more semantic purity than b, in my view.  Both are intended for purely presentational effects.  Neither adds anything to the document’s semantics in a fashion that, for example, strong does.  So on those grounds, the choice is a wash; neither is any better than the other.  The only real difference between the two elements (besides their names) is that b has, mostly by tradition but also by way of description, a default presentational rendering—the text uses a bold font face.

Which leads to the next point, one I forgot to make in the previous post (that’s what I get for writing entries late at night).  As I just said, if you use b, then in a view of the document free of author CSS, the text will be boldfaced.  That’s exactly what I want in this case; in a browser where an h5 isn’t boldfaced by default, and there is no CSS being applied at all, I’d like the date to be boldfaced.  Why?  I just do.  Oh, sure, I could come up with a rationale like it being important to highlight the entry date in a weblog, but the reasons aren’t really relevant.  As the page author, those are the kinds of decisions I get to make.  So given that desire, b has another advantage over span for the case I’m describing.  In cases where you don’t want the text to be boldfaced in a rendering free of author CSS, then b is actually disadvantageous.  There will be inevitable complaints about presentational markup, but in a non-CSS environment, what other presentational influence can I have?  None.

It was also pointed out by a few people that I’m over-classing my markup, since I could easily use descendant selectors to get the same results.  That’s absolutely true.  The classes (title and meta) are more remnants of earlier designs, and have outlived their usefulness.  In the beginning, I used the classes because I thought I’d want to use sub-headings in journal entries, in order to break up long posts.  (Andrei does this quite a bit, as do some others.)  I wanted to be sure that the title and date styles applied only to those particular headings in an entry, and no others.  Since then, practice has shown that I never write entries with sub-headings, so the classes aren’t necessary, and in fact my CSS didn’t even need the classes to be there.  Thus, I’ve taken out the classes.  If I ever find myself wanting to break up an entry into headed sections, I’ll use h6 to do it.  So thanks to those who held my feet to the fire on that point.

Lachlan Hunt pointed out that I could save a lot more weight by using UTF-8 characters instead of encoded character entities.  True.  And if I could get UTF-8 to work, I’d probably try do that, assuming I could be sure the content wouldn’t be mangled in current browsers, a worry I definitely don’t have when it comes to element handling.  Lachlan also mentioned that in a CSS3 world, I could use the ::outside pseudo-element to generate another box for styling, instead of nesting one element inside another.  Yes, and in an XBL world I could just generate the extra box(es).  Until either one or both of those worlds comes to pass, markup is the answer.  In this case, I prefer b to span for all the reasons mentioned earlier.

As you might suspect, anyone who doesn’t accept my earlier assertions about markup semantics isn’t going to agree with my markup choices.  I’ve no problem with that; note that I never said anything even remotely resembling “b is always better than span“.  It isn’t.  Neither is span always better than b, as I’ve discussed here and in the previous post.  By all means, if you have a deep-seated aversion to presentational elements, then don’t use them.  In my world, one avoids using them when a semantic element would better serve the intent.  When there is no semantic need, then I figure you should use whatever works best for you.  Knowing how to tell the difference between these cases is a big step toward really understanding how to use markup efficiently and well.

• More Markup was published on Tuesday, August 24th, 2004.
• It was assigned to the CSS category.
• There have been twenty-six replies.

In a previous post on heading levels, I used some of meyerweb’s markup as an example.  In that markup, an apparently useless <b> element appeared.  Here’s the markup:

<h4 class="title"><a href="…” title="…">entry title</a></h4>
<h5 class="meta"><b>entry date</b></h5>

In that post, I also said:

And yes, there are b elements in my markup, and I’m doing that on purpose.  I’ll talk about it some other time.

So now it’s time.

The boldface element is actually a holdover from the previous designs of meyerweb.  You can still mess with them on the theme example page, if you like.  The original idea was to provide an inline element as a hook on which I could hang some styles.  For example, if I wanted to put the date in a box that exactly surrounded the date’s text, but no more than that, I’d need an inline box.  Therefore, I could either style the <h5> element to generate an inline box, or I could have an inline element there for styling purposes.

In the first case (inlining the h5), I’d lose the block box that the element generates by default, thanks to the browser’s built-in HTML styling.  That might be okay in some cases, but more often than not it would be a problem.  Inline boxes accept a limited set of properties, and putting an inline box between two block boxes is generally a recipe for funkiness.  So that left me with the second case, that of adding an inline element.  As an added bonus, doing so gave me two elements (h5 and b) to style, if I wanted them both.

Here’s the CSS that applies to the date headings and their boldface elements:

#thoughts h5 {font-size: 1em; line-height: 1em;
  margin: 0 0 0.5em; padding: 0; color: #CCC;}
#thoughts h5 b {font-weight: normal; font-size: 0.9em;}

Although I’m not doing much with the b element, style-wise, what I’m doing is useful.  First, there’s making sure the font weight is normal, and not bold.  All right, that’s not really useful.  Second, the boldface element is used to reduce the size of the date’s font by a small amount.  I use the b element to reduce the size of the font because that leaves the element box of the h5 alone.  In other words, its text box is not reduced, which means it’s consistent with the text around it.  If I ever go back to a design where the date and title are “on the same line” and lined up with each other, as was the case in many of the old designs, I won’t have to do weird fractional math just to make it happen.

Of course, in the current design, that isn’t an issue.  So in a sense, the b element is sort of a vestige from an earlier stage in the site’s evolution, like a markup appendix.  The only difference here is that the b element might become useful again, whereas I don’t think the appendix has much chance of a comeback.

The other expected question is why, if all I wanted was an inline element as a styling hook, I used a b instead of a span.  Simple: the element name is three letters shorter, so for every hook, I’m saving six characters.  If there are, say, twenty such hooks on a page, that saves me 120 characters.  It’s a small consideration, but by such incremental savings are document weights reduced.  “What about semantic purity?” you may ask.  In my view, b and span have the same semantic value, which is to say basically none.  They’re both purely presentational elements, with the difference that span doesn’t have any expected presentational effects in HTML.  So I used the presentational hook that made the most sense to me: b.

If my goal was to emphasize the date, then I’d have used em or strong, but it wasn’t.  I just needed a hook, at least once upon a time, and that was the element I chose as my hook.

And now you have the rest of the story.

• Markup Missive was published on Monday, August 23rd, 2004.
• It was assigned to the CSS category.
• There have been forty replies.

Last night, Kat and I celebrated our wedding anniversary—a month late, true, but that was the soonest we had enough free time—with a romantic evening and dinner at Classics.  If you visit the restaurant’s Web site, you’ll discover that it plays some loud background music.  It’s relatively tasteful piano music, but still there.  The same is true of the restaurant itself, as it happens.  It wasn’t quite as loud, though, and was performed by a live pianist.  He was pretty good.

Of course, he played all the usual suspects.  About five minutes after we were seated, he started in on a rendition of “Send In The Clowns”.  Kat looked at me and said, “What, do all these guys get the same songbook?”  I tend to think so, although to his credit he managed not to play “Memories”.

Partway through the meal, we asked the server if the pianist took requests.  We were assured that he did, so we requested our wedding song: “The Christmas Song”.  She left to pass on the request and we got back to our food, one of the middle courses in the chef’s tasting menu.  As the next song emerged from the piano, I said to Kat, “Great, he’s still working that songbook.  Now it’s ‘Don’t Cry For Me, Argentina’.”

But as the chorus came around a second time, I suddenly realized something was amiss.  Cocking my head to one side, I re-focused on the music.  There was definitely something off-kilter.  “I don’t think that’s ‘Argentina’ after all,” I said.  Kat, looking puzzled herself, agreed.  It was definitely a song I’d heard before, but I was having trouble placing it.  Then, on the third round of the chorus, my eyes widened.  I looked at Kat; from her expression, I could tell she’d gotten it too.

“I think it’s—” she started to say in an incredulous tone.

“I’m pretty sure you’re right,” I said.  “We have to ask him.”

A few minutes later, we had our chance.  The pianist came over to our table and said he wanted to ask about our request, since apparently he was concerned about the other patrons’ reaction to hearing “The Christmas Song” in August.  He was curious to hear how that got to be our song for a summer wedding.

“I’ll tell you,” I said, “but first I have to ask a question.  What was the song you played just now?”

He was immediately embarrassed, and fluttered his hands as he responded.  “Oh, well, my memory isn’t, I mean one of the servers… it was just a little bit from Star Trek II: The Wrath of Khan.”

Kat and I burst into laughter and shared a high-five.

• A Classic Moment was published on Friday, August 20th, 2004.
• It was assigned to the Humor category.
• There has been one reply.

Oh, joy.  I’ve once again been accused of an anti-Explorer bias.  This would amuse me if it weren’t for the fact that it means I’m being misrepresented, despite my long-term efforts to be clear about where I stand.  It might annoy me if I could be bothered to expend the energy.  I suppose I should view this as karmic justice for my original SEO post, where I contributed to the misrepresentation of others.

For the record, I am indeed sometimes critical of IE for being non-compliant.  I’m also critical of other browsers, although of late there has been less to criticize because IE has been standing still while others advance.  That’s just the nature of things right now.  I was critical of Netscape Navigator back when the most recent version was 4.whatever and everyone else (including IE) had advanced.  It’s often easier to see the flaws in something when you have a point of comparison.

The same post implies that I’m also a CSS zealot.  True, I think CSS is a very powerful and useful technology.  However, the day I start saying things like “you can never ever use tables for layout and screw IE if it can’t handle your design”, that’s when you can accurately call me a zealot.  Until then, it’s just name-calling, and not very effective name-calling at that.

I will admit that the phrase “‘holier-than-thou’ sages on the mount” was an amusing choice of words.  Think he’s seen Episode II of the UI9 comic?

• Public Rabidity was published on Thursday, August 19th, 2004.
• It was assigned to the CSS category.
• There have been three replies.

Thanks to a post over at Simon’s weblog, I discovered that the Mozilla 1.8a3 readme file tells us of some interesting CSS-related developments:

   
• Users can now disable CSS via Use Style > None or a global preference (bug 32372.)
   
• Mozilla now supports a at-rule for matching on site/document URL. Among other things, this makes site-specific user style rules possible (bug 238099.)
   
• Preliminary support for CSS columns has been checked in to Mozilla bug 251162.)

The middle of the three is what Simon wrote about, and it’s indeed very cool.  CSS signatures would never have been necessary if browsers had always supported per-site styles.  I’m not entirely thrilled about the syntax, but it’s a good start.  And for those who are wondering how I could support a non-standard extension, I’ve never been against them as long as they were clearly marked as such.  Microsoft’s extensions (behavior, filter, the scrollbar stuff) weren’t, which inevitably led to confusion.  The Mozilla stuff is marked in such a way that you can tell it’s an extension, and in a way that won’t conflict with future CSS.

I’m happy to see that Mozilla will finally let users easily disable CSS.  For those who need the text view, say because they have poor vision, it will be a welcome feature.  For those who want to quickly check the document’s unstyled rendering, it will be similarly useful.

But I’m most intrigued by the addition of “preliminary” support for CSS columns.  This would allow you to declare that a given element’s content should be flowed into columns, complete with auto-balanced heights and everything.  For example, if you wanted a list flowed into two columns, you could declare:

ul {-moz-column-count: 2;}

That would split the contents of every undordered list into two halves, filling the first column with the first half of the list and the second column with the second half.  Thoroughly awesome.  See the CSS multi-column layout module for more details, although I don’t know how much Mozilla actually supports at this juncture.

Update: it turns out that column support isn’t present in Mozilla 1.8a3, contrary to the release notes.  I’ve been told that it will be present in 1.8a4.

• Of Site Styles and CSS Columns was published on Wednesday, August 18th, 2004.
• It was assigned to the Browsers and CSS categories.
• There have been two replies.

A few days ago, I posted the entry Silly Expert Opinions, in which I made some snide comments and rebutted some points related in a post at compooter.org.  In so doing, I fell victim to one of the classic blunders:

Never take someone to task for saying something you weren’t there to hear.

…because it may turn out they didn’t actually say it, or didn’t mean it in the way it was reported.

In the comments on the compooter.org post, the SES conference organizer Danny Sullivan (founder and editor of Search Engine Watch) and two of the panelists have calmly and professionally explained the other side of the story—the one where some of the points attributed to them were never made, some were seriously spun, and others were taken out of context.  The comments are well worth reading from about #12 on, that being Danny’s first post.  See also the thread “SES slammed by designers” at the Cre8asite forums.  (Although I should note once more that I’m not a designer.)

Unfortunately, my post triggered other posts, such as one at Molly’s crib and a  WaSP Buzz post this morning (thankfully there’s a more detailed followup).  We all fell victim to the blunder, but I fully take the blame for kicking things into high gear.  I sometimes forget that the entries I post are read and taken seriously by a whole lot of people; that my words have, at least in some circles, a certain weight.  And sometimes I let my penchant for smart-assed commentary get ahead of my more sober desire to speak with intelligence and accuracy.  My post of last Friday is such an example, and I’m sorry it’s caused confusion.  I apologize not only to the panelists and to Danny, but to anyone I inadvertently misled.

In my post, I did posit the idea that I might get into the SEO conference circuit, and now I have that ability, thanks to Danny’s deep professionalism—he could have easily, and with good reason, flamed me in e-mail and left it at that.  He didn’t.  He treated me with respect (probably more than I deserved) and opened the door I’d tried to slam.

In the afternoon WaSP post, Chris Kaminski said:

Here’s an idea: perhaps we standards folks and the SEO crowd should do a bit of knowledge sharing?  In the comments, Danny Sullivan said he’s already asked Eric Meyer to do just that, with an eye towards a possible speaking slot at an upcoming SES no less. That’s a great start. But I think we can do more. I think there’s gold to be found at the intersection of SEO and standards, or at least some good web development.

Let’s keep the beginning of dialogue in the comments to the compooter.org post, throw out the flames and ignorance, and use it to build a better set of best practices for web development. One that accounts for standards, accessibility, usability and search engines.

I agree wholly with Chris: let’s keep the dialogue going.  We’re lucky that the opportunity arose and wasn’t soured by me shooting off my mouth.  It’s time to see what can be done to harmonize the two fields, and where things can be improved.  I’m going to see what I can do about taking Danny up on his offer to attend an SES conference in the future.

I’m particularly interested because it seems, reading between the lines, that standards-oriented design isn’t as search-engine friendly as I’d thought (although it’s certainly much better than most alternatives).  Peter Janes created a test of Google’s treatment of heading levels, and the results weren’t exactly encouraging.  It bothers me that standards-oriented design and search engine optimization might be at odds, whether partially or fully.  This is definitely something that needs to be cleared up.  The results could affect the future evolution of search engines, which is a goal worth pursuing.

If you have ideas about how to get there faster, or have search engine tests of your own to share, let us know.

• SES San Jose Corrections was published on Wednesday, August 18th, 2004.
• It was assigned to the Standards category.
• There have been twenty-two replies.

As part of the XFN 1.1 update, we created an XFN and… page to cover the ways in which XFN compares to, contrasts with, and intersects with other things.  For example, that’s where we moved the XFN and FOAF document, which I really need to get around to updating.  We also debuted what Tantek loves to call “the sand-dollar diagram”.  Lacking any other vector drawing tool on my laptop, I used OmniGraffle to create it.  One of these days I really should get around to acquiring a more appropriate tool for that kind of thing.

With the spread of networking sites, people have effectively created identity islands.  My profile on LinkedIn, for example, describes a little bit of my identity.  A Ryze profile would be another part, and an Orkut profile a third.  There would no doubt be some overlap in information, but at the same time each profile will likely have some unique information about me.  The me value can be used to create bridges between these identity islands, providing—possibly for the first time—a way to tie all these disparate bits together in an easily discoverable way.  An XFN search engine (like Rubhub) could use this value to compile a unified identity profile for a person.  Similarly, it should be possible to create a tool that follows me links to pull identity information into one place.  As more profiles are created, new me links can be added and aggregated.

The only real roadblock at the moment is the inability to add XFN links from site profiles back to a central location.  Thus, in the sand dollar diagram, the links out to various services are green (XFN Friendly) while the links back from those services are blue or gray, depending on whether or not there’s an ability to add any kind of link at all.  If every service allowed users to supply a URL for a me link, then the connection would be bi-directional and thus more credible.  We don’t have to wait for that to happen, though.  If I link from meyerweb.com to various profiles with me links, that’s a good start toward consolidating my identity islands.

• Me, Me, Me, Me, and… Me was published on Monday, August 16th, 2004.
• It was assigned to the XFN category.
• There have been two replies.

The gang at GMPG (which includes me) has published the XFN 1.1 profile.  This is the profile we presented at Hypertext 2004, where we got a positive response to both the overall concept and the new values.  They are contact, kin, and me.  All three are the result of feedback we received after XFN 1.0 was released.  Of the three, I find contact the most interesting, mostly because I would never have thought of it.  To me, it seems like a value that is more about professional status than personal relationship, but a lot of people saw things otherwise.  So in it went.

For those who aren’t familiar with the term kin, it refers to any member of your family, either a blood relative or someone closely related through marriage.  As an example, all of my aunts and uncles are kin, even though half of them aren’t blood relations, having married into the family.  It was the most compact ungendered term we could find besides “family”, which didn’t feel right.

As for me, that was a value we debated for inclusion in 1.0 almost literally up to the hour we released it.  In the end, we cut it because we were resolved to include only those values we felt sure would be useful, thus keeping things as simple and lightweight as possible.  We figured that if people wanted the value, they’d tell us—and they did.  Tantek and I batted around some thoughts concerning uses of me while we were at the conference and I think we may be on to some interesting ideas.  Hopefully they’ll hold up after further discussion.

If you have a comment on XFN 1.1 or an idea for a value we could add to a future version of XFN, let us know.

• XFN 1.1 Released was published on Monday, August 16th, 2004.
• It was assigned to the XFN category.
• There have been nine replies.