Problem with <a name.

[joecool]

Hi all,

I was involved in a discussion on a different forum with regards to whether it is okay to now have any text between the <a name="anchor-name"> and the </a> or whether it is more technically right to have text there such as: <a name="anchor-name">This Is The Text I Mean</a>.

All the tutorials I see on places like w3schools have text there but then that means I need to get right of any link styles or decoration in css because I typically don't want these to be a link or look like a link.

Most people say that it is okay to write:

<a name="anchor-name"></a> and just put it where ever you want it to be.

Is this okay? Will it work in all browsers? What do you do?

[SuzyUK]

Welcome to WebmasterWorld joecool!

I don't use a name attribute ;) I use an ID attribute, the name attribute is deprecated *I think* - someone will CMIIW. To create bookmarks, you use a Fragment Identifier in the link, which looks like an ID mark in CSS..

<a href="#somebookmark>Jump to your bookmark</a>

is a normal link because that's going somewhere

Which can jump to a heading or paragraph which has the ID "somebookmark"

<h2 id="somebookmark">This is the bit of the page it'll jump to</h2>

It kind of makes sense really the CSS ID is IDentifying the section of text, and the fragment IDentifier ID's it ;)

I think it's also suggested that in forms you use both the name and ID attibutes, and they should be the same, as some languages (javascript?) had a crossover period before becoming aligned in their compatibility - that info could be outdated now, my apologies but in all the suggestions per XHTML was to use ID and I think most browsers and languages are now aligned on this.


However if you want to use name you don't need rid of the CSS you just need to make it specific

a:link will only target links.. a:link:hover, a:link:active etc..

a, a:hover, a:active etc.. will target all <a> elements

personally I stick with the ID as it's useful in other ways too

[joecool]

Hi SuzyUK,

Thanks for the welcome. I have read somewhere else about using and ID for this. I might well start doing things in this way.

[jalarie]

Older browsers need "name=?" and newer ones need the "id=?" version. Use both and make sure they match.

Properly, you need something for the content. I put "&nbsp;" (no quotes) in there; it's proper and only a blank displays.

[joecool]

Thanks Jalarie

I have been trying to find a reference on authoritative sites such as w3schools about using the "ID" instead of "name" but they the tutorials still seem to be just teaching the "name" way of doing it.

Can anyone point me in the direction of an authoritative source where it says that "name" is being depreciating and to use the "ID"?

Thanks, I just want to make sure that I am doing things 100% right before I go about changing things.

[tangor]

If ID is working now, and NAME is now depreciated (but is still backwards compatible in most browsers) I'd go with ID, or as jalarie suggested, do the belt and suspenders approach and use both. It is a marginal increase in characters per page.

That said, coding for anything less than IE8, FF3 or the Opera/Safari equivalents at this day and time is problematic. Only Governments and Really Big Corporations (most of which have filters on their systems) are still using IE6 or Netscape 4 and below...

[Fotiman]

With XHTML, the name attribute was targeted to be deprecated in favor of the id attribute.

The XHTML 1.0 spec [w3.org] says:

4.10. The elements with 'id' and 'name' attributes

HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and map. HTML 4 also introduced the id attribute. Both of these attributes are designed to be used as fragment identifiers.

In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers on the elements listed above. See the HTML Compatibility Guidelines for information on ensuring such anchors are backward compatible when serving XHTML documents as media type text/html.

Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.

With HTML5, the
changed attributes [w3.org] section of the "HTML5 differences from HTML4" document says:

The type attribute on script and style is no longer required if the scripting language is ECMAScript and the styling language is CSS respectively.

The following attributes are allowed but authors are discouraged from using them and instead strongly encouraged to use an alternative solution:

The border attribute on img. It is required to have the value "0" when present. Authors can use CSS instead.

The language attribute on script. It is required to have the value "JavaScript" (case-insensitive) when present and cannot conflict with the type attribute. Authors can simply omit it as it has no useful function.

The name attribute on a. Authors can use the id attribute instead.

The summary attribute on table. The HTML5 draft defines several alternative solutions.

And the name attribute does not appear in the "Content attributes" section for the a element [w3.org] in the HTML5 current working draft.

The name attribute was not deprecated in HTML4.

So I guess to summarize:
* HTML4 - Not deprecated
* XHTML 1.0 - Deprecated
* HTML5 - Discouraged? (don't know if that means deprecated)

[rocknbil]

Another note to throw in the mix - you don't need to add an <a> just to have an anchor. You can anchor to any id'ed element.

<p><a href="#dissertation">Jump to Dissertation</a></p>

[Ghastly volume of text]

<h3 id="dissertation">Dissertation</h3>

This approach is a bit more economic (i.e., less HTML) and semantic (I.E., an empty <a> for no other purpose than mechanics.) Pageoneresults opened a good discussion on Fragment Identifiers here [webmasterworld.com] that discusses the usage of these beyond simple anchors.

[SuzyUK]

rocknbil.. you said it shorter than me ;)

* XHTML 1.0 - Deprecated
* HTML5 - Discouraged? (don't know if that means deprecated)

That's what I was finding, to me "discouraged" in HTML5 is the same as deprecated in XHTML, deprecated always did mean things would be supported "back" the way (i.e. to HTML) - and as XHTML was all about encouraging good practice so XHTML "practices" will have to continue through HTML5 due to some dropping XHTML in favour of HTML-4, and XHTML itself always needing support - so in all it's still best to use both if in doubt, though I reckon ID will always have the support and is the more logical way, I presume support for "name" won't be dropped anytime soon!

Fotiman can you confirm whether JS (forms) should still have both with the same value too? are we still in a kind of limbo land while this permeates or will ID work if that's all that's used.

[Fotiman]

Well, for form elements, the name really means something different. For example, you can have multiple controls (radio buttons, checkboxes) with the same name value, though if they have an ID it must be unique. Whereas the name attribute on <a> elements was used as an anchor in the document.

I think in most cases, the ID value on form elements is a convenience for accessing that element. But name is still the attribute that should be used for submitting the form.

[w3.org...]

[joecool]

Thanks for the help everyone and there was some excellent references in there. That is exactly what I was looking for.

A stupid question from a novice coming up though - so get prepared.

I am only used to reading about ID's when they related to the style sheet and where they have to be in the CSS. Is everyone saying that I would not need to make an entry for each bookmark in the css?

Instead I just name the ID whatever I have called the anchor text?

[tedster]

You are correct. If you don't want a unique style for that particular ID, then it doesn't need any CSS rules.

[joecool]

You are correct. If you don't want a unique style for that particular ID, then it doesn't need any CSS rules.

Thanks