Reserved words in MSIE6 "top" ?

[Mason A. Clark]

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !

Are there other magic words in MSIE (or other browsers?)

Mason C

[Arne]

Once upon a time *Mason A. Clark* wrote:

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !

Are there other magic words in MSIE (or other browsers?)

I don't think IE understand anything of the kind :)
When you use a link to "#any thing" and the browser don't find
anything that match that, I belive it just jump up to the top of the page.

--
/Arne

Top posters will be ignored. Quote the part you
are replying to, no more and no less! And don't
quote signatures, thank you.

[Harlan Messinger]

Mason A. Clark wrote:

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !

If you *did* have <a name="top"> at the top of the page, then how did
you conclude, when <a href="#top"> worked, that IE6 understands "top"
automatically to mean *the top*?

There's nothing magic about "top" in IE. What's magic is the IE
incorrectly treats *any* href="#abcde" as a request for the top if the
name abcde isn't defined on the page.

[Mason A. Clark]

On Thu, 07 Jul 2005 23:50:52 +0200, Arne <in*****@domain.invalid> wrote:

Once upon a time *Mason A. Clark* wrote:

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !

Are there other magic words in MSIE (or other browsers?)

I don't think IE understand anything of the kind :)
When you use a link to "#any thing" and the browser don't find
anything that match that, I belive it just jump up to the top of the page.

Vas you dere, Charlie? IE6 does NOT go to top with <a href="xxxtop">
IE6 DOES go to the top with <a href="top"> even if there's NO <a name="xxxtop>

Opera goes to top if <a name="top"> is there, not otherwise.

IE6 understands "top" to mean top. Opera does not.

Mason C awaiting proof otherwise (not on MY browsers)

[Mason A. Clark]

On Thu, 07 Jul 2005 17:51:53 -0400, Harlan Messinger
<hm*******************@comcast.net> wrote:

Mason A. Clark wrote:

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !
If you *did* have <a name="top"> at the top of the page, then how did
you conclude, when <a href="#top"> worked, that IE6 understands "top"
automatically to mean *the top*?

Did I not type clearly? IE6 goes to the top whether or not there's a
<a name="top"> at the top. Opera does not.
There's nothing magic about "top" in IE. What's magic is the IE
incorrectly treats *any* href="#abcde" as a request for the top if the
name abcde isn't defined on the page.

Not on my IE6 it doesn't. I tried #abcde and #top with <a name="xtop">
at the top.

Mason C I know nothing about html; just use it.

[Spartanicus]

Mason A. Clark <ma*************@ix.netcom.com> wrote:

Opera goes to top if <a name="top"> is there, not otherwise.
Nor should it.
IE6 understands "top" to mean top.
IE "understands" nothing.
Opera does not.
Where did you get the illusion that "top" is a predefined keyword?
Mason C awaiting proof otherwise (not on MY browsers)

Your difficulties seem to result from the fact that you take IE's
behaviour as the correct behaviour. Wake up to the real world, correct
behaviour is defined by specifications, not by a badly broken piece of
junk such as IE.

--
Spartanicus

[Mason A. Clark]

On Fri, 08 Jul 2005 07:32:39 GMT, Spartanicus <in*****@invalid.invalid> wrote:

Mason A. Clark <ma*************@ix.netcom.com> wrote:

Opera goes to top if <a name="top"> is there, not otherwise.
Nor should it.

IE6 understands "top" to mean top.

IE "understands" nothing.

Opera does not.

Where did you get the illusion that "top" is a predefined keyword?

Because IE6, that real-world abomination, recognizes it.

Mason C awaiting proof otherwise (not on MY browsers)

Your difficulties seem to result from the fact that you take IE's
behaviour as the correct behaviour. Wake up to the real world, correct
behaviour is defined by specifications, not by a badly broken piece of
junk such as IE.

Which just happens to be the most common browser. In the real world
I would like *my* web pages to be operational in that browser.

Mason C you live in your world, I'll live in mine

[Els]

Mason A. Clark wrote:

On Fri, 08 Jul 2005 07:32:39 GMT, Spartanicus <in*****@invalid.invalid> wrote:

Mason A. Clark <ma*************@ix.netcom.com> wrote:

Opera goes to top if <a name="top"> is there, not otherwise.

Nor should it.

IE6 understands "top" to mean top.

IE "understands" nothing.

Opera does not.

Where did you get the illusion that "top" is a predefined keyword?

Because IE6, that real-world abomination, recognizes it.

Mason C awaiting proof otherwise (not on MY browsers)

Your difficulties seem to result from the fact that you take IE's
behaviour as the correct behaviour. Wake up to the real world, correct
behaviour is defined by specifications, not by a badly broken piece of
junk such as IE.

Which just happens to be the most common browser. In the real world
I would like *my* web pages to be operational in that browser.

You're missing the point.
If you write a nice <a name="top" id="top"></a> in the top of your
page, it will still work in IE. The fact that you /can/ also omit it
in IE, does not mean you /should/.

If you want to please IE users and annoy all the other people, yes, go
ahead and build on IE's understanding of the word 'top'. If you want
everybody to be able to click a back to top link, use a proper anchor,
like the specs define, and like even IE follows. The fact that IE
follows any #top link, regardless of there being an anchor, is only
useful for webdesigners who should be aware to test their links in
other browsers than IE, cause IE wouldn't notice the absence of the
anchor.

--
Els http://locusmeus.com/
Sonhos vem. Sonhos vão. O resto é imperfeito.
- Renato Russo -

[Mason A. Clark]

oops -- see post above Els's

[Harlan Messinger]

Mason A. Clark wrote:

On Thu, 07 Jul 2005 17:51:53 -0400, Harlan Messinger
<hm*******************@comcast.net> wrote:

Mason A. Clark wrote:

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !

If you *did* have <a name="top"> at the top of the page, then how did
you conclude, when <a href="#top"> worked, that IE6 understands "top"
automatically to mean *the top*?

Did I not type clearly? IE6 goes to the top whether or not there's a
<a name="top"> at the top. Opera does not.

Which doesn't mean that "IE6 understands 'top' to mean *the top*", which
was your conclusion.

Now I've gone and tested it and I see that you're right--href="#top"
works in IE but href="#asldfkjalsd", for example, doesn't, even when
when no names or IDs are on the page at all. Maybe it was NN4 that used
to jump to the top for any undefined name and I was misremembering. Sorry.

[Mason A. Clark]

On Fri, 08 Jul 2005 10:09:20 -0400, Harlan Messinger
<hm*******************@comcast.net> wrote:

Mason A. Clark wrote:

On Thu, 07 Jul 2005 17:51:53 -0400, Harlan Messinger
<hm*******************@comcast.net> wrote:

Mason A. Clark wrote:

How was I to know that "top" means "top" in MSIE6 ??

I was testing <a name="top"></a> at the top of the page

with <a href="#top>go to top</a> at the bottom of the page.

It always worked in IE so I drew conclusions only to
discover that it worked even with <a name="xtop"></a>

but not in Opera. IE6 understands "top" to mean *the top* !

If you *did* have <a name="top"> at the top of the page, then how did
you conclude, when <a href="#top"> worked, that IE6 understands "top"
automatically to mean *the top*?

Did I not type clearly? IE6 goes to the top whether or not there's a
<a name="top"> at the top. Opera does not.

Which doesn't mean that "IE6 understands 'top' to mean *the top*", which
was your conclusion.

Now I've gone and tested it and I see that you're right--href="#top"
works in IE but href="#asldfkjalsd", for example, doesn't, even when
when no names or IDs are on the page at all. Maybe it was NN4 that used
to jump to the top for any undefined name and I was misremembering. Sorry.

No problem. This is an experimental science.

Mason C

[Gérard Talbot]

Spartanicus wrote :

[snipped]

correct
behaviour is defined by specifications,

http://www.ietf.org/rfc/rfc2396.txt
(section G.4. Modifications from RFC 1808, section 4.2. Same-document
References and section 4.3. Parsing a URI Reference) and
http://www.ietf.org/rfc/rfc1808.txt
(section 2.4.1. Parsing the Fragment Identifier)

"User agents should be able to find anchors created by empty A elements,
but some fail to do so. (...)"
http://www.w3.org/TR/html4/struct/links.html#idx-link-5

The thing is that if the web author avoids empty anchor and validates
his document with a link checker, then there is no need to discuss about
this issue.
The MSIE behavior is not necessarly a bad one when the fragment
identifier is not matched or found. I believe such case is not
documented, therefore entirely up to user agents discretion/latitude.
not by a badly broken piece of
junk such as IE.

I want to say I agree that IE is a piece of junk for various reasons I
will not explain here. And I invite Spartanicus to participate in
reporting bugs, spec violations that MSIE 6 does.

http://channel9.msdn.com/wiki/defaul...plorerFeedback

http://channel9.msdn.com/wiki/defaul...andardsSupport

http://channel9.msdn.com/wiki/defaul...rogrammingBugs

I've personally reported at least 25 bugs, spec violations, testcases
documenting those, and made several enhancement requests of various
types (accessibility and usability).

Gérard
--
remove blah to email me

[Spartanicus]

Gérard Talbot <ne***********@gtalbot.org> wrote:

The MSIE behavior is not necessarly a bad one when the fragment
identifier is not matched or found. I believe such case is not
documented, therefore entirely up to user agents discretion/latitude.
The case made by the OP was that an undefined "top" should result in a
certain behaviour because IE does so.
And I invite Spartanicus to participate in
reporting bugs, spec violations that MSIE 6 does.

Pointless since many others would have done so many years ago, it's safe
to assume that virtually all bugs and lack of support were reported to
MS many times over. They were ignored because MS could afford to do so
having achieved a near monopoly.

I abhor monopolies and the tactics used by Microsoft to achieve such. A
significant part of the reason of why IE is now scheduled for a new
release is that it has lost significant market share. MS wants their
monopoly back, I'll be damned if I'm going to help them achieve that.
It's not in my, and user's interest to see that happen.

--
Spartanicus

[Jukka K. Korpela]

Gérard Talbot <ne***********@gtalbot.org> wrote:

http://www.ietf.org/rfc/rfc2396.txt
Has been obsoleted.
"User agents should be able to find anchors created by empty A
elements, but some fail to do so. (...)"

I cannot see how this relates to this discussion. The construct
<a name="something"></a> is valid but not advisable;
whatever you think about this, it has nothing to with
"reserved" anchor names.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Gérard Talbot]

Spartanicus wrote :

Gérard Talbot <ne***********@gtalbot.org> wrote:

The MSIE behavior is not necessarly a bad one when the fragment
identifier is not matched or found. I believe such case is not
documented, therefore entirely up to user agents discretion/latitude.

The case made by the OP was that an undefined "top" should result in a
certain behaviour because IE does so.

What I'm saying is that the behavior may not be a bad one and that
behavior may not be specifically covered by the specs. Of course, the
explanations provided and case submitted by the OP are wrong.

And I invite Spartanicus to participate in
reporting bugs, spec violations that MSIE 6 does.

Pointless since many others would have done so many years ago, it's safe
to assume that virtually all bugs and lack of support were reported to
MS many times over. They were ignored because MS could afford to do so
having achieved a near monopoly.

Every new release, new version of MSIE since MSIE 3 has improved web
standards support and has removed more spec violations than it has
brought new spec violations. You and I will certainly agree that
- Microsoft in its MSIE product may not have done all it could to
support web standards
- Microsoft in its MSIE product may not have done all it could to
support standards to remove bugs
- Microsoft in its MSIE product may not have done all it could to
support standards to improve MSIE in a timely fashion, on a continuous
manner over the years

But I still maintain that, over the years, IE has improved its standards
support and standards correctness.
I abhor monopolies and the tactics used by Microsoft to achieve such.
I don't like monopolies and tactics used by Microsoft either. Having
MSIE support more the web standards makes it less dependent on its own
proprietary DOM actually and makes it more web-interoperable.
A
significant part of the reason of why IE is now scheduled for a new
release is that it has lost significant market share. MS wants their
monopoly back, I'll be damned if I'm going to help them achieve that.
It's not in my, and user's interest to see that happen.

Commercial interests is one thing. Web standards support, compliance and
correctness is another issue. MSIE will probably continue to lose its
market share in the coming years. Mozilla products, Opera products, etc.
offer better alternative in terms of security, speed, etc. Users - and I
mean here end-users - do not care at all about web standards, do not
relate at all to web standards. Time, efforts and financial budget spent
on developing, maintaining and hosting a website is considerably smaller
if web standards are widely supported and implemented. So, it is in your
best interests as a web developer to promote web standards adoption in
browsers like MSIE 7.

Improving the W3C web standards in MSIE certainly may not improve its
market share actually: it could be the opposite. It would make MSIE
further into a situation where web languages (HTML 4.01, CSS 2.1, etc)
become more and more browser independent... and for the better.

Not too long ago, Opera own CTO asked publicly to have MSIE interoperate
better and according to web standards.

Anyway... you're free to do what you want regarding MSIE 6 bugs.

Gérard
--
remove blah to email me

[Spartanicus]

Gérard Talbot <ne***********@gtalbot.org> wrote:

The MSIE behavior is not necessarly a bad one when the fragment
identifier is not matched or found. I believe such case is not
documented, therefore entirely up to user agents discretion/latitude.
The case made by the OP was that an undefined "top" should result in a
certain behaviour because IE does so.

What I'm saying is that the behavior may not be a bad one and that
behavior may not be specifically covered by the specs.

I heard you the first time. Repeating it doesn't make it relevant to
what you replied to.

And I invite Spartanicus to participate in
reporting bugs, spec violations that MSIE 6 does.

Pointless since many others would have done so many years ago, it's safe
to assume that virtually all bugs and lack of support were reported to
MS many times over. They were ignored because MS could afford to do so
having achieved a near monopoly.

Every new release, new version of MSIE since MSIE 3 has improved web
standards support and has removed more spec violations than it has
brought new spec violations.

Each new version also introduced more proprietary methods that rival
commonly agreed upon methods, or precede such, thereby exerting pressure
to incorporate MS methods into the standards. Regrettably the masses
show little wisdom in using these proprietary methods on the www.

You and I are likely to draw different conclusions as to why we are
stuck were we are. You'd say that it is because of IE's lack of
development over the last years, and that once they (hopefully) bring it
up to date and fix most bugs things will be fine.

I'd say that we are stuck were we are because MS has been allowed to use
outrageously anti competitive methods to propel IE into a near monopoly
position. Bringing it up to date and fixing most bugs will at best only
provide a temporary respite. It will not solve the actual problem, in
fact it will restore the real problem to it's full awful glory just at a
time when thanks to alternative browsers MS is starting to lose some
market share.

Your response to the efforts of alternative browsers to try and move
things forward is to try and restore their nemesis.
MSIE will probably continue to lose its
market share in the coming years. Mozilla products, Opera products, etc.
offer better alternative in terms of security, speed, etc. Users - and I
mean here end-users - do not care at all about web standards, do not
relate at all to web standards.

Which is exactly why IE will be back in it's full monolithic position
quicker than you can say "oops" if it manages to improve the user
experience. To do so it doesn't need to improve standards support at
all.

--
Spartanicus

[Gérard Talbot]

Spartanicus wrote :

Gérard Talbot <ne***********@gtalbot.org> wrote:

And I invite Spartanicus to participate in
reporting bugs, spec violations that MSIE 6 does.
Pointless since many others would have done so many years ago, it's safe
to assume that virtually all bugs and lack of support were reported to
MS many times over. They were ignored because MS could afford to do so
having achieved a near monopoly.

Every new release, new version of MSIE since MSIE 3 has improved web
standards support and has removed more spec violations than it has
brought new spec violations.

Each new version also introduced more proprietary methods that rival
commonly agreed upon methods, or precede such, thereby exerting pressure
to incorporate MS methods into the standards. Regrettably the masses
show little wisdom in using these proprietary methods on the www.

Proprietary DOM properties, methods, attributes is not necessarly bad.
What's bad is (many and/or serious) bugs in implementation of official
W3C web standards, (many and/or serious) spec violations in browsers,
insufficient or improper support of web standards.
You and I are likely to draw different conclusions as to why we are
stuck were we are. You'd say that it is because of IE's lack of
development over the last years, and that once they (hopefully) bring it
up to date and fix most bugs things will be fine.

I'm not *that* optimistic. And it won't be that automatic. But public
pressure and legitimate complaints, sound requests from real web
designers, content developers should weight more than general abstract
whining about bugs in general.
I'd say that we are stuck were we are because MS has been allowed to use
outrageously anti competitive methods to propel IE into a near monopoly
position.
True. I agree with that explanation/conclusion.

Bringing it up to date and fixing most bugs will at best only provide a temporary respite. It will not solve the actual problem, in
fact it will restore the real problem to it's full awful glory just at a
time when thanks to alternative browsers MS is starting to lose some
market share.

Well, if MSIE 7, Opera 8.x, Firefox 1.1 and Safari 2 all pass acid2 test
and have excellent support for HTML 4.01, CSS2.1, DOM 2 Core, DOM 2
Events and other DOM 2 interfaces, then don't you think this will ease
the task of web designers and give more freedom to the users when
updating or upgrading their browsers?
Your response to the efforts of alternative browsers to try and move
things forward is to try and restore their nemesis.

No. Web standards conformance by browsers and web standards adoption by
web designers give ultimately more choice, freedom to the users. It
makes web programming languages and web formating langueges
browser-independent, device-independent, os-independent,
media-independent, etc..

MSIE will probably continue to lose its
market share in the coming years. Mozilla products, Opera products, etc.
offer better alternative in terms of security, speed, etc. Users - and I
mean here end-users - do not care at all about web standards, do not
relate at all to web standards.

Which is exactly why IE will be back in it's full monolithic position
quicker than you can say "oops" if it manages to improve the user
experience. To do so it doesn't need to improve standards support at
all.

We'll see (I am a bit skeptical too about anything Microsoft decides...
and do). Just 4 days ago, this happened:

Webstandards.org to Collaborate with Microsoft to Promote Web Standards
http://webstandards.org/
"Standards are of increasing importance as Web developers strive to make
their sites work across all browsers and accessible by the broadest set
of customers.
- Brian Goldfarb, product manager for Web Platform and Tools at Microsoft."

http://webstandards.org/press/releas.../05/index.html

And you can read several web designers' comments here:
http://www.molly.com/2005/07/05/wasp...web-standards/

Apparently part of the IE 7 dev. team will be on that joined task force.

Gérard
--
remove blah to email me

[Spartanicus]

Gérard Talbot <ne***********@gtalbot.org> wrote:

Proprietary DOM properties, methods, attributes is not necessarly bad.
You may feel nostalgic about the browser war era when manufacturers
tried to outdo each other with proprietary methods, I'm not.
Well, if MSIE 7, Opera 8.x, Firefox 1.1 and Safari 2 all pass acid2 test
and have excellent support for HTML 4.01, CSS2.1, DOM 2 Core, DOM 2
Events and other DOM 2 interfaces, then don't you think this will ease
the task of web designers

No, IE6 will be around for a long time. Last I heard I won't be able to
install IE7 on my W98 system.

I'm also deeply sceptical about MS completing support for CSS2.1 and
fixing most of it's bugs. Your and my web pages might be alright in the
unlikely event that they achieve the aforementioned, but gazillions of
existing webpages were authored to work in IE with no regard for the
standards. Many of these pages are likely to break if IE7 fixes the bugs
and uses a compliant CSS parser.

The last time MS fixed a few bugs they couldn't face the prospect of
infuriating many of their customers because "IE6 broke their webpages",
so they unleashed the fallacy known as doctype switching.

I don't believe that MS is willing to say to their customers "Sorry, we
got it wrong with IE6 and lower, we fixed that now, please update all
your legacy pages". MS is in a dire situation, they're damned if they
don't fix IE, and they're damned if they do. I dread to think what MS
will come up with this time to try and get out of that catch 22
situation.

--
Spartanicus

[Mason A. Clark]

On Sat, 09 Jul 2005 05:20:28 -0400, Gérard Talbot <ne***********@gtalbot.org>
wrote:

Spartanicus wrote :

Gérard Talbot <ne***********@gtalbot.org> wrote:

The MSIE behavior is not necessarly a bad one when the fragment
identifier is not matched or found. I believe such case is not
documented, therefore entirely up to user agents discretion/latitude.

The case made by the OP was that an undefined "top" should result in a
certain behaviour because IE does so.

What I'm saying is that the behavior may not be a bad one and that
behavior may not be specifically covered by the specs. Of course, the
explanations provided and case submitted by the OP are wrong.

An opinion based on standards and theory, not observation.
This is an experimental science. Learn to live with it.

And I invite Spartanicus to participate in
reporting bugs, spec violations that MSIE 6 does.

Pointless since many others would have done so many years ago, it's safe
to assume that virtually all bugs and lack of support were reported to
MS many times over. They were ignored because MS could afford to do so
having achieved a near monopoly.

Every new release, new version of MSIE since MSIE 3 has improved web
standards support and has removed more spec violations than it has
brought new spec violations. You and I will certainly agree that
- Microsoft in its MSIE product may not have done all it could to
support web standards
- Microsoft in its MSIE product may not have done all it could to
support standards to remove bugs
- Microsoft in its MSIE product may not have done all it could to
support standards to improve MSIE in a timely fashion, on a continuous
manner over the years

But I still maintain that, over the years, IE has improved its standards
support and standards correctness.

I abhor monopolies and the tactics used by Microsoft to achieve such.

I don't like monopolies and tactics used by Microsoft either. Having
MSIE support more the web standards makes it less dependent on its own
proprietary DOM actually and makes it more web-interoperable.

A
significant part of the reason of why IE is now scheduled for a new
release is that it has lost significant market share. MS wants their
monopoly back, I'll be damned if I'm going to help them achieve that.
It's not in my, and user's interest to see that happen.

Commercial interests is one thing. Web standards support, compliance and
correctness is another issue. MSIE will probably continue to lose its
market share in the coming years. Mozilla products, Opera products, etc.
offer better alternative in terms of security, speed, etc. Users - and I
mean here end-users - do not care at all about web standards, do not
relate at all to web standards. Time, efforts and financial budget spent
on developing, maintaining and hosting a website is considerably smaller
if web standards are widely supported and implemented. So, it is in your
best interests as a web developer to promote web standards adoption in
browsers like MSIE 7.

Improving the W3C web standards in MSIE certainly may not improve its
market share actually: it could be the opposite. It would make MSIE
further into a situation where web languages (HTML 4.01, CSS 2.1, etc)
become more and more browser independent... and for the better.

Not too long ago, Opera own CTO asked publicly to have MSIE interoperate
better and according to web standards.

Anyway... you're free to do what you want regarding MSIE 6 bugs.

Gérard

[Andy Dingley]

On Fri, 08 Jul 2005 20:06:12 GMT, Mason A. Clark
<ma*************@ix.netcom.com> wrote:

No problem. This is an experimental science.

What the web needs is a central organising body that produced clear and
exact specification docuemnts so that M$oft could easily follow them,

Nah......