Re: validity of <a name>

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