- From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Date: Fri, 18 Mar 2011 16:47:09 +0100
- 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