This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I have detailed in [1] why I think <a name> should be valid again in html5. I am then suggesting (a) to revert the semantics of <a> to the html4 semantics: it's the source of an hyperlink and/or a named anchor (b) to make <a name> valid again in html5. I would not mind if a note is added asking web authors to prefer the id attribute on an another element. [1] http://lists.w3.org/Archives/Public/public-html/2011Mar/0367.html
(In reply to comment #0) > I am then suggesting (a) to revert the semantics of <a> to the > html4 semantics: it's the source of an hyperlink and/or a named > anchor (b) to make <a name> valid again in html5. > I would not mind if a note is added asking web authors to prefer the > id attribute on an another element. ONE: I support the view that the definition of <a> is not optimal. If I remember correctly, it says that an <a> without @href, is "a place were there could have been a link if it had been relevant". TWO: But regardless of the definition: inside BlueGriffon, why don't you just convert <a name="*"> into <a id="*"> ?
(In reply to comment #1) > ONE: I support the view that the definition of <a> is not optimal. If I > remember correctly, it says that an <a> without @href, is "a place were there > could have been a link if it had been relevant". Yes. > TWO: But regardless of the definition: inside BlueGriffon, why don't you just > convert <a name="*"> into <a id="*"> ? Because the spec says that <a> is semantically an hyperlink. Turning an html4 <a name> into a <a id> would make it a named anchor, violating the semantics defined in the spec.
(In reply to comment #2) > Because the spec says that <a> is semantically an hyperlink. It is only "semantically a hyperlink" - "REPRESENTS a hyperlink" - when it contains @href: "If the a element has an href attribute, **then** it represents a hyperlink (a hypertext anchor)." There is another thing which <a> always is, however: It is always 'interactive content', even without the @href, see: http://dev.w3.org/html5/spec/content-models.html#interactive-content But I suppose that you are not after changing *that* detail. > Turning an html4 <a name> into a <a id> would make it a > named anchor, violating the semantics defined in the spec. QUESTION: Would that solve you concern if the spec stated that an <a id="">*</a>(anchor with the @id attribute) "REPRESENTS a named anchor"? (I *do* support such a change.) NOTES to convince the editor (Ian) to make such a specification: FIRSTLY: Spec forbids 'target, rel, media, hreflang, and type' unless @href is present. But @id is not forbidden. SECONDLY: Spec contains one example where it shows how one can use an <a> element WITHOUT any @href. PROPOSAL: add @id to that example. THIRDLY: @name is actually "obsolete but conforming" http://dev.w3.org/html5/spec/obsolete.html#obsolete-but-conforming-features Hence the "old" semantics are actually not clearly unpresent in HTML5.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: no spec change Rationale: This seems to have been done already. <a name="..."> raises a warning in conformance checkers, but does not raise an error. This is intended to allow migration from legacy documents to the more consistent usage of id="".
The name attribute is still listed in the HTML5 specification as an obsolete feature. Your resolution is in error. Please correct the status of the bug to WONTFIX if you're not going to make <a name> valid.
(In reply to comment #5) > The name attribute is still listed in the HTML5 specification as an obsolete > feature. Your resolution is in error. > > Please correct the status of the bug to WONTFIX if you're not going to make <a > name> valid. I tend to agree with Shelley here. The presence of that sentence in the prose induces a confusion about the real status of the name attribute on <a>.
Wanted to correct something I said about Amaya not using a@name. (See message on public-html: http://lists.w3.org/Archives/Public/public-html/2011Mar/0395.html ) It turns out that, for XHTML 1.0 and HTML4, then Amya does use <a name="foo" id="foo">foo</a> whenever the author manually selects a piece of *text* and makes it a target. (In contrast, whenever the author selects an entire, pre-existing *element*, then Amaya inserts an @id in that element rather than using a@name.)
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Marking "Rejected" as requested, although the spec basically already says what was requested.