473,225 Members | 1,414 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,225 software developers and data experts.

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 14442
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: jackogreen | last post by:
Hi, My Asp database generated pages' content links all open a new window containing the same page by default; this is strange since the default behavior for anchor links is to open in the same...
6
by: PhillyFan | last post by:
I have a page setup using anchors. For some reason not all the anchors are working correctly. The last three anchors do not start where they are supposed to. I then started removing the anchor...
2
by: Ginchy | last post by:
I have uploaded a small 3 page web using MS Publisher 2003 and after uploading I switched on url masking to cloak the url. I am certain that it worked fine. I simply changed the colour scheme...
1
by: Barry | last post by:
Hi I am Developing a C# control for use in ASP.NET Web Application, it is has some HtmlAnchor links on it, i want to avoid the underscore which comes in all links, how can i do it it the...
1
by: Barry | last post by:
Hi I am Developing a C# control for use in ASP.NET Web Application, it is has some HtmlAnchor links on it, i want to avoid the underscore which comes in all links, how can i do it it the...
0
by: TurboT | last post by:
We had a an intermittent problem with the aspnet links on our external website. It seemed to be related to the following, but I was wondering if there is some timeout, or caching parameter which...
10
by: elibol | last post by:
Hi, Is there an event that fires when the back or forward button on a browser is pressed? I need an event to fire when someone clicks the back or forward button after an anchor has been set. ...
3
by: elwilson | last post by:
Hi, I'm new to php and looking for suggestions for the following situation: 1. I created a list of FAQ's that I want to be able to link to to further down the page (where the complete FAQ is...
1
by: David C | last post by:
I have posted this question, which I think is very simple on several sites, and nobody seems to know what I am talking about. At my wits end here. Please help. I am putting together a site...
1
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...
0
by: veera ravala | last post by:
ServiceNow is a powerful cloud-based platform that offers a wide range of services to help organizations manage their workflows, operations, and IT services more efficiently. At its core, ServiceNow...
0
by: jianzs | last post by:
Introduction Cloud-native applications are conventionally identified as those designed and nurtured on cloud infrastructure. Such applications, rooted in cloud technologies, skillfully benefit from...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
by: jimatqsi | last post by:
The boss wants the word "CONFIDENTIAL" overlaying certain reports. He wants it large, slanted across the page, on every page, very light gray, outlined letters, not block letters. I thought Word Art...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
0
by: stefan129 | last post by:
Hey forum members, I'm exploring options for SSL certificates for multiple domains. Has anyone had experience with multi-domain SSL certificates? Any recommendations on reliable providers or specific...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.