
The HTML A element is broken - onderhond
http://www.onderhond.com/blog/html-links-are-broken
======
Terretta
> _From a conceptual point of view their implementation makes no sense at
> all._

If your concept is that blocks of design should do things when clicked, that
idea is valid. Thankfully, we have methods for easily capturing click events
on arbitrary and nested blocks--in fact a whole language for handling events
across the representation of layout.

Meanwhile, hyperlinks were for terms in hypertext, and A are the anchors
around terms, helping you make a TOC and Index within a single document. The
semantic meaning of A is, "this is a term" and A HREF is "this term
conceptually relates to this other hypertext reference".

Nobody's forcing you to overload that very simple concept, and certainly
nobody's forcing you to wrap headers and footers and main divs _inside_ an
anchor. I feel that your application of the anchor is broken.

~~~
sophacles
_Meanwhile, hyperlinks were for terms in hypertext, and A are the anchors
around terms, helping you make a TOC and Index within a single document. The
semantic meaning of A is, "this is a term" and A HREF is "this term
conceptually relates to this other hypertext reference"._

Except that images have been linkable since forever, and they are not really
"terms in hypertext". Once you start allowing other items than text inside
your anchored reference, you have to accept that the relations may become more
complicated than a simple, single graph edge. The reference content may in
fact be a block quote with a deeper nested reference within itself... and so
on.

~~~
saraid216
> Except that images have been linkable since forever, and they are not really
> "terms in hypertext".

Images are text, at the academic level that hypertext was originally
conceived. That's why it makes sense to click and drag an image into Google
search, and why it doesn't make sense to do the same to a random div.

~~~
sophacles
So seriously, what about blockquotes? They are just text that may be related
to the source (not a stretch of imagination I hope), and which also may
internally contain links in the quoted section?

Going back to the img example: What if I want a navbar? The semantically
linked thing is not a random div, it is the whole button area, not just it's
text. What if it contains a "help with this option" icon with in the area,
that is semantically different from it's surrounding button?

The argument is that if an image is "text", then other elements that aren't
just words, can in fact be "text", because they have semantic value.

~~~
saraid216
"bold" isn't text, and neither is "blockquote", which is the same thing:
they're styles.

~~~
sophacles
Argh... blockquote has semantic meaning - this is quoted text.

Bold is a style. Hence it being phased out in favor of emphasis (em).

Seriously, your entire argument right now looks like: "there are only three
semantic things - anchors, images and text". It ignores the notion of
headings, lists, partial references, nested references, sections, etc. These
all have textually semantic meanings apart from styling.

Are you just trolling, or are you honestly refusing to acknowledge that there
are semantic meanings for things other than the three I mentioned?

~~~
saraid216
Yeah, I was kinda unclear. I apologize for that.

Terretta covered it as well as I could have, so I'll just elaborate on a
couple things.

Using the word "content" is a lot clearer here: the point is that it's non-
structural, rather than that it is non-semantic. It doesn't make sense to
hypertext structural elements, but it does make sense to hypertext pieces of
content.

Let's say I have a massive corpus. That corpus is composed of text, images,
perhaps some audio and video files, whatever. That corpus is _structured_
using markup, by saying "this block is a quote of something else; this block
is the header; this block is a list and these blocks are its items" and so on.

That all assumes it's text, of course. If it's a 2d image, that might actually
be an image map, in which certain portions are sliced off, defined as
subsections (much like an UL tag with LI children), and sensibly linkable.
Differently, an audio file might have specific time intervals linked
elsewhere; we don't have a UI for dealing with that purely yet (and maybe will
never find a reason to have one). And YouTube & co have demonstrated ways of
doing video linking. If you link to a specific second of a YouTube video,
that's no different from a table of contents in a hardcover book: it's the
automatic movement that makes it hypertext.

That's what hypertext is. It links two pieces of _content_ together. An anchor
tag is just how we've done it so far.

And I need to emphasize that this is an academic perspective and mostly useful
for thinking about how to design a browser's API. And I'm overwhelmingly _not_
qualified to do that. As a web developer, it's mostly impractical to think
about this at all: it has _nothing_ to do with developing web apps.

------
p4bl0
IIRC, in one of the early draft of HTML5, the <a> tag was there for
retrocompatibilty but was deprecated, and href was a valid attribute for all
HTML5 tags in <body> and its children.

I thought that was a brilliant idea. For link on block but also for common
pattern such as the infinite <li><a href="">…</a></li> that we see everywhere
and which lead to confusion (which parts of the style should be applied to
<li> elements, which parts to the <a>?).

I really don't know why W3C didn't keep this idea in HTML5.

~~~
lucian1900
Probably because too much would get broken. That is sadly very often the (even
more sadly, correct) argument against doing things right.

~~~
p4bl0
If the change is only to allow the href attribute on any tag, how would that
break anything?

~~~
hatu
Older browsers might go crazy

~~~
DoubleMalt
Who cares? If you use HTML5 you have to throw them under the bus anyway.

And most (older) browsers ignore unknown attributes anyway.

~~~
UnoriginalGuy
HTML5 in general degrades fairly well, with the exception of with browsers
which simply don't support CSS at all (e.g. IE5 and below).

You're right to say that older browsers would ignore the unknown attribute,
the problem is that having links broken might degrade that site to a point
where it isn't usable.

~~~
DoubleMalt
But it would be pretty easy to create a polyfill that attaches onclick
handlers to the respective elements.

Actually I'm tempted to write one to get this functionality with current
browsers.

[edit] As Oscar Wild put it: The only way of getting rid of a temptation is to
yield to it.

<https://github.com/webcrofting/href4all>

~~~
Torrents
That's awesome! From concept to github in a flash. Well done.

------
SquareWheel
Oh wow, I've been wishing for ages that href were an attribute and not a part
of the <a> tag. This is validation that it isn't such a terrible idea after
all.

    
    
        <img src="pic.jpg" href="about.html">
    

Doesn't that just look _cleaner_? Shame it won't change until something
radical supersedes HTML.

~~~
Alexandervn
No so clean to me, without an 'alt'-attribute..

~~~
tzaman
alt is beside the point here

~~~
jackalope
It's a fair point, though. The href attribute tends be very long, so if your
criteria is readability, do you opt for attribute soup or put it in a wrapper
div or span? It's a subjective decision, and I don't think there's a right or
wrong answer, but examples should reflect real world situations.

Either way, I think href should be a universal attribute (obviously, it
wouldn't make sense on something like br). It offers a lot of flexibility and
is probably no more subject to abuse than anything else. I don't see how
browsers would have a problem implementing it. Just look at the 3D view of a
complex page in the Firefox Inspector to get an idea of what they're already
coping with.

------
Tloewald
Broken except insofar as it's simple and works as intended. Read article,
totally unconvinced.

~~~
mongol
So true. The overload of "broken" when you want to say "not working as I would
like" is annoying.

~~~
TwistedWeasel
I think it's a bit of an overused term:
[http://www.hnsearch.com/search#request/submissions&q=%22...](http://www.hnsearch.com/search#request/submissions&q=%22is+broken%22&start=0)

------
roel_v
This thing reads like it was generated by the html-nerd equivalent of
<http://thatsmathematics.com/mathgen/> . Does anyone understand his point? Is
he saying that he'd like to be able to attach a link destination to all html
elements, not just <a> elements?

~~~
nnq
Basically yes, and he's not the first one that thought of this: it actually
"almost" made it into xhtml2 and html5, because it's _a great idea that really
makes sense_. But it will never get to be this way any time soon because
behaviors for all elements that have href attributes will have to be
specified, including for cases of nested elements with href set. This could
happen, but not in the design-by-committee world of web-standards - _you'd
basically need to have bunch of very smart guys conjure a new specification
out of thin air and force everyone else to use it regardless of backwards
compatibility or other consequences (unfortunately this will never happen in
the world we're living in)._

------
hawleyal
It's not a link tag. They're not just links. It's an anchor tag. That is the
semantic purpose. The URI reference and a title is definitely semantic.
Together the identification of a resource. It's not just metadata or
presentation.

\----------

\- Person

\- Thumbnail

\- Name

\- URI

\- Posts by person (URI)

\----------

\- Post

\- Title

\- URI

\- Author (URI)

\----------

You might say the entire person block could have a reference to it's URI. But
more important is the posts by person anchor, and the related author anchor.
They are the anchor points from which you leave each document.

Sure, you could add that functionality to other blocks, but they would already
have other semantic meaning. Like a list item with a reference is still just a
list item.

This tag is semantically its own.

One could make the same argument about any semantic tag for inline content.
Like `em` or `strong`. You could of course indicate emphasis of an entire list
item using a CSS class, but it's still just a list item. And the ability to
use emphasis on other tags does not negate the need for an `em` tag for just
that purpose.

------
tzaman
I totally agree with the post, linking is somewhat broken. In our application
(<https://codeable.io>), we have a table with tasks, where each row links to
the single view for the task. Inner wrapping each <td> didn't really "feel"
right, so I just went with javascript approach, having data-link attribute on
each table row, then redirecting the user on click.

I know you might ask _what about graceful degradation?_ , but the truth is our
app relies heavily on javascript (websockets) to work, as 90% of modern
apps/sites do, so we decided to ignore it. We don't like that, but something's
got to give.

~~~
jdavid
the larger problem with javascript linking is, the 'new tab' problem. On
windows and linux center clicking the mouse on a link opens a new tab and does
not focus on it. most javascript does not simulate this behavior.

~~~
Tloewald
This is a good point and does actually show that allowing hrefs in any tag
could be a solution where an anchor won't do. Also you cannot simulate right
click options as you'll either get a new tab or a new window at best.

------
cosmikduster
In my opinion, the <a> tag needs a few boolean attributes:

    
    
        ad-supported: true|false,
        requires-free-registration: true|false,
        behind-paywall: true|false. :-)

~~~
alanctgardner2
This isn't a terrible idea, but I think it belongs in the header (maybe meta
tags) of the page to be loaded. Then if you added a paywall to your site,
you'd update your server config, rather than trying to round up every
hyperlink to your site ever. Imagine if Chrome could do a HEAD one link deep,
and indicate visually whether you'll actually be able to see the page, or
whether you'll be solicited for some personal info.

In the meantime, someone could write a Chrome plugin that uses a blacklist to
rewrite links to paywalled sites.

~~~
icebraining
_it belongs in the header of the page to be loaded_

Yes, but they have no real incentive to put them there, since they want people
to see the paywall (and possibly subscribe). Besides, many paywalls are
dependent on the user (e.g. she may have some free views per month or so).

------
DomreiRoam
The fact that you have a specific tag for linking make a lot of sense:

\- it allows to have multiple links for an element.

\- you can add information about the linked resource like semantic relation
with the current context (rel or rev), content type of the link, language ...

Maybe it would be nice to have the following behavior: when you have a anchor
tag without a closing tag it would mean that the anchor context is the parent
element.

------
Kiro
I've never had this problem. Why would you even wrap a block with a tags at
all?

~~~
nollidge
Yeah, this is what I don't get. Also, why would I want to nest anchors? That
doesn't make any sense.

~~~
netrus
It would be cool if I could click anywhere on your comment and get to the
"reply" page - except if I click on the small "link", a nested link.

~~~
talmand
That could lead to UX problems though. What if I meant to click on a link but
missed because, assuming you style it this way, I get the cursor that
represents a link on both so I couldn't tell the difference? Therefore, I
would end up going to an unexpected page because the link I thought I clicked
on represented something different to me than what I ended up with.

Of course, you could just give a visual feedback of what is the current link
that will be followed but that might be annoying to some depending on the
design.

~~~
SquareWheel
If clicking a comment just opens a small textbox beneath the comment then it's
not a big deal if they miss. But I can definitely see having different pages
loaded being a problem.

But ultimately, it should not be a limitation of the technology that
determines what is an isn't usable. That's a job for UX designer, and they
should have every freedom with the technology to create their designs.

~~~
talmand
Although I agree that it would be best for an UX designer to make such
decisions, most of the time one is not involved and there has to be some sort
of limit based on some standard. If you allow potentially bad decisions, then
ultimately a great deal of bad decisions will be made. For example, look at
how browsers will render absolutely awful HTML soup and the state of most of
the HTML out there.

------
devinblais
Usability is also a big reason to not wrap giant blocks with an anchor tag.
Anchor tags should be text (or an image) that clearly indicates where they are
leading the user to. If you're linking all parts of a block to something,
there are serious usability implications. Why not just link the title of the
article? Or throw a link at the bottom that says "Read more"? You can't say
the anchor tag is broken because you're trying to use it for things it's not
intended for. That's like me saying my computer is broken because it can't
make me a grilled cheese sandwich.

------
danso
So...semantically, what does a link inside a link mean? It would seem to be
non-sensical...an article is given an href but the article itself contains
links elsewhere. What is a search engine supposed to think?

~~~
deno
Inner-most links take precedence, with the exception that non-absolute nested
links are relative to outer links. E.g.

    
    
        <ul href="http://example.com/examples/">
           <li href="1">Example 1</li> <!-- http://example.com/examples/1 -->
           <li href="/foo/bar">Foo Bar</li> <!-- http://example.com/foo/bar -->
           <li href="http://example2.com">Other examples</li> <!-- http://example2.com/ -->
        </ul>

~~~
scott_w
Funnily enough, I disagree. I think nested links just shouldn't be allowed at
all.

As ever, people are the great blockers to any implementation :-)

------
DoubleMalt
Just hacked a quick enhancement together. Please comment, improve or ridicule.

<http://news.ycombinator.com/item?id=5331146>

------
rquantz
He may have a point about hrefs on arbitrary elements, but the main thing I
took away from this article was lots of examples of why not to use direct
descendant selectors.

------
csswizardry
> Another recurrent problem is that links cannot be nested.

This bit piqued my interest, so I made this: <https://bitly.com/13F3dIy>

------
stcredzero
Okay, so your blog is going to break zooming _and_ Reader? Do you dislike
readers on tablets? It's a bit odd to go on about anchor tags being broken,
when your site is broken to a big part of the readership.

------
lmm
If you want to actually solve your practical problem, I suspect a proposal to
change CSS would have more chance of being accepted than one to change the A
tag.

------
jdavid
Just write a polyfil in javascript for the functionality you desire on your
site. It shouldn't be that hard to implement.

------
thomassturm
From a UX and accessibility perspective, not allowing nested A tags is a
feature.

~~~
SquareWheel
I posted this above, but my thought is that it should not be a limitation of
the technology that determines what is an isn't usable. We should give
developers the freedom to make their own choices regarding UX.

I find the anchor tag a limitation, whereas an href attribute allows for much
more freedom without resorting to using Javascript. Well, in theory; in
practice you would need a shim for older browsers.

------
user24
OT: Damn that's a nice blog UI.

~~~
millerm
+1

