40078 - <a name>'s being treated as <a href>'s

Status: VERIFIED DUPLICATE of bug 40197

(Core :: Layout, defect, P3)

Description

[Jeremy M. Dolan]

right clicking on text contained in a <a name> block brings up the link menu
(ie, you can select 'open link in new window', etc...).

also, it can be DnD'd, which ends up doing a history->back.

Comment 1

[Jeremy M. Dolan]

Attachment: test case

Comment 2

[Jeremy M. Dolan]

also, triple click to select line doesn't work on <a name> text.

Comment 3

[Jesse Ruderman]

see bug 31594 for a few reltated bugs

drag&drop actually treats it as href="", which goes to the directory listing if 
you're viewing a file inside a directory.

Comment 4

[Charles Manske]

Note that this is technically "bad HTML" since you are never supposed to have
content between start and end tags for a named anchor. Nonetheless, we should
handle this case correctly. The early W3C people who approved using <a> for both
link "source" and link "target" should be tarred and feathered, IMHO.

Comment 5

[Jeremy M. Dolan]

a thought occurs (oh so few and far between...)

we can't force <a name> termination in cases where there is also an href in the 
anchor. i certainly could see code out there setting a 'name' for a link, and 
trying to optimize but squishing them into the same <a>.

Comment 6

[Charles Manske]

There is one very simple solution, in my opinion: The parser should immediately 
terminated the <a> node (effective "inserting </a> " when content is written 
out) after encountering <a name="foo"> if there is no "href" attribute (a dual 
anchor/link which is a silly thing to do, but I suppose is legal.) 

Comment 7

[Sean Richardson]

This is reminiscent of bug 37201, "a without href is draggable, acts like 
href="./" when dragged", which was for <A> elements with *no* attributes.
It appears that <A> elements without href attributes are acting too much like 
those that do have an href. 

Also, as it *is* legal to have <A>foo</A> elements with no initial attributes,
to be set later by DOM manipulation, there is no way to to predict what 
attributes might be set, so handling of all <A> needs to be robust.

What was that about tar and feathers again?

Comment 8

[Sean Richardson]

Um, it appears that content in <A> elements with only a NAME attribute
*is* allowed, see under http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2

> Suppose we define an anchor named "anchor-one" in the file "one.html".
>
>            ...text before the anchor...
>            <A name="anchor-one">This is the location of anchor one.</A>
>           ...text after the anchor...
>
>         This creates an anchor around the text "This is the location of anchor 
>         one.". Usually, the contents of A are not rendered in any special way 
>         when A defines an anchor only.

Comment 9

[Charles Manske]

Thanks for the pointer to legal content within a named anchor.
My "tar and feathers" comment reflects our having to special-case a lot of code 
in Composer (and this bug reflects the requirement in browser) because of the 
duality of <a> used for both the "trigger" (name=) and "target" (href=) of a 
link relationship. This is annoying and would be easier to implement if there 
were separate tags for these purposes!

Comment 10

[Charles Manske]

Yes, this is related to 40197 alright -- it is really a dup!


*** This bug has been marked as a duplicate of 40197 ***

Comment 11

[Matt Perry]

Verified duplicate.

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.