Posts from June 2008

Kat and I are now doubly parents.  Earlier this week, we welcomed Rebecca Alison Meyer into our home and our hearts.

We chose Rebecca in honor of Kat’s late grandmother, a grand old lady of enormous chutzpah who taught Kat her near-legendary bargaining skills.  The middle name, Alison, honors Kat’s mother, who we’re grateful has lived long enough to receive the honor.

I’m behind on posting this because not only do we have a newborn to handle, but there’s also Carolyn to consider.  Carolyn is an amazing big sister and more than eager to help us, but she has a schedule to keep and needs help with some things, as all children do.  That makes free time almost totally nonexistent, which means time to write posts is similarly at a premium.

As we gradually settle into a routine, I expect to get back to the things I had cooking, but for now it’s pretty much all in abeyance while I concentrate on our newly enriched family.

• Welcome was published on Wednesday, June 18th, 2008.
• It was assigned to the Rebecca category.
• There have been no 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.

In response to my request, the indomitable Hamish Macpherson has created NeverForgetcerpt, a plugin for WordPress 2.5+ that will warn you if you’re about to publish a post that lacks an excerpt.  I’m already using it on meyerweb and it’s working like a charm.  He’s also expressed interest in the idea of a plugin that does that and also warns you if you forgot to add tags or categories, so stay tuned.  Meantime, all hail Hamish!

I have another plugin request, but in this case I’m looking for help in modifying something I’ve already done.  Or half-done, maybe.

I don’t know about you, but I get a lot of comment spam.  As I type this sentence, Akismet has stopped 837,806 spam attempts in total.  A false positive makes it past Akismet and my other defenses to land in the moderation queue about once every four days, on average.

Some of those false positives are really, really, really easy to spot, and they get marked as spam in order to help improve the recognition algorithms.  Others are hard to evaluate just by looking at the comment.  Many are trackbacks from sites in langauges I can’t read, and others that I can read look legit enough.  In such cases, I usually go visit the author’s URL to see if it looks spammy or not.

Now, the way I used to do this was to right-click on the blog link, copy the URL of the target, open a new browser tab, and paste the URL into the address bar.  Why?  To prevent my WP admin URL from landing in the referer logs of a potentially unscrupulous site owner.  But sometimes I forget to do all that, and just click.  I figured, well, why not stop fighting the tendency to just click and write a plugin that routes all outbound links through a redirect service?

So I did.  You can grab it for yourself if you want, but if you do, understand that it’s pretty clunky right now.  Which is the part I’d like help fixing.

The heart of the plugin is simplicity itself:

if (is_admin_page()) {
	add_filter('get_comment_author_url','_mw_obscurify',5);
}

function _mw_obscurify($url) {
	if ($url) return 'http://google.com/url?q=' . $url;
}

There’s a little more to it than that (specifically, the routine is_admin_page(), which I got from someone else’s plugin and wish now I could remember whose it was) but that’s the core.  So any time the URL of a comment author is fetched, it’s prepended to turn it into a Google redirect.

That’s true for both href values and displayed URLs, though, which is the clunky part.  The end result is that on comments from the aforementioned mighty Hamish, for example, I get the following markup on the “Comments” page:

<a href="http://google.com/url?q=http://hamstu.com">
http://google.com/url?q=http://hamstu.com</a>

What I’d very much prefer is:

<a href="http://google.com/url?q=http://hamstu.com">
http://hamstu.com</a>

Or even:

<a href="http://google.com/url?q=http://hamstu.com">
hamstu.com</a>

So what I’d like to know is if there’s any way to make that happen short of rewriting and replacing get_comment_author_url, which I’d prefer not to do since it could change in future versions of WordPress and I’m not particularly interested in turning a basic plugin into a continuing maintenance headache.  I mean, I will if absolutely necessary, but I’d like to find a better way if there is one.  Thus the request for help.

Also, are there better redirect strategies than using Google the way I have?  It’s very slightly annoying that I have to click through the Google redirect page, and though I absolutely understand why they do that, I’d love to find an automatic redirect that wouldn’t expose my referer to the target site.  Anyone know of one, or have a related sharp idea?

• Excerpts Exacted; Shielding the Admin was published on Thursday, June 12th, 2008.
• It was assigned to the Tools and WordPress categories.
• There have been fourteen replies.

So after I once again published a post without filling in the excerpt, thus forcing me to go back to fill it in later, I tweeted in a fit of pique:

I need a WordPress plugin that won’t let me publish a post until I’ve filled in the excerpt field. Anyone got one?

To which I got a whole lot of responses saying, in effect, “Oooo!  Good idea!  I need that too!  Let me know when you find one!”  Some of them came from people running fairly high-profile blogs.  The need clearly exists.  A couple of responses were of the “I could do that!” variety, so I thought I’d post here so as to describe how I think it ought to work from the user’s perspective, and then we can hash things out in comments and someone can code it up and make everyone happy.

So really what I want is, when I push the “Publish” button in WordPress, the plugin checks to see if there’s an excerpt.  If not, one of two things happens:

1. The plugin throws up a warning dialog telling me that I’m about to post without an excerpt (again).  If I say “Okay”, it goes ahead with publishing.  If I say “Cancel”, it returns me right back to where I was, which is the “Write Post” page, with all the data intact and unaltered.

2. The plugin returns me to the “Write Post” page with all data intact and unaltered, and puts an error box at the top of the page telling me I forgot to write an excerpt (again) and that it won’t let me publish until I fix the problem.

One or the other.  I think I like #1 a little better, but I’d be good either way.  I’m open to other approaches as well, but I don’t think the plugin should rely on JavaScript, as that means leaving out people who don’t enable JavaScript or post from JS-incapable devices.

I would do this myself, but I’m a little wary of the “return to the page with all data intact and unaltered” bit, which I would imagine is pretty easy to mess up.  Thus I’m putting it up here as a semi-Lazyweb post so that someone else, someone with more experience with WordPress and plugin authoring, can do it right and quickly.

Okay, who’s on it?

• Wanted: Excerpt Exacter was published on Tuesday, June 10th, 2008.
• It was assigned to the Tools and WordPress categories.
• There have been nineteen replies.

Just when you thought the whole embedded-video thing couldn’t get any worse, here I come with videos featuring, well, me.

The most recent is a short clip from one of my presentations at An Event Apart back in April, debug / reboot, where I comment at my usual pace on the suppression of quotation marks in my reset styles and why I think relying on browser-generated quotation marks is a bad idea.  You also get to see my hair before it got to be the length it is now, which is even longer.  There’s a complete transcription on that page, by the way, courtesy Mr. Z.

Then there’s the vaguely silly one, in which I attempt to debug my clothing while sitting in my living room.  The main takeaway here, I think, is that my speech patterns on stage are just about the same as those in “regular life”.  Pity my family.

So there’s me in the movies.  It’s nowhere near as epic-ly mëtäl as some other folks’ videos, but I suppose we all do what we can.

• Caught In The Camera Eye was published on Tuesday, June 10th, 2008.
• It was assigned to the An Event Apart, CSS, and Speaking categories.
• There has been one reply.

As a follow-up to “The Missing Link“, I’ve written a fairly lengthy document that presents a number of alternatives for creating a more flexible and robust linking mechanism.  The important core of the piece comes first, identifying a generic problem and covering some pros and cons of various ways to address the problem.

After that comes a much longer section which presents reasons to add linkability to various elements in the HTML5 specification.  I did not consider WebForms elements, but instead the list of 91 elements found in the primary list in Simon Pieters’ excellent HTML5 Elements and Attributes guide.

The important thing in that long list is not the exact mechanism I propose, but that I was able to find use cases for 30 HTML5 elements.  Each one is described briefly and accompanied by one or two markup examples.  Another 18 (listed at the end of the document) seemed initially to be good candidates, but I failed to find reasonable use cases for them.  The remaining 43 elements weren’t even considered, since they all seemed to be obviously poor choices.  One example is video, which would likely suffer if it were a hyperlink– resolving what to do when a user clicks on the video controls was completely unclear to me.

Now, as to why I’m blogging this instead of taking it to one or another of the relevant mailing lists: I’m looking for community input in order to strengthen the document.  Did I miss any alternative solutions in that first section?  Are there more pros and cons for the various alternatives?  What use cases did I miss in that last list of 18; or, for that matter, what are some strong use cases for the list of 30 that I didn’t include?  Are there any elements among the 43 I omitted that do, in fact, have strong use cases for being linkable?

I’ll do my best to keep up with comments.  Have at it, folks!

Update 11 Jun 08: I’ve updated the document to incorporate ideas from commenters, and added a few extra bits of information at the end of the document.  It’s worth another look, especially since I’ve gotten some semi-official encouragement to submit the proposal to the HTML Working Group.

• Strengthening Links was published on Thursday, June 5th, 2008.
• It was assigned to the (X)HTML category.
• There have been twenty-one replies.

One of the few things I think XHTML2 got absolutely, totally, 125% right was freeing the href attribute from the few elements that accepted it and spreading it all over the language.  It saddens me that this isn’t happening in HTML5, especially since at least 1.5 of the four reasons given seem off base or flat-out incorrect.  From where I stand, at any rate.

Here, let me explain by having a pseudo-dialogue with the four reasons.

It isn’t backwards compatible with existing browsers.

Neither was CSS, table markup, PNG support, or any number of other worthwhile advancements in the web.  And yes, table markup was an absolutely worthwhile advancement: previous to that, the only way to have a table of data that lined up in any fashion was to space-format it and throw the whole thing into a pre element.  Ugly nonsemantic fun!

For that matter, if lack of backwards compatibility is an accepted reason to exclude something from HTML5, then a whole bracket of new elements—like, say, nav, article, aside, dialog, section, time, progress, meter, figure, video, datagrid, header, footer, need I go on?—need to come out of the specification right now.  They’re totally unsupported, and may not even be stylable, by older browsers.

(Yes, I just proposed that the term for a group of elements be a “bracket”.  A pod of whales, a flock of seagulls, a bracket of elements.  Try it out, see how it feels on the tongue.  A little angular, perhaps?  Don’t worry, you’ll get used to it.)

It adds no new functionality that can’t already be achieved using the a element.

What?  What?!?

Given a table where each row contains several cells of of summary data, and there is a desire to be able to click on a row to get more detailed information via a search keyed off that summary information, please explain to me how being able to use <tr href="..."> on each row as opposed to writing a whole bunch of JavaScript to associate a click event listener and delegation code and handler functions and target assembly logic just to simulate what <tr href="..."> would do, were it permitted, constitutes “no new functionality”.  Please.  I would love to hear that one.

Unless of course HTML5 is going to let us wrap a elements around whatever arbitrary collection of elements we like, in which case, never mind.  I’ll just wrap all my trs in as and be done with it.  That’d be keen.  Will that be possible?  Will the HTML5 syntax be so flexible as to permit that?

Yeah, that’s what I thought.

Not that I spent half the week banging my head against this problem and getting a bunch of hand-holding in the arcana of JavaScript and inconsistent browser event handling just to address what twenty-five seconds or so would have sufficed to resolve in an href-everywhere world or anything.

And for the flip side of this, see Wilson Miner’s “Accessible Data Visualization with Web Standards“, where a bar graph is built out of spans so that they can all be wrapped in an a element in order to let you click on any “row”—that is, what would have been a row had he been able to use table markup—and get more information.  Yes, absolutely, all that stuff should be in a table, but it was a case of have a table with a bunch of not-that-easy JS forced onto it, or have the contents of every cell in a row be a separate hyperlink to the same destination, or do simple markup with savaged semantics.  We shouldn’t be forced into that choice.

It doesn’t make sense for all elements, such as interactive elements like input and button, where the use of href would interfere with their normal function.

True enough.  So don’t add it to those elements which would suffer, like input and button.  Or, alternatively, define behavior conflict resolution in those cases.  There might actually be good reasons to have button accept an href value as a fallback in cases where the normal function of the button fails in some manner.

Either way, the fact that adding href doesn’t work in some cases is no reason to forgo its addition in all cases.

Browser vendors have reported that implementing it would be extremely complex.

I’m always willing to hear why implementors think something is complex to implement, as they’re often subtle and fascinating insights into web browser development.  Still, it seems to me that everything ubiquitous href attribution would imply can be recreated with a heavy dose of JavaScript event handlers and related code—(on)click for the sending you off to the target (and any :active-style effects you wanted to bring in), (on)mouseover or plain old :hover for the interactive effects, et cetera, et cetera.  Are they really saying that it’s more complex to support this sort of thing in markup than it is to support all the scripting and DOMiness that permits people to laboriously recreate it on their own?  If so, why?  I’m really curious to know what would make this “extremely complex”, which sounds a good deal more dire than “complex” or just plain old “difficult”.

I’m open to having my mind changed by strong evidence that this would be borderline impossible to implement, even though it can apparently be simulated via existing DOM/JS implementations.  Anything short of that, however, isn’t going to convince me that this should be dropped.  It was a good idea when it was in XHTML2, and it shouldn’t be abandoned if there’s any chance to save it.

• The Missing Link was published on Monday, June 2nd, 2008.
• It was assigned to the (X)HTML and Standards categories.
• There have been forty-five replies.