Why did they deprecate the 'name' attribute for HTML <a> elements?

Question

From what I understand, in HTML5 we're supposed to start using the id attribute to reference a elements, instead of the name attribute. The problem with this is that there is also a constraint that id should be unique per document.

Now, I see a lot of situations where you'd want to reference a set of related a elements (in JS, typically). By getting rid of the name attribute though, we're forced to either reuse the same id, or use a class name. Classes should supposedly be about presentation, so this is also an imperfect solution if you're referencing your a's for non-presentation related reasons.

I suppose another HTML5 alternative would be to use something like data-name, but this also seems hackish. Is there something I'm missing? Is there a secret W3 conspiracy to phase out name altogether?

Answer 1

Ah, HTML. How inconsistent you are.

The issue, it seems, is the confusion with name attribute for anchors and the name attribute for inputs. Back in the pre-HTML5 days, you needed a way to distinguish an outgoing link (one via href) with an internal document link (a # bookmark).

So, how would they accomplish this? It's specified here: http://www.w3.org/TR/html401/struct/links.html

By activating these links (by clicking with the mouse, through keyboard input, voice commands, etc.), users may visit these resources. Note that the href attribute in each source anchor specifies the address of the destination anchor with a URI.

The destination anchor of a link may be an element within an HTML document. The destination anchor must be given an anchor name and any URI addressing this anchor must include the name as its fragment identifier.

Destination anchors in HTML documents may be specified either by the A element (naming it with the name attribute), or by any other element (naming with the id attribute).

Yes, give an anchor a name attribute (which acts as a fragment identifier) which another anchor could link to.

Only, with HTML5, they decided any element (other than a) could act as fragment identifier (which makes sense - there should only be one fragment that you can link to...) - Which is why they deprecated the name attribute.

As for how to select them? The class attribute is perfectly fine (sure, it's used for styling, but does it make it purely presentational?)

Another quote (from w3c: http://www.w3.org/TR/html401/struct/global.html#adef-class)

The class attribute, on the other hand, assigns one or more class names to an element; the element may be said to belong to these classes. A class name may be shared by several element instances. The class attribute has several roles in HTML:

*As a style sheet selector (when an author wishes to assign style information to a set of elements).

*For general purpose processing by user agents.

Answer 2

I see no reason not to use classes or data-attributes.

To your points about the name attribute - those should have been unique anyway! Multiple a elements with the same name is not terribly useful, as linking to them in the URL will become ambiguous: www.example.com#my-named-element.

At our company, we've explored using a data-behaviors attribute like so:

<a href='#' data-behaviors='something-cool something-else'>Click Me</a>

And in the JS we bind events to it using:

$(".container").on("click", "data-behaviors=~'something-cool'", function(e){
  e.preventDefault();
})

We've also explored using classes with the naming convention .js-something-cool so that we don't get confused by which classes are for CSS and which are specific to javascript functionality.

In the end, we've ended up preferring the js- class name scheme because it's less clunky to use than a data-behavior version. But at times we'll mix and match depending on our needs.

For instance, you might make toggle functionality like this:

<a href='#' data-toggle='#opened-div'>Click Me</a>

<div id='opened-div'>Some stuff</div>

And that way your data attribute can both be used to bind the event, and decide what elements are being toggled.

Answer 3

in HTML5 we're supposed to start using the id attribute to reference a elements, instead of the name attribute.

The use of ids to link to was introduced in HTML 4. XHTML 1 deprecated the name attribute. This was maintained in HTML 5.

The problem with this is that there is also a constraint that id should be unique per document.

Ambiguous link targets are not useful!

Look at the definition of the name attribute for the a element in HTML 3.2:

This should be a string defining unique name for the scope of the current HTML document

Deprecating it in favour of id does not add any new uniqueness constraint.

Now, I see a lot of situations where you'd want to reference a set of related a elements (in JS, typically).

There are lots of situations where you'd want to reference all sorts of different types of related element. HTML provides classes for that. You can even have an element be a member of more than one of them.

Classes should supposedly be about presentation

No they aren't. Classes are the generic way to identify a set of elements as belonging to a group.

Look at the definition of a class in a dictionary:

A set or category of things having some property or attribute in common and differentiated from others by kind, type, or quality

See also the HTML 5 definition of the class attribute which makes no mention of being strictly for presentation and one of the examples of use is with JavaScript.

That they are primarily used with CSS is just because people frequently want to apply styles to groups of elements.