Friday, July 25th, 2008

HTML 5 Linking all around the horn

Category: HTML, Standards

Eric Meyer has been working on an HTML 5 linking proposal and has put together a demonstration of his proposal.

His linking demo shows how you could put href="..." on paragraphs, table rows, cells, and many other places.

This demo is done with simple JavaScript for now, with the obvious hope that browsers natively support these features in the future.

Posted by Dion Almaer at 7:51 am
11 Comments

+++--
3.7 rating from 19 votes

11 Comments »

Comments feed TrackBack URI

Well written and deeply researched into though the whole idea is mostly a bad suggestion… :|
Apart from the “linking complete table rows” part I see no apparent gain, only drawbacks since this is a MASSIVE change that will render completely invalid browsers for decades, meaning your website will break for decades if you start using it and as a result nobody will use it and therefor no browsers will rush to implement it…
Also “separation of concerns” is a beautiful construct and adding up tons of new attributes for every single DOM element is NOT “separation of concerns”…
.
Creds given though for the deep research and the stress on w3c :)
Though I’d expect “hell to freeze over” before this is implemented for obvious reasons…

Comment by polterguy — July 25, 2008

Wasn’t this part of the XHTML 2 spec ?
Whatever I like it :)

Comment by Yves — July 25, 2008

“this is a MASSIVE change that will render completely invalid browsers for decades, meaning your website will break for decades if you start using it and as a result nobody will use it and therefor no browsers will rush to implement it”

I don’t follow your logic – if Eric has a _WORKING_ JS demo in Fx2/Saf2/O92, then an unobtrusive library can be written to support these older browsers while new browsers implement the feature.

There are two cases:

– you’re not using ‘link-anywhere’, old-style-linking will still continue to work
– you’re using ‘link-anywhere’, which means you need to use JS to handle older browsers

On the other hand, apart from linking an entire table row, everything else seems do-able today by wrapping things in a html:a element. Therefore, I don’t see this as a huge benefit.

Comment by codedread — July 25, 2008

@polterguy: Don’t be so dramatic. With a little javascript you can easily make this work in current browsers.

Though I agree that it’s not likely to see the light of day. The pay-off is too small, and there will be too many people opposed to it.

I wouldn’t mind it, but I don’t have a particular need for it either.

Comment by Joeri — July 25, 2008

@polterguy: Well with that attitude, so much for improving the spec at all. After all, if IE never implements ________ it isn’t worth having, right? As much as I hated it, it might be time to subtly bring back “best viewed in [a-grade browser list]” notices. There’s no question, with the Webkit, Gecko and Presto teams on board for HTML 5 and already implementing parts of it, that we can’t expect the whole spec to be implemented before it’s even published. It’s just, as always, IE holding us back.
.
Well, I say screw ’em. Until IE doesn’t work for huge swaths of the web, MS isn’t going to see the pressure that its users are either going to expect improvements or bail. Perhaps the IE 8 team’s attitude too? :D
.
‘Also “separation of concerns” is a beautiful construct and adding up tons of new attributes for every single DOM element is NOT “separation of concerns”…’
.
I don’t think it any more entangles concerns either. To me the question is: is hyperlinking an integral part of the web, or an element of the web on par with document structure in general? Is there any philosophical reason that there needs to be a separate element with completely arbitrary constraints (can only contain inline elements being the most obvious) instead of allowing any element to be a hyperlink? I mean, the anchor tag is, for all intents and purposes, a span tag with href (and a few other link-specific) attributes. Why an inline element? What sense does that make?

@codedread: “On the other hand, apart from linking an entire table row, everything else seems do-able today by wrapping things in a html:a element. Therefore, I don’t see this as a huge benefit.”
.
Really, you can [correctly] wrap a set of divs with a single link (thus avoiding unnecessarily verbose and redundant markup)? Or, for a more realistic use case, an entire blockquote?
.
@Joeri: “The pay-off is too small, and there will be too many people opposed to it.”
.
I think the payoff would be tremendous, and why would so many be opposed to it?

Comment by eyelidlessness — July 25, 2008

@eyelidlessness
If we start talking about an “integral part of the web” one could probably argue the same about everything. Why not create a new Common Attribute named; “imgSrc” to make it possible to have images for EVERY tag in the HTML spec? This would have the additional benefit of making it possible to both use images as inline elements and block-level elements. Though then of course we’d have to add up alt attributes also for all tags. And while we’re at it why not add up accessKey attributes for all tags? Or even have the block/inline level be an attribute and have the inline default value of elements be overridden if the “elementType” was given, and so on, and so on…
.
Now the reason is apparent. All those constructs have EXISTING ALTERNATIVES already. Just like the href attribute for document.getElementsByTagName(‘*’) also have EXISTING working alternatives!
.
The first thing a standardization committee asks itself when starting a new standardization process is “do there exist valid standardized solutions for achieving the same in another standard”. And unless your company name is MSFT and you’re trying to standardize ODF”2.0″ and you spend a bayillion on lobbying then the standardization process will be shut down before even started if the answer to the first question was yes!
.
“I think the payoff would be tremendous, and why would so many be opposed to it?”
Whoa…!
What was in that cup of teat you just had man…?
.
Sorry if I sound offending, but it sounds like you either wrote the original article and you’re trying to defend your first suggestion (which was *bad*) or that you have another agenda that you don’t want to come clean about…

Comment by polterguy — July 25, 2008

@polterguy: Not to step into a flame-war here, but that last statement of yours could equally be applied to you: you sound like you have an agenda as well. I mean, why else would you so vehemently oppose something that, at worst, people wont end up using?

Comment by Jon Hartmann — July 25, 2008

@Jon, eyelidness

He used the exact same comment to describe my reaction to his widget toolkit. Anything that doesn’t fall into the “polterguy” field of acceptance is immediately is cast as an “agenda” – as if we are disgruntled members of the IE development team here to pick on him.

Comment by matanlurey — July 25, 2008

@polterguy:
“If we start talking about an “integral part of the web” one could probably argue the same about everything.”
.
Except that it’s actually true of hyperlinks; they’re part of the foundation of the web.
.
“Why not create a new Common Attribute named; “imgSrc” to make it possible to have images for EVERY tag in the HTML spec? ”
.
I would argue that it’s because images are things with their own semantic meaning, while hyperlinks are essentially metadata about the content between the tags, and the tags themselves have exactly no meaning (until you assign the href attribute to elements with a meaning). The a element is simply a span with the ability to add a href attribute (and other hyperlink metadata); the img element is an exact one to one semantic mapping to an image resource, displayed inline with the page. Moreover, the fact that it’s displayed inline is another clear distinction: after all, writing an anchor tag with href metadata pointing to google does not add the content of the google page it points to into the page inline with the rest of the content. It’s not an object; it’s a metadata tag.
.
“This would have the additional benefit of making it possible to both use images as inline elements and block-level elements.”
.
This is already possible.
.
“And while we’re at it why not add up accessKey attributes for all tags?”
.
I don’t see the harm in that.
.
“Or even have the block/inline level be an attribute and have the inline default value of elements be overridden if the “elementType” was given, and so on, and so on…”
.
I don’t even understand where you’re going with this. Allowing block level elements to be hyperlinks isn’t a huge drastic change to the philosophy of HTML at all; it simply allows links to be block structures which can contain other block structures.
.
“All those constructs have EXISTING ALTERNATIVES already. Just like the href attribute for document.getElementsByTagName(’*’) also have EXISTING working alternatives!”
.
Huh? There is an existing alternative, in markup, to making a table-row a link?
.
“Whoa…!
What was in that cup of teat you just had man…?”
.
Why do I have to be… high or drunk? is that what you’re implying?… to ask why people are opposed, and say that I think it’s beneficial?
.
“Sorry if I sound offending, but it sounds like you either wrote the original article and you’re trying to defend your first suggestion (which was *bad*) or that you have another agenda that you don’t want to come clean about…”
.
Wow, and people say I’m paranoid. No, I didn’t write the article; I didn’t even read it, to be honest. The post caught my attention, though, because this was something I liked from the XHTML 2 spec, and was interested. That’s my agenda. I like the feature, and would like to use it yesterday.
.
@matanlurey:
Hey, I don’t mind being accused of having an agenda. But I don’t know where the accusation that my agenda’s hidden came from; after all, I laid it all out for everyone to see. I want this feature and I want it yesterday. That’s all.

Comment by eyelidlessness — July 29, 2008

Incidentally, was it XHTML 2 that removed the img tag and replaced it with object? I was fond of that as well.

Comment by eyelidlessness — July 29, 2008

@eyelidlessness, yeah it was XHTML 2.

Comment by matanlurey — July 29, 2008

Leave a comment

You must be logged in to post a comment.