105693 - W3C HTML 4.01 spec recommends we ignore non-alpha target

Status: RESOLVED INVALID

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Braden]

Per the HTML spec, browsers should ignore target names that don't start with an
alphabetic character and aren't one of the reserved identifiers.

  <http://www.w3.org/TR/html4/types.html#type-frame-target>

Mozilla isn't doing this.

Comment 1

[Kevin McCluskey (gone)]

Bulk reassigning Eric Pollmann's remaining form submission bugs to Alex.

Comment 2

[Christopher Hoess (gone)]

->Frames

Comment 3

[John Keiser (jkeiser)]

I suspect that this is here for a reason.  Is there any compelling
<B>technical</B> reason to deny these anchors from working?

Comment 4

[Braden]

As I understand it, Mozilla aspires to HTML 4 conformance. If there is a reason
that non-reserved target names starting with "_" *should* be allowed, that
behavior should be reserved for quirks mode.

Comment 5

[John Keiser (jkeiser)]

OK, I'll give you that.  But so far I think the spec sounds pretty arbitrary in
this regard.  I'm very curious whether there is any user- or developer-level
justification for this restriction.

Comment 6

[Braden]

The "developer-level" justification is future-proofing: effectively reserving
all identifiers that start with "_" means that identifiers in this namespace can
be given special meaning without impacting existing pages.

However, I'll grant that the obsolescence of frames and resulting improbability
that they will be extended make this argument pretty theoretical.

Comment 7

[Alfonso Martinez]

*** Bug 202167 has been marked as a duplicate of this bug. ***

Comment 8

[Gérard Talbot]

>Is there any compelling <B>technical</B> reason to deny these anchors from working?

_new might be one for backward compatibility... although even here I'm all for
removing support for _new. You can expect that some people will complain if
support for _new is suddenly removed. It was first introduced in NS 4 because
_new was more intuitive, self-explanatory than _blank. Mozilla still supports
_new; see line 1406 at this url (url broken to avoid horizontal scrolling):

http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/﷒0﷓

Note that Composer only offers _blank and does not offer _new in its drop down
list of choices for target.

_content is one for sure. Internally, Mozilla supports _content so that scripts
can access the sidebar content.
http://www.mozilla.org/docs/dom/domref/dom_window_ref3.html#1016797

Comment 9

[Gérard Talbot]

The current [admittedly DRAFT] HTML 4 test suite at the W3C

http://www.w3.org/MarkUp/Test/HTML401/current/tests/6_16-BF-01.html
(that page is loaded into
http://www.w3.org/MarkUp/Test/HTML401/current/tests/sec6_16-BF-01.html
)
clearly indicates that Mozilla also fails at ignoring target name starting with
a digit. E.g.: Load the W3C HTML 4 test suite, then click on the link 
<a href="6_16-BF-01f.html" target="4four">this link</a>
in the bottom-left-lime-colored frame (...c.html). 
Despite the fact that a frame was named "4four", the link should load into the
same frame, not into the bottom-right-pink-colored frame (...d.html)

Comment 10

[Dan M]

I completely agree with the W3C's recommendation but it was five years tardy.
Names beginning with underscores other than the reserved ones are in use in the
wild. Implementing this recommendation would "break" those sites. ("Break" in
quotes because the consequences of ignoring a frame name generally don't lead to
a serious malfunction.)

I've happened to have noticed a few examples. One is www.scriptsearch.html,
which uses the not uncommon "_new" target. I believe the malfunction at this
site caused by implementing the W3C's recommendation would be limited to opening
advertising in the same window rather than a new one, which seems quite benign.

A second example I've run across is HSBC's, a bank in the UK. Its login process
(at
http://www.ukpersonal.hsbc.co.uk/public/ukpersonal/internet_banking/en/logon.jhtml)
involves submitting a form targeted to a window named "_pib", for whatever
reason. When you log in to this bank the main window is supposed to remain at
the login screen, which contains other useful links as well. A secondary window
should open to handle the details of your account. If we were to implement the
W3C recommendation, Mozilla would handle this bank's login quite incorrectly.

We've considered disallowing non-reserved names beginning with an underscore
more than once, and always decided not to. It would have been nice had that
namespace been reserved. Following the W3C spec now will cause problems
perceived to be a bug in Mozilla, and it's not to be done lightly.

I'm changing this bug's summary to reflect its questionable status.

Comment 11

[Dan M]

*** Bug 248396 has been marked as a duplicate of this bug. ***

Comment 12

[Justin Wood (:Callek)]

Whiteboard [WONTFIX?]

Comment 13

[d]

A WONTFIX seems good to me... 5 years later...

Comment 14

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

HTML5 requires supporting all target values, even ones that don't start with a-zA-Z. Marking invalid.