W3C home > Mailing lists > Public > public-html@w3.org > March 2011

validity of <a name>

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Fri, 18 Mar 2011 16:47:09 +0100
Message-ID: <4D837E7D.2090102@disruptive-innovations.com>
To: "public-html@w3.org" <public-html@w3.org>
Implementing a wysiwyg editor for html4, xhtml1 and html5, the
removal of <a name> from html5 is a big problem ; let me explain:

1. first, the web is full of <a name>... It's really not like
    <font face> that's disappearing at fast pace, at least from the
    corporate or institutional web sites

2. <a name> has been successfully working for so long I can't even
    remember when it was introduced in html...

3. most web authors without a deep technical knowledge still use
    <a name> for targets of a URL fragment id ; many authors with
    deep technical knowledge still use it too...

4. <a name> is now invalid in html5, making it impossible to copy
    the trivial <p>foo<a name="a"></a>bar</p> from html4 to html5
    without raising a validity issue ; turning that <a name> into
    a <span id> is not doable without prompting the user, something
    that should not happen on a copy/paste action ; furthermore, that
    could break stylesheets.

5. in a wysiwyg environment, the user wants to see visible named
    anchors ; in html4, that's simple to show <a name>... 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>. 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.
    Since it's impossible with the simple knowledge of the document to
    detect elements carrying an id AND serving as named anchors, a
    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.

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.
    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.

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 would not mind if the spec recommends to use an
id on another element instead of using <a name>. But we really need
<a name> to become valid again in html5.

</D.Glazman>
--
Disruptive Innovations
Received on Friday, 18 March 2011 15:47:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC