http://wiki.whatwg.org/wiki/FAQ#HTML_should_support_href_on_any_element.21

(In reply to comment #1)
> <tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>

This sucks because user cannot work with such "row links" like regular links. E.g. such links cannot be opened in new tab with browser's native way to do this (Ctrl+Click, Cmd+Click, middle-click -- this even can vary across browsers and platforms) or by choosing an equivalent context-menu item; URL of link cannot be copied to clipboard via corresponding context-menu item, etc.

In other words, JavaScript "links" have same issues as "links" in Flash movies.

Maybe it makes sense to add `href` attribute at least for `TR` element only? Making table row acting as link is quite often task in web-development.

I share the previous commenter's disgust with JavaScript links. They're incredibly frustrating. You can't bookmark them, middle-click them, or copy them. It seems kinda odd just to support href for <tr>, though, especially since tables are becoming so passé for layout and are rarely needed legitimately. I am sad to see this idea go, even though I can sorta see why.

There's still the suggestion that src be global. I suppose we code developers can try to obtain equivalent functionality using the <object> or <figure> elements and maybe some CSS. Not quite as elegant, but it will have to do.

(In reply to comment #2)
> Making table row acting as link is quite often task in web-development.

Do you have any data to support that statement?

(In reply to comment #4)
> (In reply to comment #2)
> > Making table row acting as link is quite often task in web-development.
> 
> Do you have any data to support that statement?

Sure. Yandex.Mail (mail.yandex.ru) web-interface displays messages as table where each row contains 4 cells: two are message author and subject (clickable as _single_ link that fills most of row space), other two (small) cells contain date and checkbox to select message (as item in message list) for some operations. This is clearly tabular data.

But currently this is semantically not a table at all: each row is actually a `DIV` element that contains `A` element containing `SPAN` elements _imitating_ table cells (basic HTML structure representing a "row" is shown below):

	<div>
		<label><input type="checkbox" /></label>
		<div><span>Date</span></div>
		<span><a href="#message/12345">
			<span>Some subject</span>
			<span>Message fragment</span>
			<span><span>Message author</span></span>
		</a></span>
	</div>

Using real table with entire row being link in such cases would be much more semantic and potentially more accessible.

(Triggering `click` event of link-row when clicking on checkbox/date cells could be prevented with `event.preventDefault()`).

Thanks. So Yandex,Mail doesn't use a link for the full row, but only some of the cells (the checkbox and date shouldn't be in the link). That suggests <tr href> might not be the correct solution here.

How is this supposed to be different to repeating the link in each cell that wants it? Is it just ease of authoring? Or should the browser treat them as a single link for the purpose of focus navigation? Something else?

(In reply to comment #6)
> Thanks. So Yandex,Mail doesn't use a link for the full row, but only some of
> the cells (the checkbox and date shouldn't be in the link). That suggests <tr
> href> might not be the correct solution here.

Yandex.Mail is just a real-world example of tabular data marked-up nontably (unsemantically) just due to markup-language limitations. But even in this case, as I've highlighted in comment 5, link fills _most_ of row space.

Of course, a more flexible solution would be ability to wrap cells themselves in link like this:

    <tr>
        <td>Lorem</td>
        <a href="#">
            <td>Ipsum</td>
            <td>Dolor</td>
        </a>
        <td>Amet</td>
    </tr>

But, considering current browsers' markup-error-correction algorithms in particular, this is unlikely possible.

Maybe, when dealing with <tr href="">, we could have some mechanism to specify indexes of specific cells that we want to act as single link. For example:

    <tr href="#" hrefcells="2,3">
        <td>Lorem</td>
        <td>Ipsum</td>
        <td>Dolor</td>
        <td>Amet</td>
    </tr>

In this example, "Ipsum" and "Dolor" cells would act as single link pointing to URL specified in `href` attribute of `TR` element.

Maybe `hrefcells` attribute could be also applicable to `COLGROUP` elements to prevent duplicating this for each row of table when each row has same structure.

But considering specifics of current process of W3 speccing, all these advanced features are unlikely to become live. So just ability to have `href` for `TR` is probably most viable option.


> How is this supposed to be different to repeating the link in each cell that
> wants it? Is it just ease of authoring? Or should the browser treat them as a
> single link for the purpose of focus navigation? Something else?

Treating multiple cells as one single link is one of major purposes here (aside from trivial "DRY" principle, this allows to hover cells as an integral unit). Another purpose is that such link row would have height adjusted by browser automatically according to height of most high of cells in particular row; this is problematic with independent links nested into different cells (even aside from undesirability of having multiple adjoining links pointing to same URL just because of markup language limitations).

(In reply to comment #7)
> Yandex.Mail is just a real-world example of tabular data marked-up nontably
> (unsemantically) just due to markup-language limitations.

Why the "just"? It's exactly what we're looking for -- real world pages working around the lack of the feature.

> But even in this
> case, as I've highlighted in comment 5, link fills _most_ of row space.

They wouldn't want to the link to fill *all* or the cells, correct?

> Of course, a more flexible solution would be ability to wrap cells themselves
> in link like this:
> 
>     <tr>
>         <td>Lorem</td>
>         <a href="#">
>             <td>Ipsum</td>
>             <td>Dolor</td>
>         </a>
>         <td>Amet</td>
>     </tr>
> 
> But, considering current browsers' markup-error-correction algorithms in
> particular, this is unlikely possible.

Indeed.

> Maybe, when dealing with <tr href="">, we could have some mechanism to specify
> indexes of specific cells that we want to act as single link. For example:
> 
>     <tr href="#" hrefcells="2,3">
>         <td>Lorem</td>
>         <td>Ipsum</td>
>         <td>Dolor</td>
>         <td>Amet</td>
>     </tr>
> 
> In this example, "Ipsum" and "Dolor" cells would act as single link pointing to
> URL specified in `href` attribute of `TR` element.
> 
> Maybe `hrefcells` attribute could be also applicable to `COLGROUP` elements to
> prevent duplicating this for each row of table when each row has same
> structure.

I think you're going into over-designing a particular solution instead of addressing the need in the best way.

> But considering specifics of current process of W3 speccing, all these advanced
> features are unlikely to become live.

What?

> So just ability to have `href` for `TR`
> is probably most viable option.

Why provide a solution that only almost solves the problem?

> Treating multiple cells as one single link is one of major purposes here (aside
> from trivial "DRY" principle, this allows to hover cells as an integral unit).

OK, so, act as a single link for the purpose of focus navigation and the :hover/:active/:focus selectors?

> Another purpose is that such link row would have height adjusted by browser
> automatically according to height of most high of cells in particular row; this
> is problematic with independent links nested into different cells (even aside
> from undesirability of having multiple adjoining links pointing to same URL
> just because of markup language limitations).

Hmm. This seems like something that should be solved in CSS rather than in markup.

An alternative proposal:

<tr>
 <td>checkbox
 <td>date
 <td><a href=/foo/ id=link_foo>Some subject</a>
 <td><a hrefref=link_foo>Message fragment</a>
 <td><a hrefref=link_foo>Message author</a>
</tr>

(Specifying href is allowed if it has the same value as the link_ref href, if the author wants that kind of back-compat.)

This is similar in the design to the form="" feature on form controls.

(In reply to comment #8)
> (In reply to comment #7)
> > Yandex.Mail is just a real-world example of tabular data marked-up nontably
> > (unsemantically) just due to markup-language limitations.
> 
> Why the "just"? It's exactly what we're looking for -- real world pages working
> around the lack of the feature.

It's not rare when lack of a feature results in avoiding corresponding designs at all. So searching for real-world examples of simulating _exact_ feature that is _absent_ currently is often pointless and unhelpful.

> > But even in this
> > case, as I've highlighted in comment 5, link fills _most_ of row space.
> 
> They wouldn't want to the link to fill *all* or the cells, correct?

Let's put that Yandex.Mail is an example of need for single link to span several _cells_.

> > So just ability to have `href` for `TR`
> > is probably most viable option.
> 
> Why provide a solution that only almost solves the problem?

Because it's better than not providing a solution at all.

> > Treating multiple cells as one single link is one of major purposes here (aside
> > from trivial "DRY" principle, this allows to hover cells as an integral unit).
> 
> OK, so, act as a single link for the purpose of focus navigation and the
> :hover/:active/:focus selectors?

...and not forcing to have multiple repetitious things (individual link for each cell instead of one link) violating "DRY" (Don't Repeat Yourself) principle.

> > Another purpose is that such link row would have height adjusted by browser
> > automatically according to height of most high of cells in particular row; this
> > is problematic with independent links nested into different cells (even aside
> > from undesirability of having multiple adjoining links pointing to same URL
> > just because of markup language limitations).
> 
> Hmm. This seems like something that should be solved in CSS rather than in
> markup.
> 
> An alternative proposal:
> 
> <tr>
>  <td>checkbox
>  <td>date
>  <td><a href=/foo/ id=link_foo>Some subject</a>
>  <td><a hrefref=link_foo>Message fragment</a>
>  <td><a hrefref=link_foo>Message author</a>
> </tr>
> 
> (Specifying href is allowed if it has the same value as the link_ref href, if
> the author wants that kind of back-compat.)
> 
> This is similar in the design to the form="" feature on form controls.

Unfortunately this is not a good idea since this forces us to assign a unique `id` to elements, which is impractical/unusable when markup is created manually.

(BTW `aria-labelledby` attribute sucks for exactly the same reason.)

A really viable solution should be as simple and straightforward to use as wrapping multiple `TD` elements in `A` element would be (like `<a href="#"><td></td><td></td></a>`). `href` attribute for `TR` element looks like such a solution.

Another real-world example of whole table-row acting as solid link is project list of an author on Google Code:

http://code.google.com/u/109330852418236875528/

Link behavior is emulated via JS, and (not surprisingly) browser's native ways to open links other than click itself do not work as long as you don't click exactly text of link itself located in second cell of each row.

For example, Ctrl+Click does not open link in new tab, it does open it in same tab instead. Middle click does not do anything at all though it should open link in new tab too.

I don't really see why that's a problem. When the user wants to click the link to get its options, the link is right there and clickable; the rest of the time, you can click anywhere in the row as a convenience. This is pretty much exactly what is described in the FAQ:

   http://wiki.whatwg.org/wiki/FAQ#HTML_should_support_href_on_any_element.21

It seems perfectly adequate to me, especially considering the downsides of making more elements into link elements (also described in the FAQ).