The Missing Link

Comments (45)

1. WHATWG Wiki says:

   HTML has served the Web community well, but it lacks some basic semantics necessary for modern Web applications. HTML 5 attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.

   Maybe my memory doesn’t serve me well but wasn’t linking <tr>s an issue raised in the past few years? IIRC past eight years or so?

2. Well, I never liked XHTML2. But the href-Attribute for everything was a great invention. And with only a single line of javascript every document with these atributes appended to non-a-tags could even be used in old browsers.

   Styling via CSS would be easy in non-IE-browsers to: [href] {text-decoration:underline;color:blue;cursor:pointer;} and your done.

   Imagine , or .

   Opera demonstrated with its support for Web Forms 2.0 (http://www.whatwg.org/specs/web-forms/current-work/), that with only some CSS- and Javascript-modifications one could easily extend its browser to handle such new language-constructs.

3. Here’s a whatwg thread on the subject.

   While I wouldn’t be surprised if Ian Hickson or other WhatWG folks find your complaint here on your blog and follow up with it, (especially now that I’ve seeded it with the appropriate keywords ;) ), if you really want the WG to consider it, I would think a mailing list would be a more appropriate place to raise the issue, no?

   Last I heard, these specs are still under development and are subject to revision where a good argument can be made, and I’d say a good argument could be made for href on <tr> elements, at the least.

4. The HREF’s being applied to any element, was always one of my favorite ideas too. Nice clear post on why it really can be and should be added into HTML5. Gives me an idea for a new post…

5. p.s. I don’t think you ever made it clear that you were looking for href semantics in your post about javascript event handling. If that is all you needed, then I believe the following simple code would have sufficed:

   
function rowclick()
{
  alert(this.getAttribute('href'));
}


function init()
{
  var tbl = document.getElementById('someTable');
  var rows = tbl.getElementsByTagName('TR');
  for (var i=0; i<rows.length; i++)
  {
    if (rows[i].getAttribute('href'))
    {
      rows[i].onclick=rowclick;
    }
  }
}


6. Right on Eric. Makes more sense to do it your way.

7. I don’t know the “correct” usage of the href tag but it seems to me to be notably different from an onClick event. href, if I had to guess, is in its most abstract, “correct” usage is a property to indicate a relation. Now this makes sense for XML: XML can be queried via XPath and XML is often used to express relational data. HTML 5 is a completely different ball game, and while HTML 5 fits neatly into the syntax and largely into the purpose of XML, we still refer to them by two different names because the differences between the two are still notable.

   In the meantime I’m a big advocate of extension toolkits like jQuery, which make adding arbitrary onClick events into simple one liners.

8. It would help if you explained what you would use this for. Is this primarily needed for table rows?

9. (Also, it would be nice if you could post your comments on HTML5 on either the W3C HTML WG or WHATWG mailing list. That makes tracking comments easier. We do try our best to track blog comments as well though.)

10. Let’s not forget that adding href also means adding hreflang, type, ping (in HTML 5) and some other stuff.

    Besides tr, td and th, I think it would be very hard and confusing to bring href to anything but simple subset of the inline elements: abbr, dfn, and perhaps two or three more.

    Since JAWS and other screen readers use links to quickly navigate a page, that is also a concern. I have no answers, though.

11. The ‘browser vendor’ argument always annoys me. Get off your backsides and program the things that designers need! Seriously, why is so much stuff ‘impossible’ (no, you can’t have href on all elements. No, you can’t have a parent selector. Why? Because we say it’s too hard). Yet what are these things really? How is it so hard as to be impossible to implement when you can write a JS hack to do the same things? When we live in a world where you can boot up a PC and play online games with thousands of other people over numerous networks, using multitudes of different hardware, in true 3D worlds that are near photo-realistic, featuring complex interactive physics: but we can’t have a parent selector in our browser. That is a joke, and it’s not funny. It almost feels like browsers are being forced into obsolescence by engineers that don’t want to see them survive. Is our future going to be Silverlight and AIR? I hope not.

    Utterly agree with your points Eric. The HTML5 WG and the W3C just dont seem to be headed in any useful direction (still).

12. Kevin, thanks for the pointer! I see Shannon made pretty much exactly the same points I did, only three months earlier. He or she also makes a point I meant to include but cut for focus, which is that backwards compatibility concerns can be further nullified via DOM scripting for older browsers (crawl the document for non-a elements with href attributes and slap an (on)click on ’em).

    Anne, the use cases are many. My specific use case last week was table rows, but off the top of my head, I would add the href to at least the following HTML4/XHTML1 elements based on what seem like fairly obvious use cases:

    tr, th, td, caption, li, img, cite, blockquote, dfn, abbr, acronym, code, tt, kbd, var, span, legend, h1, h2, h3, h4, h5, h6, address

    …and I’m pretty sure there must be several more where I’m just not remembering an element or coming up with a valid use case.

    I can’t keep up with the HTML5 mailing list, unfortunately, which is why I’m not a member.

    Lars, I’d be happy to see those attributes come along. rel and rev should also come along for the ride, assuming they survive.

13. i totally agree!

    just recently i cursed the href limitations, because i wanted full semantic “teaser-boxes” (divs including h2, img and one or more p) to link to the corresponding pages.

    i think it is much more convenient and user-friendly to simply klick the whole box instead of seeking out the title or an “read more” towards the end.

14. My favourite from XHTML 2 was the <section> element, with the <h> element inside it, instead of your <h1>s and <h2>s.

15. To me, it seems like a bad idea to rely on scripting to maintain backwards compatibility, what happens when you disable javascript?

    It would be nice to have the href attribute though, I’ve felt the need for it in the same situation as Wolfgang.

16. Matt, javascript libraries can implement parent selectors because they don’t have to deal with the dynamic nature of HTML or operate at the speed we’d expect of a browser CSS implentation.

    With current CSS a browser can know what CSS selectors to apply to a given element by just examining it’s parents and earlier siblings of it and its parents (this might not be true for all pseudo selectors). So when incrementally rendering a document only the previous elements need to be examined so they can tell which CSS selectors to apply when they start rendering an element. With parent selectors previous elements would need to be revisited as more elements are added, possibly causing multiple reflows during the rendering of a page.

    When elements are dynamically added only their descendants, their siblings and their siblings’ descendants can possibly be affected with current CSS. With parent selectors every element in the document can be affected so adding an element could become very slow.

    Calculating whether a given element matches a given CSS selector would also greatly increase in complexity (I suspect it would be an increase in the big O complexity). I imagine that if any caching schemes are used to speed up CSS calculations as the document changes they’d be a lot less useful with parent selectors.

    I’m not a browser implementor so I imagine there are further problems that I haven’t anticipated. Which is to say that if the browser implementors say that something is difficult to implement, then they might just be talking from experience that you and I don’t have. Some javascript which does a fraction of what you’re asking them to do and at much slower speed than would be acceptable does not prove them wrong.

17. Paul, mine too. That one feature would make creating modular templates *so* much easier, not to mention giving a huge boost to the reusability of the markup and CSS.

18. Pingback :: Monday, June 2nd, 2008 5:01pm

    XMLRPC Test » GR Shared Link - The Missing Link

    […] The Missing Link […]

19. The browser-vendor argument is bunk. If it’s possible to do :hover on arbitrary elements and nested elements, then it’s possible to make a click on those elements do whatever you want.

    I’ve always heard that stuff like table column background colors can’t be done because there’s no good way to specify its behavior in a progressive-rendering model. I don’t understand why the standard has to make absolutely everything possible with progressive rendering, or indeed why it has to have anything to do with the each browser’s rendering algorithm at all.

    IANAProgrammer, though, so what do I know?

20. @Chris: Xpath works on the DOM and a HTML5 and XHTML5 document can be represented in the same DOM. So you can use Xpath for HTML5 – you only need a different parser for the document.

21. I think I agree with you Eric. I’ve been trying to follow the discussion on the whatwg disuccion list and the argument feels like it is going in circles. I’m with you that the backwards compatability argument is erroneous, surely any new specification will introduce anomolies with previous editions otherwise what the point of having a new specification. Besides, as long as the href attribute is not removed from the anchor element in HTML5, where will compatability be affected?

    IMHO links are not truly semantic, they are behavioural, so why should we have to resort to additional markup to achieve them. Put the behaviour into any tag and resolve the conflict.

22. Pingback :: Tuesday, June 3rd, 2008 12:35am

    JasonMorrison.net » Blog Archive » XHTML 2 vs HTML 5 and the href Attribute

    […] Eric Meyer has at least one point in XHTML 2’s favor – the ability to add and href attribute to anything, making it a link.  In addition to making the <a> tag jealous, this would let you do some pretty cool stuff like turn an entire table row into a link in a dynamic data reporting web app without a lot of Javascript or duplicated tags. […]

23. Eric, those are not really use cases. That’s a list of syntax proposals that you feel solve a certain problem. I can certainly come up with use cases for some of them, but they don’t really seem convincing. (The table row case sort of is though and is probably worth investigating more.)

    As for the mailing list, it’s not a prerequisite to keep up with it. You can just filter out most of the e-mail apart from the bits that interest you.

24. @Paul and @Michael,

    The section element is in the current HTML5 spec. There are still different header elements, but they take their importance relative to the (possibly nested) section they are in, rather than the document.

25. Anne, perhaps you could define exactly what constitutes a “use case” so that I know what standard I have to meet.

26. @Anne: I’d say that all block-level elements that may contain other block-level elements would benefit having a href= attribute. The use case for all would simply be when you need the whole element and all of it’s descendants to redirect to another location. Block-level elements that can only contain inline elements, like p, don’t need this as the good ol’ a will do the job.

27. Introducing a new block-level anchor tag may be more easy for browser vendors to implement. Not sure if that is to be prefered though.

28. Eric, a use case is a description of a problem that (probably one that you have encountered) that (presumably) does not have a clear existing solution. So, for example, the use case statement you have above is

    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

    given that use case it is also helpful if you can suggest several possible solutions and what the pros and cons are of each. so, to meet the use case you have here allowing href on tr is only one possible solution. Other possible solutions for this use case include:

    * Using javascript onclick handlers (pro:works in many UAs today, con:does not work when scripting is disabled, requires authors to know javascript to fulfil the use case)

    * Making the content model of <a> transparent (pro:works in many situations in many UAs today, con:doesn’t work well in tables due to special parsing requirements, may make conformance checking less useful)

    * Adding a new block-level element that has a transparent content model (pro:no parsing problems, con:doesn’t work in UAs today, requires scripting for legacy support)

    for more details on how to describe use cases and possible solutions, see this email from Hixie. The key idea is that use cases are descriptions of problems that should be solved rather than descriptions of solutions to problems.

    I also second Anne about the mailing list thing; there is really no need to read everything that gets posted to the whatwg list or public-html in order to productively contribute to those lists. It is clear that some of the most useful contributions are from people who simply ignore everything but the area in which they have a particular interest.

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

    Other browser vendors have already implemented it. I believe Mozilla supports xlink:href on all elements.

30. Eric, I think what Anne means by a use case is something along the lines of: “For each element upon which you would like to have ‘href’, detail, with specific example, why this would be useful.”

31. J King: That’s a bit unrealistic, isn’t it, given the number of HTML elements there are? Shouldn’t the point be: justify why the majority of elements should NOT support the href attribute.

32. Although on a first read, I thought: “hey, this is a good idea”, I think I still don’t get it, sorry.

    Wouldn’t this make the <a> element totally unnecesary? (this isn’t necessary a problem)
    What about nested elements where both parent and child have a value for the href attribute? And in this case of nested “links”, wouldn’t this arise some serious accessibility problems? It’s difficult enough for some people to click on a single isolated link; nesting an “inline-element link” on “block-element link” could really be a new challenge for navigating?

    I hope I’m not missing something here.

33. I’ve found the WHATWG use the backwards compatibility argument whenever it suits their decision, yet ignore the same issue with all the new elements they ARE creating.

    The biggest failure for me was the lack of a generic, extensible heading system. XHTML 2 had h+section, HTML5 just has h1-6 but it DOES have section. Because that makes sense. H wasn’t ok, but SECTION was?

    I’m starting to think we’ll never use HTML5, something else will come along and bypass it.

34. Anon: no, the reverse is far more work since it would be a never-ending tasking of justifying why every existing and proposed attribute didn’t belong on every existing and proposed element. Note too that by understanding the use cases (i.e. problems) that need to be addressed, we can potentially identify what elements have common characteristics that are at the root of the problem, and so the rationale behind the proposal can encompass all of these common elements at once. This is one of the values of working out a clear use case: it helps you step back to look at the problem from a wider perspective.

35. Ben, HTML5 has a system like h+section. In that system, h is just called h1.

36. Sebastian, xlink:href in Mozilla does not actually work on HTML or SVG elements last I checked. (It apparently didn’t come for free when implementing it.)

37. Pingback :: Wednesday, June 4th, 2008 8:48am

    Max Design - standards based web design, development and training » Some links for light reading (4/6/08)

    […] The Missing Link […]

38. @henri: I do not consider a document full of h1 elements to be the same as a document using h elements. h1 has an existing meaning and personally I only use one h1 per document. So it is my opinion that a document full of h1s is not a proper contextual heading system, it’s a halfway hack.

    I also fail to see any logical reason why you would allow the addition of section yet decide that h should be left out because it’s “not backwards-compatible”. If you use section, Firefox and IE aren’t going to be able to read and style the page properly (based on a quick test, Opera and Safari allow styling via section). Remember you’re going to have to use section to contextually style all those h1s into something with a visual hierarchy, which will break in non-html5 browsers just as much as h would break.

    Anyway, I’ve had this argument before and I know HTML5 isn’t going to have h. The working group’s decision making process just bothers me, and it appears to bother at least a few other people as well.

39. Ben, Firefox 3 will allow proper styling of section and for Internet Explorer you need to use the document.createElement('section') hack for a while I suppose. Using h would mean that older assistive technology for instance doesn’t even recognize it as a heading and not use it in the document outline. That seems bad. The styling issues you mention we’ll have to overcome anyway. Using h will not magically solve those. In fact, it’s not really clear what problem h using would solve.

40. Anne, help me understand why HTML 5 folks don’t think that changing the meaning of numbered headings will not confuse users? Headings are the most important construct for making Web pages accessible but almost nobody uses numbered headings correctly. Why not fix this serious problem? The section/h construct is the best solution.

    The section/h construct must also be structured just like tables, definition lists, and ordered/unordered lists. Every section element must have one h element as the first element. For example:

    <section>
    <h>…content goes here…</h>
    … content and other section elements go here …
    </section>

    As an authoring tool vendor, we believe that the use of structured section/h construct is the only way to ensure the correct use of headings in authoring tools.

41. Pingback :: Monday, June 9th, 2008 10:49pm

    Trevor Davis | Blog | Weekly Link Round-Up #34

    […] The Missing Link […]

42. Sebastian, xlink:href in Mozilla does not actually work on HTML or SVG elements last I checked. (It apparently didn”t come for free when implementing it.)

43. Well, technically speaking there is more than one way to do this and make it compatible with a range of browsers.

    I can’t see specific technical usage for extending “href” attribute to tags like “tr” but I guess this would turn to be useful to (smart) marketer… ;-)

    Cheers/Chicco

44. True Chicco, but again it comes to how you want to conform your site to the standards. If you are going to create links, they need to be usable over various other mediums as some sites to pull content off yours to theirs. I doubt they would continue to help build your links and content distribution if you were causing them validation errors.

45. Gawd. I don’t know when my brain got things mixed up, but up until about 20 minutes ago I thought that the @href attribute was going to be global in HTML5.

    GRR!

    Regarding the following: Browser vendors have reported that implementing it would be extremely complex.

    I would echo your response to reason #1: Neither [ were tons of things implemented in several browsers ] or any number of other worthwhile advancements in the web.

    I mean, is it easy to get a browser to pass Acid3? I don’t personally know for sure, but I’m going to go with No. But browser vendors still work for it.

    Gah, Eric, please beat some sense into the spec authors on this point!