Re: validity of <a name>

On Fri, 2011-03-18 at 16:47 +0100, Daniel Glazman wrote:
> 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

If I'm reading Opera MAMA right, <font> was more popular than <a name>
in 2008.
http://dev.opera.com/articles/view/mama-markup-report-part-3-basic-body/

Do you have more recent data?

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

The same goes for pretty much every feature that has been valid but is
no longer except longdesc, axis and summary.

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

What do you do when <font> is copied from HTML 4 into HTML5 in
BlueGriffon?

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

Shouldn't it be considered an awesome feature that there are more
granular places to target links to as a side effect of CSS?

>  and
>     filters reading html4 and outputing html5 will have extreme
>     difficulties dealing with <a name> because of style issues.

<a name> is so bad for styling that CSS needs :link to avoid
accidentally styling <a name> even though selecting on the a element
would be easier in the absence of <a name>.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 18 March 2011 16:53:16 UTC