Comments on: The Missing Link

By: Tony

Tony — Tue, 01 Sep 2009 15:09:20 +0000

Gawd. I don’t know when my brain got things mixed up, but up until about 20 minutes ago I thought that the @href attribute was going to be global in HTML5.

GRR!

Regarding the following: Browser vendors have reported that implementing it would be extremely complex.

I would echo your response to reason #1: Neither [ were tons of things implemented in several browsers ] or any number of other worthwhile advancements in the web.

I mean, is it easy to get a browser to pass Acid3? I don’t personally know for sure, but I’m going to go with No. But browser vendors still work for it.

Gah, Eric, please beat some sense into the spec authors on this point!

By: Rexibit Web Services

Rexibit Web Services — Tue, 22 Jul 2008 15:25:48 +0000

True Chicco, but again it comes to how you want to conform your site to the standards. If you are going to create links, they need to be usable over various other mediums as some sites to pull content off yours to theirs. I doubt they would continue to help build your links and content distribution if you were causing them validation errors.

By: Chicco

Chicco — Thu, 17 Jul 2008 09:12:38 +0000

Well, technically speaking there is more than one way to do this and make it compatible with a range of browsers.

I can’t see specific technical usage for extending “href” attribute to tags like “tr” but I guess this would turn to be useful to (smart) marketer… ;-)

Cheers/Chicco

By: gossard

gossard — Sat, 12 Jul 2008 02:05:23 +0000

Sebastian, xlink:href in Mozilla does not actually work on HTML or SVG elements last I checked. (It apparently didn”t come for free when implementing it.)

By: Trevor Davis | Blog | Weekly Link Round-Up #34

Trevor Davis | Blog | Weekly Link Round-Up #34 — Tue, 10 Jun 2008 02:49:25 +0000

[...] The Missing Link [...]

By: Vlad Alexander

Vlad Alexander — Fri, 06 Jun 2008 12:31:32 +0000

Anne, help me understand why HTML 5 folks don’t think that changing the meaning of numbered headings will not confuse users? Headings are the most important construct for making Web pages accessible but almost nobody uses numbered headings correctly. Why not fix this serious problem? The section/h construct is the best solution.

The section/h construct must also be structured just like tables, definition lists, and ordered/unordered lists. Every section element must have one h element as the first element. For example:

…content goes here…
… content and other section elements go here …

As an authoring tool vendor, we believe that the use of structured section/h construct is the only way to ensure the correct use of headings in authoring tools.

By: Anne van Kesteren

Anne van Kesteren — Thu, 05 Jun 2008 10:41:04 +0000

Ben, Firefox 3 will allow proper styling of section and for Internet Explorer you need to use the document.createElement('section') hack for a while I suppose. Using h would mean that older assistive technology for instance doesn't even recognize it as a heading and not use it in the document outline. That seems bad. The styling issues you mention we'll have to overcome anyway. Using h will not magically solve those. In fact, it's not really clear what problem h using would solve.

By: Ben Buchanan

Ben Buchanan — Thu, 05 Jun 2008 01:21:51 +0000

@henri: I do not consider a document full of h1 elements to be the same as a document using h elements. h1 has an existing meaning and personally I only use one h1 per document. So it is my opinion that a document full of h1s is not a proper contextual heading system, it's a halfway hack. I also fail to see any logical reason why you would allow the addition of section yet decide that h should be left out because it's "not backwards-compatible". If you use section, Firefox and IE aren't going to be able to read and style the page properly (based on a quick test, Opera and Safari allow styling via section). Remember you're going to have to use section to contextually style all those h1s into something with a visual hierarchy, which will break in non-html5 browsers just as much as h would break. Anyway, I've had this argument before and I know HTML5 isn't going to have h. The working group's decision making process just bothers me, and it appears to bother at least a few other people as well.

By: Max Design - standards based web design, development and training » Some links for light reading (4/6/08)

Wed, 04 Jun 2008 12:48:22 +0000

[...] The Missing Link [...]

By: Anne van Kesteren

Anne van Kesteren — Wed, 04 Jun 2008 08:33:58 +0000

Sebastian, xlink:href in Mozilla does not actually work on HTML or SVG elements last I checked. (It apparently didn't come for free when implementing it.)

By: Henri Sivonen

Henri Sivonen — Wed, 04 Jun 2008 05:04:26 +0000

Ben, HTML5 has a system like h+section. In that system, h is just called h1.

By: Isaac Lin

Isaac Lin — Wed, 04 Jun 2008 02:30:50 +0000

Anon: no, the reverse is far more work since it would be a never-ending tasking of justifying why every existing and proposed attribute didn’t belong on every existing and proposed element. Note too that by understanding the use cases (i.e. problems) that need to be addressed, we can potentially identify what elements have common characteristics that are at the root of the problem, and so the rationale behind the proposal can encompass all of these common elements at once. This is one of the values of working out a clear use case: it helps you step back to look at the problem from a wider perspective.

By: Ben Buchanan

Ben Buchanan — Wed, 04 Jun 2008 01:50:14 +0000

I've found the WHATWG use the backwards compatibility argument whenever it suits their decision, yet ignore the same issue with all the new elements they ARE creating. The biggest failure for me was the lack of a generic, extensible heading system. XHTML 2 had h+section, HTML5 just has h1-6 but it DOES have section. Because that makes sense. H wasn't ok, but SECTION was? I'm starting to think we'll never use HTML5, something else will come along and bypass it.

By: Maniqui

Maniqui — Tue, 03 Jun 2008 21:56:35 +0000

Although on a first read, I thought: “hey, this is a good idea”, I think I still don’t get it, sorry.

Wouldn’t this make the element totally unnecesary? (this isn’t necessary a problem)
What about nested elements where both parent and child have a value for the href attribute? And in this case of nested “links”, wouldn’t this arise some serious accessibility problems? It’s difficult enough for some people to click on a single isolated link; nesting an “inline-element link” on “block-element link” could really be a new challenge for navigating?

I hope I’m not missing something here.

By: Anon

Anon — Tue, 03 Jun 2008 15:06:06 +0000

J King: That’s a bit unrealistic, isn’t it, given the number of HTML elements there are? Shouldn’t the point be: justify why the majority of elements should NOT support the href attribute.