Posts in the (X)HTML Category

In support of the still-to-be-finished proposal for allowing most HTML 5 elements to become hyperlinks, I’ve written a quick proof-of-concept demo for your perusal.  Basically, it’s a page with some JavaScript that captures the whole document tree, looks for any elements with an href attribute, and then sprinkles some events on those elements in order to make them act like hyperlinks.  There’s also some CSS that applies old-school link presentation to said elements (blue and underlined, baby!).  I’m using href because it was the easiest thing to do.

I’m sure I could have written a more elegant script (and yes, I know, your favorite JS framework would done it in half the lines and seventeen times the page weight) and I suspect there are some things I’m missing.  I’ll be interested to hear what those may be.  Meanwhile, if you want to try out your own arbitrary-element linking, grab a copy of the demo and edit the markup to your heart’s content.  Or you could suck out the JS and apply it to your own test pages.  Your call.

The demo works fine in Firefox 2, Camino 1.5, Safari 2, and Opera 9.2.  I didn’t test it in anything else.  It may well fail spectacularly in every other browser known to man and dog.  That’s not really an issue, though.  The goal here is to have a working demonstration, not a universal solution.  (The latter may come later.)  It’s a handy way to show people how browsers should behave in an arbitrary-link world.

The one thing that didn’t go right is the status-bar URL handling when hovering over a linked element (other than an a element) that descends from another linked element.  For some reason the descendant’s URL never shows up in the status bar.  I’m sure there’s an easy fix.  I regard this as a minor issue.  [Update 7/23: this has been fixed thanks to Allwyn Fernandez.]

The biggest thing that’s missing is simulating “visited” styles on non-a elements; in this case, turning them purple.  That would require mining the history and dynamically adding classes and, well, all kinds of stuff.  I’m sure it’s possible.  I’m also sure that I don’t have the time right now to figure out how to do it well.  Besides, ship early, ship often, right?

As I said before, I’m very interested to know what people think of the demonstrated behavior and how it might be improved.  And hey, if anyone wants to contribute improvements to the JS, I’ll do my best to keep up.

One more step toward a concrete proposal…

• Any-Element Linking Demo was published on Wednesday, July 23rd, 2008.
• It was assigned to the (X)HTML and JavaScript categories.
• There have been seventy-two 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.

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.

Cripes.  In preparing to mention some upcoming appearances, I realized I’d never gotten around to mentioning a couple of events in the recent past; specifically, AEA Seattle and the Webmaster Jam Session.  I’ll get to those in the next couple of posts, and then fire off a couple of reviews.

What I called you all here for, though, was to pass along news of an upcoming two-continent microtour.  Yes!  You can almost feel the white-hot spirit energy of this global adventure, can’t you?  I know I can, and unless I’m very much mistaken, I see it in your eyes too.

It’s a special thing we’ve just shared.  Don’t tell anyone else.

The festivities will start with my return to London (UK, not Ohio) for a two-day Carson Workshop on December 7th and 8th.  You can learn more at the Carson Workshops site, of course.  I hear tell that a goodly chunk of the limited seating has already been claimed.  In the course of the two days, I’ll be leading an expedition into the very heart of CSS.  From the darkest, thorniest jungles to the spectacular hidden vistas glimpsed only by a few lucky souls we will travel, and those who emerge alive will truly be a band of brothers and sisters.

Since I’ll already be in London on the date, might there be a stop by the BBC Backstage Bash?  Could be.  Could very well be.

From the sun-kissed shores of wild England, I’ll wing my way to verdant Boston for Web Design World.  It will be there that I will spend half a day—said day being December 11th—presenting a condensed version of some parts of the content covered in London, an overland flight giving us an idea of where the previous week’s group blazed a mighty trail.  Yes, I’d like to present it all, but since I have not (yet) fully asserted dominance over the flow of time, I have no way to fit two days into half a day.  It would be like trying to fit a Danish prince inside a nutshell.  No matter how you or he may espouse theories of some fabled infinite space to be ruled within that diminuitive husk, homey just won’t fit.

My work in Boston having been completed, I will make my way homeward at last, nearly a full week and many thounsands of miles after leaving it, tired but triumphant, ready to face the New Year and all the changes it will bring.

So now you know.  And as well we know, knowing is half the battle.

(For those who might be in the know, a bonus prize to anyone who can identify the web site and author I was homage-ing in this post.  Not parodying!  No no!  I’m not sure such a thing would be possible in any event.)

• Hands Across the Sea was published on Wednesday, November 1st, 2006.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been five replies.

Once I got a look at the markup of my latest Vitamin piece, “Stand Up For Your Rights!“, I winced.  Four paragraphs, with each alternating bit of dialogue separated by a line break?  Ay caramba!

And yet, I’m not sure I could have done better, structurally speaking.  The only semi-reasonable alternative that comes to mind is a set of four blockquotes with paragraphs instead of line breaks, but that doesn’t work for me.  They are, after all, invented conversations.  I’m not quoting anything.

Maybe paragraphed text with a div, possibly classed, for each section (yes, all right, each division) of the article would have been a better choice.  Or maybe not.  What do you think?

• Broken Rights was published on Monday, October 23rd, 2006.
• It was assigned to the (X)HTML and Writing categories.
• There have been twenty-eight replies.

I’ll get back to the whole IE7 thing in a day or three.  Sorry to start the conversation and then go silent, but I’ve recently learned two things.

1. The week after announcing a new event over at An Event Apart (like, say, AEA Chicago) is always very busy as registrations come in, people contact us with questions, posts have to be written, and so on.
2. The week before an event (like, say, AEA Atlanta) is always very busy with travel preparations, double-checking of arrangements, last-minute tweaks to talks, and so on.

So of course we’d set things up to have both happen the same week.  With another conference on my schedule for the end of the same week as AEA Atlanta.

Anyway, as I say, I’ll get back to the blogging Real Soon Now.  In the meantime, I have two new appearances to announce (in chronological order).

1. 27-28 April 2006 – Iceweb 2006 – Reykjavik, Iceland

   I’ll be presenting “The One True Layout?”, which will be a detailed look at the pros and cons of techniques debuted in Alex Robinson’s article.  A bunch of other big names will be there as well, despite which I got top billing on the site’s speaker list.  Ha!  Take that, Mr. Dave “I’m Too Sexy For The Web” Shea!

2. 12 May 2006 – Carson Workshops – London, England

   This will be an updated version of the full-day seminar “Professional CSS XHTML Techniques”.  Seating on these is quite limited, so you might want to register early and often.  Or at least early.

That’s it for now.  I hope to be back soon.

• Still Here was published on Saturday, April 8th, 2006.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been two replies.

I noticed this morning, after the power finally came back on, that the graphic next to the information on the Carson Workshops home page about the CSS/XHTML workshop I’m doing in a couple of weeks has a “LAST FEW” banner over it, so it looks like those seats are going fast as well.  If you were interested in that one but hadn’t yet gotten around to registering, now might be a good time.

• Selling Out Again was published on Thursday, October 20th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There has been one reply.