468,765 Members | 916 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,765 developers. It's quick & easy.

FF: anchor links not working..


<a href="#1">

<a name="#1">

this link is not working in FF (works fine in IE..)
would appreciate thoughts/suggestions.. thank you..

Frances
Feb 8 '06 #1
16 14211
Frances wrote:
<a href="#1">

<a name="#1">

this link is not working in FF (works fine in IE..)
would appreciate thoughts/suggestions.. thank you..


IE is fixing your error for you. Firefox is not.

It should be <a name="1">.

Or use an id on any element instead and get rid of the targetted <a>
element altogether. But be aware that id values must start with a
letter not a digit.

Steve

Feb 8 '06 #2
On Wed, 8 Feb 2006, Frances wrote:

<a href="#1">

<a name="#1">

this link is not working in FF
No, its name isn't "#1". There's two things wrong with that, so
Mozilla/FF are working correctly in refusing to use it.
(works fine in IE..)
No it doesn't. It might do what you wanted it to do, but (as so often
with IE) that only demonstrates that it's broken.
would appreciate thoughts/suggestions..


http://www.w3.org/TR/REC-html40/types.html#type-name

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").

Use something like <a href="#n1">

Then use id="n1" on a suitable element for current browsers.

Your <a name="n1"> is for ancient browsers; but if you do that, and if
you use a style for a:hover , you're due for some surprises in a
conforming browser. (IE, <=6, as usual gets this wrong. I don't
know about 7 yet, and I'm not sure I can really be bothered, having
seen how many bugs are still being reported with it).

Feb 8 '06 #3
Alan J. Flavell wrote:
http://www.w3.org/TR/REC-html40/types.html#type-name

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").


Strange as it may seem, the name attribute of the <a> element is not a
NAME token as far as I can tell.

Steve

Feb 8 '06 #4
On Wed, 8 Feb 2006, Steve Pugh wrote:
Alan J. Flavell wrote:
http://www.w3.org/TR/REC-html40/types.html#type-name

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
followed by any number of letters, digits ([0-9]), hyphens ("-"),
underscores ("_"), colons (":"), and periods (".").


Strange as it may seem, the name attribute of the <a> element is not a
NAME token as far as I can tell.


That's rather a mess, isn't it? The "a name=" attribute takes a value
of type CDATA, which suggests it could be pretty much anything. But
it links to a piece of text which says

Name = cdata [...]
Note that this attribute shares the same name space as the id
attribute.

Which can weasily[1] be interpreted as "same syntax rules apply for
both", although you might want to argue that it doesn't say that in so
many words.

The id attribute takes a value of type "id", which indeed is
constrained as described.

If the name= attribute had been defined to take a value of "id", then
it would not have been possible to use the same value in an id= (for
current browsers) and <a name="..."> (for old browsers). Obviously
they needed to avoid that clash somehow, if they were to keep this
compatibility feature.

Or you could just argue that they kept CDATA here because that was
what was in HMTL/3.2(spit!). Ho hum.

So, using name="1" would not raise a validation error, but id="1"
surely would (and indeed it does). In fact, even name="#1" (which was
wrong for a different reason) would not raise a validation error - but
it's surely wrong, nevertheless.

--
[1]
Q: Can you tell the difference between a polecat and a ferret?
A: Oh yes, weasily.
SCNR.
Feb 8 '06 #5
8 Feb 2006 16:52:24 +0100 from Frances <fd***@yahoo.com>:

<a href="#1">

<a name="#1">

this link is not working in FF (works fine in IE..)


Suggestion 1: When something "works" in IE but not in a real browser,
it's probably bat HTML and an IE bug. So don't take IE as the
standard of what's right.

Suggestion 2: href="#1" means to find the name "1" on the current
page. It's a type of relative URL, and the leading "#" means to find
that anchor on the current page. So you need to change name="#1" to
name="1".

Suggestion 3: You really want to be using ID rather than NAME,
because (a)any element can have an ID attached with no need for extra
<a>...</a> tags and (b) IDs can be addressed in CSS but NAMEs can't.
However, IDs can't start with a digit.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you
Feb 8 '06 #6
Frances wrote:

<a href="#1">

<a name="#1">

this link is not working in FF (works fine in IE..)


Which means IE has a bug. You should understand that "#" is not part of
a name, it's a delimiter. In a URL, it separates the name of a resource
from a reference to some named part of that resource. If there isn't
anything to the left of the #, then what's on its right is a reference
to some named part of the *current* resource (IOW, the page that you're
already looking at). So

href="#abc"

is a reference to a section of the current resource (page) named "abc".

If IE overlooks this flaw in your code, then it's a good thing you're
testing in Firefox too.
Feb 8 '06 #7
Frances wrote:

<a href="#1">

<a name="#1">

this link is not working in FF (works fine in IE..)
would appreciate thoughts/suggestions.. thank you..

Frances


Everyone answered you correctly. All I'm going to add is that you should
first validate markup code of this sort before even investigating
differential page rendering in browsers.

Invalid markup code can even crash browsers. Period. Specially browsers
like MSIE 6 who are laxist, tolerant with many complex internal markup
correction/compensating mechanisms.

First example:
Not too long ago, it was established that <input type> was crashing MSIE
6 SP1:
"Slashdot: HTML Rendering crashing IE. Here’s a test page that crashes
my Internet Explorer 6.0 SP2 with all patches."
http://diveintomark.org/archives/200...eadable_markup
May 2003

Second example (still unfixed in MSIE 6):
Load the following code in MSIE 6 SP2 with all the patches, even the
latest January 2006 and you'll crash:

<div style="vertical-align: top;">
<p>First <font size="4">Paragraph</p>
<p>Second </font> Paragraph</p>
</div>

Everything was nicely reported and clearly explained in october 2003 and
the bug is still reproducible, 100% of the time.

Page where this bug is explained at
http://jehiah.com/archive/ie-vertica...-vulnerability

Proof of concept at http://www.jehiah.com/sandbox/vertical-align-top.htm

Gérard
--
remove blah to email me
Feb 8 '06 #8
Alan J. Flavell wrote:
The "a name=" attribute takes a value
of type CDATA, which suggests it could be pretty much anything. But
it links to a piece of text which says

Name = cdata [...]
Note that this attribute shares the same name space as the id
attribute.
That's odd indeed, but I'd read it as a geekish way of saying "you can't
use the same stuff both here and in an id='...'". When formulating it in
space terms (which really required rocket science, I'm sure) they
managed to say something they didn't mean.
Which can weasily[1] be interpreted as "same syntax rules apply for
both", although you might want to argue that it doesn't say that in so
many words.
Well, yes, literally it says something that implies that the set of
possible values is the same as the set of possible values of an id
attribute. But then it wouldn't be declared CDATA, would it?
Or you could just argue that they kept CDATA here because that was
what was in HMTL/3.2(spit!). Ho hum.


My understanding is that <a name="1"> is intentionally allowed and
well-defined in HTML 4. It would not have been nice to break (in
principle) lots of existing markup for no good reason.

Besides, the restricted syntax of ID doesn't sound reasonable in the
first place. After all, the general (though slow) trend is to _extend_
the syntax of names in computer languages, removing the old restrictions
and allowing national letters etc., excluding only things that really
cannot be used in names. Quite often, identifiers consisting of digits
would be most natural. Consider, for example, a hypertext document that
contains a law, with numbered paragraphs. What would be more natural
than to use id="42" then? The paragraphs are logical parts that need to
be referred to rather often, so they should be available as link
destinations. They typically have no headings, so anything but a number
is artificial. Now we have to use id="p42" or something similar. Or
stick to good old <a name="42">, which is admittedly clumsy.
Feb 8 '06 #9

On Thu, 9 Feb 2006, Jukka K. Korpela wrote:
Alan J. Flavell wrote:
The "a name=" attribute takes a value of type CDATA, which
suggests it could be pretty much anything. But it links to a
piece of text which says

Name = cdata [...]
Note that this attribute shares the same name space as the id
attribute.
That's odd indeed, but I'd read it as a geekish way of saying "you
can't use the same stuff both here and in an id='...'".


That's odd: I thought they were trying to say just the opposite, i.e
that for compatibility with old client agents which only support <a
name="...">, and with (future?) client agents which might only support
id=, it was legal to use the same value in both constructs (to refer
to the same point in the document, assumedly).
Well, yes, literally it says something that implies that the set of
possible values is the same as the set of possible values of an id
attribute. But then it wouldn't be declared CDATA, would it?
If they had declared it in the DTD to be of type ID, then the attempt
to write a bothways-compatible anchor to which I just referred, would
produce a clash due to the duplication of the same ID.
My understanding is that <a name="1"> is intentionally allowed and
well-defined in HTML 4.
You may be right, although I'm unsure of that. That's surely not
compatible with id= with a value of type ID, is it?
Besides, the restricted syntax of ID doesn't sound reasonable in the
first place. [...]


I think that's a different argument, though. I was trying to be sure
what they specification said/meant, rather than what it ought to have
said or meant.

regards
Feb 9 '06 #10
Alan J. Flavell wrote [in part]:
Your <a name="n1"> is for ancient browsers; but if you do that, and if
you use a style for a:hover , you're due for some surprises in a
conforming browser. (IE, <=6, as usual gets this wrong. I don't
know about 7 yet, and I'm not sure I can really be bothered, having
seen how many bugs are still being reported with it).


The name attribute for the anchor is not deprecated in the HTML 4.01
specification. Further, section 12.2.3 seems to imply that the name
attribute is preferred over the id attribute for identifying a
destination for URIs.

Instead of using the id attribute in other elements, I use the the construct
<a name="xxx"> </a>
before the content that I want identified with xxx. Some browsers
position the referenced anchor at the very top of the page. With this
construct, the content is slightly below the top of the page. Here,
there is no advantage to using the id attribute, which I reserve for
non-destination purposes.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>
Feb 9 '06 #11
On Thu, 9 Feb 2006, David E. Ross wrote:
Instead of using the id attribute in other elements, I use the the construct
<a name="xxx"> </a>
before the content that I want identified with xxx.


That's rather complicated. And remember that "A" is an inline element -
so you can't use it around TR, for example. A page like
http://ppewww.ph.gla.ac.uk/~flavell/...a03.html#x0391
would be much more complicated with NAME instead of ID.

--
All free men, wherever they may live, are citizens of Denmark.
And therefore, as a free man, I take pride in the words "Jeg er dansker!"

Feb 9 '06 #12
On Thu, 9 Feb 2006, David E. Ross quoted me saying:
Your <a name="n1"> is for ancient browsers; but if you do that,
and if you use a style for a:hover , you're due for some surprises
in a conforming browser. (IE, <=6, as usual gets this wrong. I
don't know about 7 yet, and I'm not sure I can really be bothered,
having seen how many bugs are still being reported with it).
The name attribute for the anchor is not deprecated in the HTML 4.01
specification.


I'm not sure what that has to do with IE6 and/or 7, or with a:hover in
CSS, so I'll assume that you quoted some material that you hadn't
intended to be relevant (hint: that tends to cause misunderstandings
on usenet), and that you're referring back to my first clause only.

You're technically correct, of course: it's not deprecated in the
HTML/4.01 specification, which is from 1999. However, the use of the
id for this purpose was presaged not later than the never-finished
HTML/3.0 draft from 1995, and I think it's clear which way things have
been moving, albeit slowly, since then.
Further, section 12.2.3 seems to imply that the name attribute is
preferred over the id attribute for identifying a destination for
URIs.
It doesn't say that to me! It says there are some issues to be
considered, and it appears that consideration could go either way,
depending on one's assessment of those issues.

However, you put me to rights as far as something I said earlier,
which I now realise to be wrong. They really -do- advocate using
richer name strings in the <a name="..."> context - strings which
would not be valid as the value of an id= attribute. My apologies to
anyone who was misled by my earlier remarks - I honestly had
overlooked that bit of the spec.

Personally, I would advise authors to steer clear of any name="..."
values which would not be allowable as id= values, being of a somewhat
conservative nature and worrying about whether the associated href's
will ever come out right; but nevertheless, I now realise that the
HTML spec not only allows it, but positively encourages it at that
point, and Jukka expressed similar views - so clearly YMMV.
Instead of using the id attribute in other elements, I use the the
construct
<a name="xxx"> </a>
before the content that I want identified with xxx.
There's something interesting going on here. Of course, some antique
browsers wouldn't honour an anchor unless it contained some
non-whitespace content - you clearly aren't bothering with that, and
I've no argument with you over that (even though, as an old-timer, I
do still put substantive content into any <a name="..."> anchors which
I write). But what is your motivation for including a white space in
your element - does that actually *do* anything?
Some browsers position the referenced anchor at the very top of the
page. With this construct, the content is slightly below the top of
the page. Here, there is no advantage to using the id attribute,
which I reserve for non-destination purposes.


You've every right to do so in HTML if you wish. I'm just saying that
with current browsers it isn't necessary - a useful side-effect is
that use of id= can simplify the markup somewhat.

regards
Feb 9 '06 #13
Andreas Prilop wrote:
On Thu, 9 Feb 2006, David E. Ross wrote:
Instead of using the id attribute in other elements, I use the the construct
<a name="xxx"> </a>
before the content that I want identified with xxx.


That's rather complicated. And remember that "A" is an inline element -
so you can't use it around TR, for example. A page like
http://ppewww.ph.gla.ac.uk/~flavell/...a03.html#x0391
would be much more complicated with NAME instead of ID.


I'm not using it around any other element. I'm using it around a single
blank space.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>
Feb 9 '06 #14
Alan J. Flavell wrote [in part]:

There's something interesting going on here. Of course, some antique
browsers wouldn't honour an anchor unless it contained some
non-whitespace content - you clearly aren't bothering with that, and
I've no argument with you over that (even though, as an old-timer, I
do still put substantive content into any <a name="..."> anchors which
I write). But what is your motivation for including a white space in
your element - does that actually *do* anything?


I use a blank space for two reasons:

(1) It makes the construct stand out better when I go to edit the page.

(2) It means the element does not have null content. I'm not sure
whether all browsers can handle an anchor without any content at all.

HTML 4.01 section 9.1 is not completely clear regarding this usage. A
string of blank characters is collapsed, but whether this is always to
one blank or sometimes to no blanks at all is not mentioned. Further,
while that section says "authors should not rely on user agents to
render white space immediately after a start tag or immediately before
an end tag", it fails to indicate what happens if the SAME white space
is in both positions as the sole content.

In any case, I know that Mozilla does not render any character for the
blank content of my construct but does render the page as I intended
when the URI is referenced, specifically the positioning of the anchor
at the top of the page so that page content following the anchor begins
slightly below the top. I believe IE also renders the page with that
positioning. I also know that this construct is not identified as an
error or even a warning when I validate the page.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail? Use PGP.
See my <http://www.rossde.com/PGP/>
Feb 9 '06 #15
Alan J. Flavell wrote:
On Thu, 9 Feb 2006, Jukka K. Korpela wrote:

Alan J. Flavell wrote:

The "a name=" attribute takes a value of type CDATA, which
suggests it could be pretty much anything. But it links to a
piece of text which says

Name = cdata [...]
Note that this attribute shares the same name space as the id
attribute.


That's odd indeed, but I'd read it as a geekish way of saying "you
can't use the same stuff both here and in an id='...'".

That's odd: I thought they were trying to say just the opposite, i.e
that for compatibility with old client agents which only support <a
name="...">, and with (future?) client agents which might only support
id=, it was legal to use the same value in both constructs (to refer
to the same point in the document, assumedly).


Section 12.2.3 specifies: "The id and name attributes share the same
name space. This means that they cannot both define an anchor with the
same name in the same document. It is permissible to use both attributes
to specify an element's unique identifier for the following elements: A,
APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used
on a single element, their values must be identical."

That's in the section on links. I think whoever wrote it didn't consult
with the person who wrote the section on forms, because there it's
reasonable to have an element with different id and name values--in
particular, in the case of radio buttons. Several radio buttons in the
same logical group MUST have the same name attribute in order to
function as intended, AND if they are to be labeled using label tags, or
they are to be accessed using client-side code using
document.getElementById, then they also must have id values, which CAN'T
be the same.

<li><input type="radio" name="agegroup" id="agegroup1" value="1"
checked><label for="agegroup1">18-21</label></li>
<li><input type="radio" name="agegroup" id="agegroup2" value="2"><label
for="agegroup2">22-26</label></li>
....

The bottom line is, I guess, that there are two unrelated attributes
used for mutually distinct purposes and subject to mutually distinct
rules that were unfortunately both given the name "name".
Feb 24 '06 #16
On Fri, 24 Feb 2006 11:39:09 -0500, Harlan Messinger wrote:
Section 12.2.3 specifies: "The id and name attributes share the same name
space. This means that they cannot both define an anchor with the same
name in the same document. It is permissible to use both attributes to
specify an element's unique identifier for the following elements: A,
APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used
on a single element, their values must be identical."

That's in the section on links. I think whoever wrote it didn't consult
with the person who wrote the section on forms, because there it's
reasonable to have an element with different id and name values--in
particular, in the case of radio buttons. Several radio buttons in the
same logical group MUST have the same name attribute in order to function
as intended, AND if they are to be labeled using label tags, or they are
to be accessed using client-side code using document.getElementById, then
they also must have id values, which CAN'T be the same.


I don't see the contradiction that you do. I read the first paragraph you
quote as saying that the name attribute may also be used to specify the id
of an A, APPLET, FORM, FRAME, IFRAME, IMG, or MAP element in which case,
if there is also an id attribute it must specify the same identifier. It
does not preclude using the same name attribute more than once in other
elemets (like radio buttons) because on these elements the name attribute
is not an alternative way of specifying the id.

The first phrase (that id and name share the same space) *might* be taken
to mean that when choosing names for such elements as radio buttons one
must avoid using strings already used as element id's elsewhere in the
document. Alternatively it might just mean that they share the same space
when playing the same rôle (as a way of setting the id) -- I would not
want to hazard an opinion about which, but either way there is no problem
with duplicate name attributes.

--
Ben.

Feb 26 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by PhillyFan | last post: by
2 posts views Thread by Ginchy | last post: by
1 post views Thread by Barry | last post: by
1 post views Thread by Barry | last post: by
10 posts views Thread by elibol | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.