Support linking / hrefs on any element


No problem. Making it possible to make a table row a link would probably be a good beginning since that’s not just a sort of syntax sugar, but something currently unachievable.

Oh, I obviously missaid, I meant usecase, fixed now.

It’s at least redundant if entire element’s contents should be a link. Btw, the more elements in the document, the slower browser works, so reducing the overall number of links would probably have a positive result of increasing performance given that links are used very frequently.


Let’s not go getting caught up in micro-optimizations for the vast majority of web sites and applications. This has hardly any impact enough for most sites to justify having the sepc adjusted to allow href to be a bluntly made available to any generic element.


Hint: “Btw” means minor. Nonetheless, a bunch of minor things might comprise a whole major thing, so consistently excluding all minor things is probably not a great approach. The fact that a thing is minor does not mean it does not deserve to be mentioned or taken into account. Btw, cavil to minor things is an attribute of a troll. :wink:


How about instead of saying people are trolls for not agreeing there be some data provided to support the claims made? The assertion that there is a performance impact is measurable. Tests can be done to see what the current methods do for sites and a mockup can be done of the envisioned way and compared. That way actual data can be weighed instead of the assertion that something would be a major benefit to sites if implemented.

I think though the best way forward is a case-by-case analysis of allowing href on elements. That way each new element it is added to has justifiable benefits to web authors in some way. Instead of bluntly saying it “could possibly” be needed anywhere so let’s “just do it”.


If the need is to have elements that won’t accept direct <a> children contain links, we might be able to solve the problem by instead extending <map> and/or <area>, to point at elements that should be a hyperlink. This would also sidestep the issue of making sure hrefable elements could accept the other attributes that hyperlinks have, like rel, title (different semantics across elements), target, type, etc.


Myself and others have spent several messages trying to explain the sort of usecase needed and why what you are presenting is not even close to good enough. All you’ve done is restate what you want several times but provided no compelling arguments for it. The closest you’ve come (performance) has little data for impact and even you admitted is minor. I even went and provided an example of a usecase that actually makes a good argument in favour of adding it to tr.

You fail to grasp that a spec change in and of itself, let alone one that requires active changes from browsers, let alone one that fundamentally changes a key part of how the web works, is something that requires a strong and compelling argument in its favour despite having been told multiple times that your “usecase” doesn’t come close.

If you can’t handle completely fair and reasonable responses to arguments you make without resorting to implying people are trolls here there is no way you will be able to get anything through the w3c or whatwg and would more than likely put them off considering the idea further.


Hmmm that’s interesting. Forgot entirely about all the various other required attributes that would also need to be brought over. How could map and area be extended to arbitrary elements? Obviously it would involve allowing usemap on other elements but ‘area’ and its coordinate based targetting are not a good fit. Perhaps extend area with an attribute that takes an ID.

I think in terms of implementation this one has less friction than allowing href on more elements but I think the dev experience would be much worse and the semantics less clear as well as it removes the link from the element being the link. Worth pursuing in tandem though.


Chao, Jonathan, let’s avoid too much mentoring and categoricalness given that none of us are decision makers.

As I said, I’m fine with adding href-attribute support on per-element basis.

Substantively, the first candidates for adding href-attribute support are those that cannot currently be wrapped in an A element:

  • TR (to linkify a table row) (as already said multiple times in this thread);
  • TD / TH (to linkify a table cell on its full height);
  • COL (to linkify a table column).


IIUC, this would involve associating elements by a unique attribute like id or name that is generally quite painful and undesirable. Though I’m not sure the “elements that won’t accept direct <a> children contain links” phrase doesn’t have some essential parts accidentally missing and affecting it meaning.


There are considerations for accessibility that appear not to have been taken into account so far, such as: elements convey role information, this information will be corrupted by such hybrid elements. There is not a mechanism available in most accessibility APIs to expose subroles.

There is also the issue of links not being allowed to have interactive content descendents, which i don’t believe is something that will change as its a practical limitation pertaining to focus and interaction, or able to be changed. Which (I think) would seriously limit the attractivess of allowing abitrary container elements to be linkified.


As an option, such “hybrid” elements could be announced by AT as if each of their corresponding descendant elements had a link inside it. For example:

    <tr href="/products/42/">

would be equivalent to this for AT:

        <td><a href="/products/42/">Foo</a></td>
        <td><a href="/products/42/">Bar</a></td>

Fwiw, we have already concluded (OK, I have concluded) here in this thread that interactive content should be ruled out from being able to have the href attribute and that it is fine to allow the href attribute on per-element basis, not globally.


Thanks for the updates. I did note that there would be issues such as accessibility to any extension but it’s good to have someone that can provide more specifics.

As someone that has a bit more insight on the issue do you think the problems make extending link functionality on a specific element insurmountable? I know it would at least be very hard but I think the tr issue is something that comes up enough to seriously look into trying to fix.

If it’s something that is potentially solvable even with caveats (at the least I suspect there would be more rendering rules to deal with fixing nested interactive comments like nested a tags already have), would you be able to give some direction on the ease and the issues with the various options?

As far as I can tell there are 3 ways that could be taken:

  1. Allowing a within a table to wrap a tr. This is pretty obviously a no-go from what I could see for just how deeply it would effect parsing rulesand semantics of tables
  2. Allowing href and related attributes onto tr. Would appear to be the cleanest appoach from a dev and non-accessibility user point of view but I suspect this is where the roles issue comes in, correct?
  3. Extending ‘area’ to take a target ID and allow ‘usemap’ on table. More awkward from a developer and semantic point of view but potentially has the least issues with the accessibility side of things and ‘map’ appears to be designed to lay over rather than be a descendant of its target.


We haven’t concluded it’s fine to allow href on a per-element basis. We just said that you have to try and make the case for extending ‘href’ on a per element basis.


Given that I’m fortunately not a topic starter, I suspect “you” means any of us here.


Steve, could you tell what you think about borrowing the groundwork of XHTML2 as for the global href attribute? Thanks.


Personally, I am more concerned about the tr case than arbitrary elements. Probably I should have started this topic with a narrower focus, but it’s too late now. The tr case is a real limitation that I have encountered on numerous occasions, whereas linking arbitrary elements is more of a nice-to-have.

That said, my justification for allowing linking on arbitrary elements is the improved developer ergonomics of not needing to add wrapping anchor elements everywhere. So, in this case I can’t present use-cases, as it is a proposed improvement to an existing feature — e.g. linking.

The improvement might sound slight, but I think it would be quite considerable. Firstly, it is a chore that needs to be done frequently when developing a web app. So often in fact, that I suspect many devs do it mostly without thinking, and without considering the amount of time they could save if it were as easy as simply adding a href attribute. Even a small optimisation can bring about considerable savings when applied to a common task, and may justify effort that would be

It is not just a case of adding a bit of extra markup: When the anchors are added within a layout such as flexbox, additional CSS is needed to fix-up the layout, often requiring nested flexboxes. Replacing the existing container element entirely with the anchor may not be possible if it has semantic meaning, or is a web component.


It sounds like allowing href and other linking attributes on tr / other elements is probably a non-starter. My proposal therefore would be a slight rejig of @tigt’s idea:

A new attribute, called something like “link-container” that hints to the user-agent that, if the element’s descendants contain one, and only one, anchor element, then the anchor’s inter-actable area should expand to fill the whole of the ancestor.

This would require an actual anchor element to be used to specify the href, along with any other link attributes. It would therefore enforce backwards compatibility / fallback, and should improve the accessibility situation, I think?


I wouldn’t hurry with conclusions. AFAICT, Steve was the first and only decision maker participated in the thread.

This sounds more like a CSS feature and also wouldn’t help with linkifying an entire table row. Fwiw, it’s possible to edit messages for some time (probably a month) after posting here, so feel free to change your starting message so that it’s more focused on the narrower case of linkifying specifically a table row. As an option, create a new thread solely about linkifying a table row.


I would hardly call my self a decision maker :wink: In this case in particular. Input from browser implementers is absent, and unfortuntely, for those who think this is a good idea, I don’t think you will see any enthusiasm from them.


AFAIK, you are at least involved in creating real specs unlike others. :wink:

That’s quite usual here at WICG in general, unfortunately.