These techniques don't meet basic accessibility guidelines and should be avoided. I'm pretty sure option 2 would completely break table navigation for screen readers. If it's tabular content (so you're using a table) and you want a larger link target, I would try a combination of row height and min width on the row header with the link.
Similarly, option 1 completely breaks many expected features of links. The article smugly provides an option for control-click, and says the "only" remaining issue is the lack of hover preview, but completely forgets about implementing middle click, to say nothing of right-click (which can't be implemented).
I'm literally BEGGING web devs to stop trying to re-implement anchor tags in javascript. Every time I use some shitty SPA that decides to ignore my middle clicks on links, or worse, treat them as left clicks and navigates away from the page I was trying to leave open, I die a little bit inside.
Using inspector I threw together some divs and styled them using the aforementioned CSS property values and it definitely works. Columns work, and it even responds to table-layout: fixed! You only lose the ability to use rowspan/colspan attributes but that's about it.
I was thinking about posting it but checked ARIA recommendations to figure out what additional attributes would be appropriate. It strongly recommends against switching interactive elements (a link) to non interactive (grid row). For example, this doesn't validate:
If the markup is not semantically a table, then CSS grid is probably the correct approach. If the content really is a table, then it is very hard to imagine how making an entire row into a link could be meaningful. In the GitHub table, for example, does the author really think that clicking under Author should link to the PR, and not to the author themselves?
In practice, most tables with each row being a resource have a single column which is the meaningful one to be a link (e.g. the title or name of the resource).
> If the content really is a table, then it is very hard to imagine how making an entire row into a link could be meaningful.
There are many “skin on a database” type use cases where it can be valuable to present information that’s both tabular (eg summary of columnar information for multiple rows) and navigable (eg to individual row details, edit interface, etc).
There are also many classic (non-web) interfaces with conceptually similar prior art. One that immediately comes to mind is music players, where it’s common to present song list data as tabular, and allow selection of the full row.
These presentations are relatively out of popular usage… but I think that would make them more appealing to a HN audience, which tends to skew heavily in the direction that older UI paradigms were more usable.
> If the content really is a table, then it is very hard to imagine how making an entire row into a link could be meaningful.
While not a link, each file in a MacOS Finder List view is selectable view a single click target that encompasses the entire table row. It's definitely a table, and the entire row is a click target. Is that also odd, or is the _link_ part of it the thing you specifically find odd?
The Finder list view is not a table, you can't select any of the data other than the name. I also don't think you can keyboard navigate the data by column but I can't check that right now.
I’d say it’s definitely a table. It has configurable columns which you can sort by. I don’t think “table” implies being able to edit cells or navigate by cells, since that’s certainly not how HTML tables work by default.
A screen reader can absolutely navigate tables by cells, by row and by column.
But my mistake, VoiceOver calls Finder's list view a table and can navigate vertically in a column and you can navigate vertically without VoiceOver if you enable Full Keyboard Access (FKA).
And when the bulk of the page is the table, it is very obnoxious to click into the window to focus, (or unfocus an input), and suddenly you are whisked away to another page
Yep, basically the "block links" technique used to make clickable cards. A downside is it prevents selecting any text covered by the pseudo-element; the JavaScript technique can have the same problem.
Your 'pen has `td { position: relative; }` so the link's pseudo-element is not actually covering the row, the row only gets the visual styling that makes it appear clickable.
If you remove the positioning from the `td` and add `tr { position: relative; }` then you'll find you can activate the link by clicking anywhere in the row but you can't select the text in the row (because the link's pseudo-element is "covering" it). However, if you start a text selection outside the table, you can select the whole table (or the first however many rows you want).
This post includes some JavaScript as a progressive enhancement that tries to differentiate text selection from clicks.
> The only remaining issue with this [JS] solution is that the user doesn't get the URL preview provided by browsers when hovering over anchor elements. There is currently no workaround for this.
True, there is no workaround, but you can achieve something kind of similar by adding a title attribute (e.g. title="foo") to the <tr>.
The <table> element has so many arbitrary restrictions (that I'm sure have their legacy/accessibility reasons) that it's honestly not usable in a fully featured table component. For simple tabular data display, sure. But for anything beyond that, just use divs.
