Posts in the (X)HTML Category

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.

With the Redesign Watch back up and running, the most recent entry is Slashdot, the venerable geek portal so infamous for its ability to kill web servers with a single link that the site’s name is a verb meaning “to bring a server grinding to a halt”.

I was asked in a comment:

What’s your feeling on slashdot being HTML 4.01 (and slightly failing validation) VS XHTML 1.0?

My feeling is good.  Why?  Let’s take the second part first.

When it comes to HTML versus XHTML, I just do not care.  Sure, sure, people will tell you that XHTML is XML so it’s more transformable or something.  That’s a very good argument when the XHTML is well-formed and valid.  It’s also a very good argument for using HTML when it’s well-formed and valid.  Conversely, neither HTML nor XHTML is easily transformed when ill-formed and invalid.  This is an experiential point of view, too: I’ve written XSLT (which is itself so tortuous and ugly that it almost by definition cannot be called well-formed) to transform both HTML and XHTML, and the effort is pretty much the same each way—assuming well-formed, valid markup.

So as far as I’m concerned, there’s really no major practical difference between HTML and XHTML.  There are plenty of minor practical differences, like having to throw trailing slashes on all your empty elements in XHTML and needing some namespace information.  Some people will tell you the whole MIME-type thing is a major practical concern, but I’m just not that much of a purist.  Take that for whatever it’s worth.

I mean, imagine a world where Slashdot had used XHTML instead of HTML, and was failing validation.  How would that be any better or worse than things are now?

Okay, so that’s the second part.  The first part, the failure to validate, is not something I can get too terribly upset about.  Slashdot, as a site that accepts ads, is going to get horrible markup shoved into its pages.  That’s just the way it is.  If you want major sites to be perfectly valid, then in all honesty advertisers are the place to start.  So they’re already operating with a major handicap there.

Even if we were to ride our high horses along a very hard line and say that ads are just no excuse, I’d be hard-pressed to fault the job they’ve done.  For example, I ran a check on the Slashdot home page.  Out of 1,262 lines of code, there were exactly four validation errors, and that’s using HTML 4.01 Strict—you’ll note they bypassed Transitional, which only increases my respect.  Three of the errors revolved around an image in a noscript element, and the last was due to the presence of a language attribute on a script element—something they can fix in fifteen seconds, once it gets to the top of the to-do list.

You know what?  I’d be ecstatic to have that low a failure rate when launching the markover of an incredibly complex site like Slashdot.  Think about all the content they have to manage, stitch together, and offer up.  Four errors out of all that dynamically assembled markup?  I say somebody should organize them a parade for doing such a good job, and showing that any site can make use of and benefit from standards.

I’m also really looking forward to the restyling of Slashdot through user-created style sheets, and the Greasemonkey enhancements built on top of this new structure.  If there’s a site whose readers are inherently primed to script the holy bejeezus out of it, that would be the one.

Would I be happier if they’d managed to achieve total validation?  Of course.  In the meantime, though, I’m going to be very nearly as happy for what they’ve accomplished, and also for the simple fact of it being another major site that’s taken a big step forward.  Progress is always a cause for celebration in my world.

• Slashdot’s Validity was published on Sunday, September 25th, 2005.
• It was assigned to the (X)HTML, Redesign, and Standards categories.
• There have been eighteen replies.