Are Links without Any Content Valid (HTML5)?

[deeper]

Hi,
[w3.org...] says:

If the contents of an a element are empty, the element represents an empty hyperlink.

Does that mean, that <a href="http://www.example.com"></a> is completely valid?
No text, no img, no transparent px, no & nbsp;, really nothing.

I cannot test it because right now I have no html5, but if the answer is yes, then all browser should deal with it properly, right?

[diddlydazz]

hi deeper

yes, running an empty hyperlink through the validator (http://validator.w3.org/) will validate (HTML5).

are you having issues in a certain browser?

[lucy24]

then all browser should deal with it properly, right?

Sure ... if by "properly" you mean "the browser will correctly follow the link if the user succeeds in clicking on it-- which can never happen, since its screen space encompasses 0 pixels".

You may be thinking of the form

<a name = "letter-a" id = "letter-a"></a>

where a fragment anchor isn't attached to any content. Current browsers should have no trouble going to a location identified in this way. (Weren't we talking about this in another recent thread? It used to be a problem in Safari, but that was several versions ago.)

I cannot test it because right now I have no html5

? You may have misunderstood how browsers read HTML. They don't look at the DTD and then heed only those elements that are included within that specific HTML variant. Instead, a browser does everything it knows how to do, regardless of DTD. See caniuse.com for specifics. For example, I can put <wbr> in documents with an HTML4 DTD, or keep <tt> in documents whose DTD identifies them as HTML5 ("doctype html" and that's all).

:: detour to consult caniuse, which infuriatingly has started not playing nice with Camino ::

Jeepers. TencentTraveler is a browser? An actual browser used by actual humans with actual computers? I thought it was just some nasty Chinese robot.

[Fotiman]

the browser will correctly follow the link if the user succeeds in clicking on it-- which can never happen, since its screen space encompasses 0 pixels"

Actually, links don't NEED to be clicked on... there is such a thing as keyboard navigation that will still allow the user to follow that link even if they couldn't click on it. For example:

<p>Click in the input to set focus there, then press the Tab key to set focus on the hidden link, then press the Enter key to navigate to that link.</p>
<input><a href="http://www.example.com"></a>

[deeper]

Thanks to all.

I had to ask because:

-w3c defines explicitly what an "empty hyperlink" is, but they never mention it anywhere again. "Hyperlink" and "empty" elements ect., yes, but not "empty hyperlink".

-On several occasions webdesigner want to replace any text element (not only text anchor) with an image by CSS. More or less complicated methods (http://css-tricks.com/css-image-replacement/), with more or less disadvantages (browser; Google does not punish at once but they quickly frown about "hiding or doubling anything"; layout ect.). Often the issue could be solved easily by just leaving it empty, but it seems as if many prefer other ways. Why? I supposed failing validation could be one reason or a lack of browser support.

-After researching in the web many seem to be aware of being valid with links that have no href. Like lucy24 mentioned, there may be for example fragment anchors or any other things done intentionally and senseful this way. But links WITH href/URL without any anchor text or img as content? I couldn't find a source saying explicitly that it is valid and because of what practical usages.

-Links and their text anchor is one of the most important (single) ranking factors. I really read a lot about it in the past, but I don't remember any single word especially about completely empty links (no images too). Sure, "always use descriptive KWs...".

-Usually it's hard to imagine any application that does make sense. CSS, screenreader, keyboard navigation (like Fotiman hinted)... world is really big....

-It seems as if there are at least some screenreader, which target at the title attribute by default after detecting such an empty link. Therefore better completely empty than for example placeholder. A good solution for social buttons as sprite. No struggling with special CSS tricks. Being valid was the last possible obstacle.

[lucy24]

Usually it's hard to imagine any application that does make sense.

That's the essence of it. In general it's better to start by figuring out what you want to do-- including figuring out your intended human interaction-- and then design your site so it will do that thing.

In the case of images, it doesn't even have to be sprites. One straightforward application of image-as-link uses the image map, as defined in HTML4 and essentially the same in HTML5. In fact w3 says explicitly [w3.org]

Generally, image maps should be used instead of slicing an image for links.

Each map area can have its own alt text.

Oi! Fotiman! As long as you're here, why don't you stop by the javascript subforum and make sure I wasn't giving wildly bad advice.

[deeper]

Each map area can have its own alt text.

Do you know any other differences or advantages? In general obviously most webmaster prefer sprites, because they are more flexible.

Not sure why w3c could recommend them over sprites.

[lucy24]

Not sure why w3c could recommend them over sprites.

They're not. They're recommending maps over slicing (physically chopping into bits) a single image. The benefit of the image-map approach is that it's entirely done in HTML.

If the whole image is meant to be contiguous, like

+---+---+---+
|...|...|...|
|.A.|.B.|.C.|
|...|...|...|
+---+---+---+
|...|...|...|
|.D.|.E.|.F.|
|...|...|...|
+---+---+---+

you can use either sprites or a map. (An obvious case is a literal map with "click on your area" links.) If you've got a bunch of separate picture areas, it has to be sprites.

[deeper]

Thanks for your explanation.

The last days I read a lot about sprites, nobody mentioned image maps....

[mattur]

On a sidenote, use the new W3C HTML validator at:

[validator.w3.org...]

The old validator is DTD-based, out of date, incomplete and no longer maintained. The new checker has more features and provides better checking (by going beyond the limited constraint checking available by using the old DTD-based validation).

There's a good, funny article about markup checking by the W3C staff member who is co-developing the Nu Markup Checker here:

[html5doctor.com...]