The HTML A element is broken
onderhond.com
onderhond.com
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.
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.
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.
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.
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?
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.
That's not what he said. Also, those are not similar things. A, with or without HREF, can wrap the other two. Images and text are symbols of meaning where the text defines itself as to what that meaning is, and the image defines itself as to what that meaning is.
A blockquote indeed means something, but it doesn't define itself. It just sets off text from other text. It needs text (one of those two things above) inside it to convey the quoted meaning.
Put another way, a blockquote is not content. Text is content, as is an image.
While I agree block-linking seems like an odd way to implement the desired functionality, the idea that javascript (did you mean javascript?) is a more suitable alternative is dubious.
The concept of requiring an entire engine to enable linking from HTML elements just seems dirty, when it could be achieved so much more simply with a universal href tag. For starters, how would one define link targets?
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.
And most (older) browsers ignore unknown attributes anyway.
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.
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.
<img src="pic.jpg" href="about.html">
<img src="pic.jpg" data-href="about.html">
Of course, there is the question of how well this would work on older browsers, although actually as long as javascript is not disabled I don't think it would give much trouble (data attributes can be easily fetched in IE6 for instance)
Edit: Here's a quick and dirty demo of how this could work: http://jsfiddle.net/Dszvc/2/ it could easily be turned into a full featured plugin.
<img src="pic.jpg" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="about.html" />
You’d still need JS polyfill, but at least the semantics remain intact.
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.
----------
- 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.
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.
Users with JS get <tr data-href=""><td><a href="">Content</a></td></tr>, with JS doing as in your example.
The downside is that we'd have to repeat ourselves, but at least the system will degrade somewhat-gracefully.
ad-supported: true|false,
requires-free-registration: true|false,
behind-paywall: true|false. :-)In the meantime, someone could write a Chrome plugin that uses a blacklist to rewrite links to paywalled sites.
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).
- 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.
It's actually unfortunate that in so many cases where people wrap blocks with anchors, they go for the inner-wrap method which has a major downside in that the inner anchor does not span the entire block by default. That means that there are a lot of, say, logos that have padding you can't click on (contrast with the horrible ads that have clickable whitespace).
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.
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.
<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>As ever, people are the great blockers to any implementation :-)
This bit piqued my interest, so I made this: https://bitly.com/13F3dIy
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.