- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sat, 19 Mar 2011 07:25:33 +0100
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
Daniel Glazman, Fri, 18 Mar 2011 16:47:09 +0100: > 5. in a wysiwyg environment [...] Even if > targeting elements with id has always been valid in fragment > identifiers, that's not what *all* editors deal with when they > offer to insert a named anchor. They *all* offer <a name>. There is *at least* one exception: Amaya. Amaya does use <a>, but instead of @name it uses @id. I believe that the crucial thing is to use the <a> element. Another example is Wikipedia. E.g. you find <a id="top"></a> here: http://en.wikipedia.org/wiki/Anchor#top. (When I and Boris discussed this subject in this group 2 years ago or so, then Wikipedia used <a id="top" name="top"></a>. > In html5, > since there is no <a name>, that's considerably harder: only a > handful of elements carrying an id attribute are meant by the web > author to be a URL fragment id's target. The others usually carry > an id attribute because of CSS rules applying to the element or as > a way to identify them in the tree for JavaScript code. I get this point. But when would <a id="fragment"></a> *not* solve the case? > Since it's impossible with the simple knowledge of the document to > detect elements carrying an id AND serving as named anchors, a Actually: all <a id="*"> could be taken to be equal to <a name="*">, no? Any common use of <a id="*"> which couldn't? Also, it sounds from your comment in the bug, as if all you are seeking is direct statement in the spec that it is accept to use <a id="*"> instead of <a name="*">: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12334#c2 I do support that HTML5 should explicitly give back that semantic to anchor elemetns *with the @id attribute*. (That would be like it is in XHTML1.) > wysiwyg environement has little choice: show all elements carrying > an id as named anchors or show none of them. Both choices are > just unacceptable from a user's perspective in an editing app. Still wonder why <a id="*"> wouldn't work, from everyone's perspective. > 6. I understand making <a name> valid in html5 will make many authors > use it instead of switching to an id carried for instance by a span. Nowhere does HTML5 recommends using <span id="*">. I'm glad it doesn't. > But the semantics of the element a have been changed here, and > filters reading html4 and outputing html5 will have extreme > difficulties dealing with <a name> because of style issues. Again, don't understand the disadvantage of <a id="*"> > Given all the above, and given the burden on editing tools, > it seems to me a bad change for html5 to remove support for <a name>. > I am then officially asking for the return of the original semantics > of a, source of hyperlink or named anchor, and the validity of > <a name> in html5. I strongly support you on the semantic side of the problem: give the meaning back! But I don't see why it isn't enough to use @id for this purpose. -- leif halvard silli
Received on Saturday, 19 March 2011 06:26:12 UTC