meyerweb.com

This morning I caught a pointer to TypeButter, which is a jQuery library that does “optical kerning” in an attempt to improve the appearance of type.  I’m not going to get into its design utility because I’m not qualified; I only notice kerning either when it’s set insanely wide or when it crosses over into keming.  I suppose I’ve been looking at web type for so many years, it looks normal to me now.  (Well, almost normal, but I’m not going to get into my personal typographic idiosyncrasies now.)

My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts kern elements with inline style attributes that bear letter-spacing values.  Not span elements, kern elements.  No, you didn’t miss an HTML5 news bite; there is no kern element, nor am I aware of a plan for one.  TypeButter basically invents a specific-purpose element.

I believe I understand the reasoning.  Had they used span, they would’ve likely tripped over existing author styles that apply to span.  Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way.  Because the markup is script-generated, markup validation services don’t throw conniption fits.  There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.

The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s kerns.  The currently accepted way to avoid that sort of problem is to prefix with x-, as in x-kern.  Personally, I find it deeply unlikely that there will ever be an official kern element; it’s too presentationally focused.  But, of course, one never knows.

If TypeButter shifted to generating x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof.  It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet.  It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more.  Settling on some community best practices could save us some trouble down the road.

Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details.  That throws a fairly large wrench into the gears, and requires further contemplation.

• Invented Elements was published on Friday, March 23rd, 2012.
• It was assigned to the (X)HTML, Browsers, DOM, HTML5, Standards, and Web categories.
• There have been fourteen replies.

The “href everywhere” document (which is officially titled “HTML5: More Flexibile Linking”) has been updated, so kindly give it another look and challenge my assertions, use cases (or lack thereof), and any weak points.  Unless you consider the whole idea of extending linkability to be a weak point, in which case, never mind.  You may or may not be right, but attacking the whole premise isn’t going to get much traction.  I’m convinced the general idea is a good one.  Now it’s up to me to make the best case for it and convince implementors that I’m right.

Thanks to comments on the previous post in the series, a few elements were added to the list of those which have plausible use cases, and I added some documentation of the elements that either aren’t on the list or don’t need to be on it at the end.  Eventually, the “Possible Additions” section will disappear entirely, and at that point I’ll be ready to submit it for consideration to the Working Group.

There are a few outstanding questions raised by commenters on the previous post:

1. Is there a reasonable case for linking any of ul, ol, or dl?  In cases where they represent quotations of other documents, they’re be wrapped in a blockquote anyway, and I’ve already got a use case for that one.  Linking li makes sense, but the whole list?  There are also questions about dd—would it make sense to allow linking to the paired dd?—but I don’t see a use case for dd.  The whole point there is it’s supposed to be the definition, not a shortened reference to a longer definition.

2. I was persuaded of the utility of linking video, my previous uncertainty having been based in a misunderstanding of how click-this-video worked now, but what about audio?  I haven’t noticed it being common to link embedded audio clips to other sources, but maybe I’m missing something.

3. Can a table have multiple thead, tbody, or tfoot elements?  If so, linking them starts to make more sense.  I only wish I could find the part of the HTML5 draft that answers this one way or the other. In a like vein, I can’t decide if it makes more sense to add linking to caption or table.  I’m kind of tending toward the former.  Anyone have good arguments either way?

4. Should embed and object have direct linking, or is that better handled with already-extant markup patterns?  (If so, using param, I would imagine.)

5. Is there a reason to link a whole pre to some other resource, other than linking part of a program to a codebase?  Because in those cases, I’d probably use the <pre><code>...</code></pre> pattern, and link the code element.  pre is a presentational element, really, and you’ll note that I haven’t proposed adding linking to just about any of the presentation elements, sup and sub being the exceptions.

6. There’s a list of “(Possibly) Unsuitable Elements” near the end of the document that might bear some review in case I’m missing some obvious use cases.  Obvious to someone other than me, I mean.

Let me know what you think!  I’m definitely moving forward with this, as I’ve received encouragement from a member of the HTML WG,  but I’d like the proposal to be as solid as possible before I do so.  Thanks for everyone’s help!

• Linking Up was published on Thursday, June 12th, 2008.
• It was assigned to the (X)HTML category.
• There have been twenty-nine replies.

Tim Bray, that dashing man-about-town, recently sang the praises of Adium, a multi-service chat client for OS X.  I’d tried it a while back, and been only marginally impressed.  At the time, its presentational inflexibility was too annoying for me to take it seriously.  Okay, yes: it was a damn sight better than Messenger for OS X, which is the only reason I even kept it on my hard drive.  But I hardly ever log onto MSN any more, as everyone I know is on AIM.  So I’d stuck with iChat AV.

Still, Tim’s word is always gold (or at least high-grade palladium) with me, and he said the magic words (“highly skinnable”), so I downloaded the latest copy and poked around for a bit.

Boy howdy!  Adium has definitely come a long, long way since last I visited.  You can change the appearance of your chat sessions (with “message themes”), the dock icons, the contact list, and much more.  Since none of the default message themes really did it for me, I went looking for others.  There are quite a few available at the Adium Xtras site, but none of them were really what I wanted either.  In iChat, I cranked the graphic frippery down to zero so that the chat sessions were as compact as possible, but I still had the text look nice.  If I could recreate that in Adium, it would make the migration much, much simpler.

So I dug into the package contents of a promising message theme… and found out that themes are based on nothing more than XHTML and CSS.

Seriously.  The entirety of an Adium chat window is an XHTML document that’s being dynamically updated via DOM scripting—all of it pumped through WebKit, of course.  In creating a message theme, you define what markup will be used, and write CSS to style it.  You can even define variants on your theme by writing additional style sheets.

So with some quick hacking, I not only radically improved the markup generated during a chat (the markup I saw in the packages I downloaded was, um, sub-optimal), but I basically replicated my old iChat theme with some simple CSS.  And then I created some variants that slightly modify it in various ways, mostly to prove that I could.

I’m now wondering if I could write and attach JavaScript that would make chat sessions even more interactive, more robust.  (Update: Phil says yes.)  Click on a line to copy the whole line to the clipboard, say, or dynamically change the in-session presentation by hitting a button.  Adium may block that kind of thing, but if not, then it’s a chat client extensible beyond anything I’ve so far imagined.

And given how much I love to tinker with my software, that’s like waving a bulging suitcase of money in front of a senator.

Granted, there are some things I’d like to change.  For example, the markup you define in a theme is not used in saving the chat log.  In a log, you just get some basic markup with a case of classitis and very, very poor semantics.  It would be a lot cooler if you could define the log markup (or the log just used the markup you generate during a chat session) and the CSS to present it.

A chat log is also something that, it seems to me, cries out for a microformat.  The markup I’m using for my theme is also a first effort in that direction, recycling some other microformats’ concepts (I stole a bit from hCalendar and am planning to graft in some hCard as well) and setting up some basics.  If I can take this far enough, I might consider pushing to upgrade the markup Adium generates in its logs.  They’re dropping a lot of information on the floor when they write out the logs, and I think that’s a shame.

But then, I can make the effort to fix that and actually have a chance of it paying dividends.  The joys of open source, you know?

I’ll still use iChat AV for videoconferences, which are an essential tool for family cohesiveness when I’m on the road, as well as to keep close to my father down in Florida.  For text, though—which accounts for at least 90% of my instant messaging activity—Adium is my new chat buddy.

• Adium: Chatting With Style was published on Monday, December 19th, 2005.
• It was assigned to the CSS, Microformats, and Standards categories.
• There have been forty replies.

A little while back, I made a joke about presentational class names.  As it happened, there was a second joke hidden within the joke—as is so often the case with me—and I was delighted to see that one of my readers caught it.

But is there a reasonable alternative?  I’ve long been using the class value border to indicate when I want to put a border around a picture.  This is, to me, one of those gray-area situations that’s very hard to resolve.  I can claim that border is not very presentational: it doesn’t say anything about the specific appearance of the border, only that there should be one.  I could also argue that it’s entirely too presentational: from a semantic point of view, what does it matter if the picture is bordered or not?  It doesn’t, so the class name is unacceptable.

And yet, it does matter.  Visually, some images need to have borders, while others need to lack a border.  I can’t invent a new element or attribute to express the difference (not without writing my own DTD, anyway).  Technologically, class values are the only place I can make the distinction.

There are some other sort-of-presentational class names hanging around my site, too.  standalone is used when an image, or set of images, stands on its own, as opposed to illustrative images that are floated.  The intent is presentational, though again, standalone doesn’t say exactly how the images stand alone.  It just says that they do.

I’ve yet to come up with a good semantic way of saying “this image needs to have something that visually separates it from the rest of the page”.  I’ve kicked around ideas for other values, like framed or separated, but these fall into the same gray area… probably because the intent is basically presentational.  I’ve abstracted the presentationalism of the intent, but it’s still there.

So, anyone have a better class name, or even a better approach to drawing the distinction?  And before anyone tells me to quit worrying about this, I’m not worrying—I’m playing.  It’s like doing a crossword, or working on a logic puzzle.  Usually I just do this stuff in my head, but in this case I’m fairly stumped, and could use some help.

• Class Presentation was published on Sunday, April 3rd, 2005.
• It was assigned to the (X)HTML and CSS categories.
• There have been forty replies.

See, that’s why presentational class names are such a bad idea.

• Keep Your Classes Clean was published on Wednesday, February 23rd, 2005.
• It was assigned to the (X)HTML, CSS, Humor, and Standards categories.
• There have been eleven replies.

Due to some weather-related travel upheavals, I didn’t get to spend as much time at SES Chicago as I would have liked—I ended up flying in Tuesday afternoon, speaking before lunch Wednesday, and leaving Wednesday evening.  Still, the panel went very well, the speakers were quite gracious, and I didn’t even need a fire extinguisher.

Based on what was said in the panel and the fleeting conversations I was able to have (sometimes from the podium) with Matt Bailey and Shari Thurow, here’s what I took away from the conference:

• Semantic markup does not hurt your search engine rankings.  It may even provide a small lift.  However, the lift will be tiny, and it isn’t always a semantic consideration.  Search engines seem to use markup the same way humans do: headings and elements that cause increased presentational weight, such as <strong> and <i>, will raise slightly the weight of the content within said elements.  So even the presentational-effect elements can have an effect.  They also stated that if you’re using elements solely to increase ranking, you’re playing a loser’s game.
• The earlier content sits in the document, the more weight it has… but again, this is a very minor effect.
• Hyperlink title attribute and longdesc text has no effect, positive or negative, on search engine ranking.  The advice given was to have a link’s title text be the same as its content, and that anything you’d put into a longdesc should just go into the page itself.  (Remember: this advice is ruthlessly practical and specific to search-engine ranking, not based on any notions of purity.)
• Having a valid document neither helps nor hurts ranking; validation is completely ignored.  The (paraphrased) statement from a Yahoo! representative was that validation doesn’t help find better information for the user, because good information can (and usually does) appear on non-valid pages.
• Search engine indexers don’t care about smaller pages, although the people who run them do care about reducing bandwidth consumption, so they like smaller pages for that reason.  But not enough to make it affect rankings.
• A lot of things that we take for granted as being good, like image-replacement techniques and Flash replacement techniques, are technologically indistinguishable from search-engine spamming techniques.  (Mostly because these things are often used for the purpose of spamming search engines.)  Things like throwing the text offscreen in order to show a background image, hiding layers of text for dynamic display, and so forth are all grouped together under the SEO-industry term “cloaking”.  As the Yahoo! guy put it, 95% of cloaking is done for the specific purpose of spamming or otherwise rigging search engine results.  So the 5% of it that isn’t… is us.  And we’re taking a tiny risk of search-engine banishment because our “make this look pretty” tools are so often used for evil.

Reading that last point, you might be wondering: how much of a risk are you taking?  Very little, as it turns out.  Search engine indexers do not try to detect cloaking and then slam you into a blacklist—at least, they don’t do that right now.  To get booted from a search engine, someone needs to have reported your site as trying to scam search engines.  If that happens, then extra detection and evaluation measures kick in.  That’s when you’re at risk of being blacklisted.  Note that it takes, in effect, a tattletale to make this even a possibility.  It’s also the case that if you find you’ve been booted and you think the booting unfair, you can appeal for a human review of your site.

So using standards will not, of itself, increase your risk of banishment from Google.  If someone claims to Google that you’re a dirty search spammer, there’s a small but nonzero chance that you’ll get booted, especially if you’re using things like hidden text.  If you do get booted and tell Google you aren’t a spammer, and they check and agree with you, you’ll be back in the index immediately.

So there’s no real reason to panic.  But it’s still a bit dismaying to realize that the very same tools we use to make the Web better are much more often used to pollute it.  I don’t suppose it’s surprising, though.

Due to my radically compressed schedule, I was unfortunately not able to ask most of the questions people suggested, and for that I’m very sorry.  There was some talk of having me present at future SES conferences, however, so hopefully I’ll have more chances in the future.  I’ll also work the e-mail contacts I developed to see what I can divine.

• SES Chicago Report was published on Saturday, December 18th, 2004.
• It was assigned to the Speaking and Standards categories.
• There have been fifteen replies.

I’ve gotten a few e-mails and comments to the effect that instead of using a Creative Commons license for S5, I should use GPL instead.  One of the reasons given to me was that the Creative Commons licenses are not considered appropriate for software, according to the Creative Commons folks.

My problem is that I don’t really think of a collection of (X)HTML, CSS, and JavaScript as “software”, so the GPL doesn’t really seem to fit.  Yes, the JS is code, and one could argue that it’s software of a kind, but markup?  Presentational hints?  Not so much.  I feel the same way about the Color Blender: it’s not really software so much as a widget.  A fun widget, perhaps even cool to some people, but still not software in the way that BBEdit or NetNewsWire or any given Web browser is software.

My other problem with GPL is that it’s long and stunningly legalistic.  It kind of has to be, and I think that’s great for the purpose for which it’s intended.  To ‘protect’ things like S5 or the Color Blender, the GPL kind of feels like protecting a kitten with the 82nd Armored Division.  What I like about the CC licenses is that they’re easily understandable; even the “lawyer-friendly” versions are compact and mostly understandable.  In perusing the list of licenses over at the Free Software Foundation, I quickly got a headache.  The one license that seemed the closest fit is the Expat license.  But even there, given the way it’s written, I come up against the question: is a confederation of markup, styles, and client-side code really “software”?

So what to do?  Stick with the CC license?  Move to Expat?  Plunge into GPL-land?  Come up with my own variant license based on Expat or something similarly simple?  I’d be interested to hear people’s opinions—especially those of you who have faced the same question, or a similar question, in the past.

I’m still a little bit bemused that it’s even a question, and a little bit dismayed that ours is the kind of world where I really do have to worry about this sort of thing.

• S5 Licensing was published on Thursday, December 2nd, 2004.
• It was assigned to the S5 category.
• There have been forty-one replies.

Having talked about how to completely rip away all brower default styles in Firefox, let’s consider the bare minimum of styles we’d need to make the Web at least moderately readable.  As it turns out, the primary factor in document mangling caused by taking out the browser’s default styles is the loss of any display information.  In the absence of information regarding what kind of box an element should generate, they’re all made to generate inline boxes.  This is roughly equivalent to saying:

* {display: inline !important;}

Speaking of which, feel free to try that some time on a test document, or as an entry in a browser’s user style sheet.  The result should remind you of the no-defaults trick.

So let’s say we back up the browser’s default style sheets (you don’t want to lose them completely, unless you plan to re-install the browser) and then erase everything in html.css.  Having done that, we can restore a great deal of sanity to the Web by placing the following rules into html.css.

@namespace url(http://www.w3.org/1999/xhtml);
  /* set default namespace to HTML */

html, body, p, div, h1, h2, h3, h4, h5, h6,
ul, ol, dl, dt, dd, blockquote, address, pre,
listing, plaintext, xmp, menu, dir, isindex, hr, map,
multicol, center, frameset, marquee {display: block;}

li {display: list-item;}

area, base, basefont, head, meta, script, style, title,
noembed, noscript, param, noframes {display: none;}

table {display: table;}
caption {display: table-caption;}
tr {display: table-row;}
col {display: table-column;}
colgroup {display: table-column-group;}
tbody {display: table-row-group;}
thead {display: table-header-group;}
tfoot {display: table-footer-group;}
td {display: table-cell;}
th {display: table-cell;}

That rule set will not only cause block-level elements to start generating block boxes again, but it also lets list items be list items, hides the elements we’d like to have vanish, and restores table behavior to table markup.  With those few rules in place, browsing around will be much easier.  It might not be pretty, but it will avoid the extreme wreckage of removing all default styles.

There will still be some notable differences.  For example, paragraphs may now generate a block box, but they aren’t being given margins, so on most sites paragraphs will suddenly not have a “blank line” of separation.  Similarly, heading margins are gone.  Lists don’t have any predefined indentation.  Table cells don’t have default padding, and the “gutter” around page contents has vanished.  Of course, you might see some or all of those things on a site.  If you do, it means that information has been provided by the site’s styles.

In a quick browse of the Web, I found that CNN‘s site was still kind of scrambled by these styles, though certainly not as badly as before.  As an example, a lot of the article sidebars and pictures weren’t floated, which means the float behavior is markup-driven, not CSS-driven.  Why does it matter?  Because in Firefox, align="right" is just a markup hook on which the default style float: right; gets hung.  If that declaration doesn’t appear in the default styles, the markup will have no visible effect.  In other words, no floating.

The home page of The Mozilla Foundation, on the other hand, hung together pretty well, which indicates all of their layout is driven by CSS instead of presentational markup.  This didn’t come as much of a surprise, but it was nice to see.  I was pleased to find that meyerweb’s home page also stayed in decent shape.

So should you add these rules to your style sheets?  Not unless you’re feeling extra-super-mega-paranoid.  The percentage of visitors displaying your site with the default style sheets removed can be safely estimated to very closely approach zero, maybe even touching it.  Besides which, if someone does drop by with all default styles removed, they’ve probably done it on purpose.  If they then send you snarky e-mail about they broke your site that way, feel free to answer them with a polite acknowledgment that they did, indeed, successfully cut their own throat.  It’s not like that’s your problem, any more than you should be bothered that someone “broke” your site with an anarchic user style sheet that suppresses display of lists and paragraphs, or sets all non-replaced elements to use white text on a white background, or whatever.

A more interesting question is whether you should set up a browser to use just those rules as defaults.  I’m giving serious thought to maintaining two copies of Firefox: a normal install, and a development install that’s been hacked to use just the styles I listed before.  It could prove valuable in checking the design assumptions of a work-in-progress, and thus to identify possible weak points in the author styles.  As an example, if I loaded a new design into the development browser and found that lists were completely non-indented, then I’d know I was leaving the list indentation distance up to browser defaults.  At that point, I could decide whether or not that was a good idea.  In some designs, it might be fine, but in others it could be a problem.  Either way, I’d have the chance to consider that question directly, and reach a decision, instead of sailing blindly on, never having thought about it either way.

• Fractionally Restoring html.css was published on Monday, September 20th, 2004.
• It was assigned to the CSS category.
• There have been ten replies.