Should I make HTML Anchors with 'name' or 'id'?

前端 未结 14 1215
旧巷少年郎
旧巷少年郎 2020-11-22 00:49

When one wants to refer to some part of a webpage with the \"http://example.com/#foo\" method, should one use

F

相关标签:
14条回答
  • 2020-11-22 01:24

    The whole "named anchor" concept uses the name attribute, by definition. You should just stick to using the name, but the ID attribute might be handy for some javascript situations.

    As in the comments, you could always use both to hedge your bets.

    0 讨论(0)
  • 2020-11-22 01:25

    Wikipedia makes heavy use of this feature like this:

    <a href="#History">[...]</a>
    <span class="mw-headline" id="History">History</span>
    

    And Wikipedia is working for everybody, so I would feel safe sticking with this form.

    Also don't forget, you can use this not only with spans but with divs or even table cells, and then you have access to the :target pseudo-class on the element. Just watch out not to change the width, like with bold text, cause that moves content around, which is disturbing.

    Named anchors - my vote is to avoid:

    • "Names and ids are in the same namespace..." - Two attributes with the same namespace is just crazy. Let's just say deprecated already.
    • "Anchors elements without href atribute" - Yet again, the nature of an element (hyperlink or not) is defined by having an atribute?! Double crazy. Common sense says to avoid it altogether.
    • If you ever style an anchor without a pseudo-class, the styling applies to each. In CSS3 you can get around this with attribute selectors (or same styling for each pseudoclass), but still it's a workaround. This usually doesn't come up because you choose colors per pseudo-class, and the underline being present by default it only makes sense to remove, which makes it the same as other text. But you ever decide to make your links bold, it'll cause trouble.
    • Netscape 4 might not support the id feature, but still an unknown attribute won't cause any trouble. That's what called compatibility for me.
    0 讨论(0)
  • 2020-11-22 01:29

    ID method will not work on older browsers, anchor name method will be deprecated in newer HTML versions... I'd go with id.

    0 讨论(0)
  • 2020-11-22 01:30

    There's no semantic difference; the trend in the standards is toward the use of id rather than name. However, there are differences that may lead one to prefer name in some cases. The HTML 4.01 specification offers the following hints:

    Use id or name? Authors should consider the following issues when deciding whether to use id or name for an anchor name:

    • The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
    • Some older user agents don't support anchors created with the id attribute.
    • The name attribute allows richer anchor names (with entities).
    0 讨论(0)
  • 2020-11-22 01:33

    The second sample assigns a unique ID to the element in question. This element can then be manipulated or accessed using DHTML.

    The first one, on the other hand, sets a named location within the document, akin to a bookmark. Attached to an "anchor", it makes perfect sense.

    0 讨论(0)
  • 2020-11-22 01:33

    In html 5, the id="" attribute defines a unique identifier for an element, which is also an anchor for a fragment link. In previous html standards, the name="" attribute of the <a> element defines an anchor for a fragment link. I recommend something like:
    <a name="foo" id="foo"></a><h1>Foo Title</h1>
    Because support for the id="" attribute is a bit spotty(even though the latest releases of all major browsers support it, the releases that don't aren't more than a few years old[And it's best not to break something if there isn't a good reason to]). It's compatible, & it doesn't style whatever's in the link'd element, for the closing </a> is still outside the element, but it's still valid in all current standards.

    Be sure that the name="" and id="" attributes of the <a> element are the same.

    0 讨论(0)
提交回复
热议问题