12334 2011-03-18 15:57:03 +0000 make <a name> valid again in HTML5 2011-12-02 17:54:00 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED WONTFIX P2 normal --- 1 daniel.glazman contributor ayg ian julian.reschke kennyluck mike m_a_s_7 public-html-admin public-html-wg-issue-tracking shelleyp xn--mlform-iua public-html-bugzilla oldest_to_newest 46810 0 daniel.glazman 2011-03-18 15:57:03 +0000 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 46819 1 xn--mlform-iua 2011-03-18 17:58:24 +0000 (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="*"> ? 46820 2 daniel.glazman 2011-03-18 18:47:13 +0000 (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. 46834 3 xn--mlform-iua 2011-03-19 06:42:09 +0000 (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. 48261 4 ian 2011-05-06 22:04:56 +0000 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="". 48266 5 shelleyp 2011-05-06 22:36:56 +0000 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. 48346 6 daniel.glazman 2011-05-09 06:01:59 +0000 (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>. 48350 7 xn--mlform-iua 2011-05-09 09:10:42 +0000 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.) 53966 8 mike 2011-08-04 05:34:55 +0000 mass-move component to LC1 60799 9 ian 2011-12-02 17:54:00 +0000 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.