Clicking on an HREF reference to a named anchor with spaces should scroll the
page to bring the table element into view.
This is broken in M16, which I downloaded on July 22, 2000 for Windows NT.
This works in Netscape Communicator 4.61
<a href="#multi part name with spaces">Click Here!</a>
. . .
<td><a name="multi part name with spaces"></a>
Created attachment 11768 [details]
Test case with targets inside and outside table
I see this with Linux 2000072113 so I'm confirming. However, I don't know if
this is a real bug or not. Section 6.2 of the HTML 4.01 spec does include a
space in the list of valid characters for the "NAME" attribute. Section 2.4.3
of rfc2396 specifically disallows spaces in URIs.
For your reference:
Bad typo sorry, that should say section 6.2 does not include a space in the list
Duplicate of bug 11453 ?
This bug may be related to the map bug referenced.
The discussion of CDATA at http://www.w3.org/TR/html4/types.html#type-cdata is
ambiguous. It is implied that <space> is valid character since it is "part of
the document character set" and "user agents may leading and trailing
whitespace" and "replace each carriage return and linefeed with a single space".
However <space> is specifically left out of the NAME definition and is
specifically left out from the URI and # fragment discussion.
BUT <space> may be encoded as %20 and based on the discussion in 6.2,
"replace character entities with characters" (i.e. %20 with <space>).
To be pedantic, no, there should be no unescaped spaces. HOWEVER, legacy
improper use, place the fact that every other browser on the planet does
the right thing, plus the fact that it is relatively simple to have the
user agent automagically escape spaces to %20 when referencing external
documents and internal document fragments, the best thing would be to
support spaces in this instance because of the number of websites that
will break, otherwise. I know it ain't "right" especially in the context
of URI definitions and XML-HTML 1.0 but well, so what.
Triaging Clayton's bug list:
Looks very much like 11453. Leaving the decision to Vidur. ;)
Taking this off Vidurs list, I have a fix for this in my tree, will attach
patch. (I think this is a dup but I can't find the other bug!)
Accepting bug and nominating for beta3, I've seen other sites break because of
this too. Nominating for beta3 based on correctness and backwards compatibility
with 4.x, the fix is really low risk, here's the patch:
RCS file: /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v
retrieving revision 1.173
diff -u -r1.173 nsDocShell.cpp
--- nsDocShell.cpp 2000/07/21 23:44:38 1.173
+++ nsDocShell.cpp 2000/07/26 02:04:24
@@ -3103,6 +3103,12 @@
+ char *tmp = sNewRef.ToNewCString();
nsCOMPtr<nsIPresShell> shell = nsnull;
rv = GetPresShell(getter_AddRefs(shell));
if (NS_SUCCEEDED(rv) && shell)
Fix checked in, marking FIXED.
Verified fixed in the Aug 24th build.
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.