Ed's Odd scrolling issue

[Neil Gould]

Hi Ed,

Preface: I am somewhat limited in that my newsreader doesn't display the
original post, but the post which quoted what I think was the original
question had a link to your page. I had mentioned that your page worked as
expected (with regard to scrolling) in older versions of FF. Later, in a
discussion with dorayme, I mentioned that I've written HTML pages with fixed
headers that still scroll properly in the latest FF versions.

OK. The reason I didn't proffer a "solution" based on my experience is that
yours is a php page, and that, to me, has possible implications about how it
is actually being generated and that might account for quirks in the way it
interacts with some browser engines. One way to know if that is the source
of the problem would be to write the same content as an HTML page and see
whether the problem persists.

 

[Jonathan N. Little]

Hi Ed,

Preface: I am somewhat limited in that my newsreader doesn't display the
original post, but the post which quoted what I think was the original
question had a link to your page. I had mentioned that your page worked as
expected (with regard to scrolling) in older versions of FF. Later, in a
discussion with dorayme, I mentioned that I've written HTML pages with fixed
headers that still scroll properly in the latest FF versions.

OK. The reason I didn't proffer a "solution" based on my experience is that
yours is a php page, and that, to me, has possible implications about how it
is actually being generated and that might account for quirks in the way it
interacts with some browser engines. One way to know if that is the source
of the problem would be to write the same content as an HTML page and see
whether the problem persists.

Being server-side vs static html should not be an issue at all, as far
as the browser is concerned is only 'sees' an html document.

 

[dorayme]

Hi Ed,

Preface: I am somewhat limited in that my newsreader doesn't display the
original post, but the post which quoted what I think was the original
question had a link to your page. I had mentioned that your page worked as
expected (with regard to scrolling) in older versions of FF. Later, in a
discussion with dorayme, I mentioned that I've written HTML pages with fixed
headers that still scroll properly in the latest FF versions.

OK. The reason I didn't proffer a "solution" based on my experience is that
yours is a php page, and that, to me, has possible implications about how it
is actually being generated and that might account for quirks in the way it
interacts with some browser engines. One way to know if that is the source
of the problem would be to write the same content as an HTML page and see
whether the problem persists.

In the url I gave right at the start of the thread to test browsers
for the fault perceived, there was no php. So what is your suggestion
for avoiding the page down and click under problems in that one?

That .php appears in the urls in a markup is, of course, nothing that
can affect a browser's scrolling behaviour.

As for what is generated on the server, you can see it for yourself
from View menu in many browsers, there are no php instructions, all of
those are carried out on the server before the browser gets to do its
business.

 

[Neil Gould]

Thanks for the thought, Neil. As others have suggested all the PHP
processing is done server-side. Once done what is sent to the browser
IS HTML.

Your info that earlier versions of FF work correctly is good to know.
I'll investigate that.

I know that php processing is server-side. I also know that server-side
instructions can affect such things as "on-click" actions, among other
things. As I can't see the server-side code, I didn't presume that no such
instructions exist simply because the page sent to the browser consists of
the HTML portions.

As I said before, I have much more complex fixed headers in some HTML pages
that work as expected in the latest versions of FF, so something else might
be at play here. So, making troubleshooting easier comes down writing the
page as HTML to see if the scrolling problem persists. If it goes away, then
you know where to start looking.

 

[Neil Gould]

Being server-side vs static html should not be an issue at all, as far
as the browser is concerned is only 'sees' an html document.

In my experience, it depends on what is going on in the server-side code.
The page is not necessarily static, which may be the underlying problem.

 

[Neil Gould]

In the url I gave right at the start of the thread to test browsers
for the fault perceived, there was no php. So what is your suggestion
for avoiding the page down and click under problems in that one?

My newsreader doesn't go back that far. Please give the urls again, and I'll
take a look.

That .php appears in the urls in a markup is, of course, nothing that
can affect a browser's scrolling behaviour.

That guarantee differs from my experience.

As for what is generated on the server, you can see it for yourself
from View menu in many browsers, there are no php instructions, all of
those are carried out on the server before the browser gets to do its
business.

I can't see the server-side code in my browser.

 

[Jonathan N. Little]

In my experience, it depends on what is going on in the server-side code.
The page is not necessarily static, which may be the underlying problem.

That is server push which is a whole other story involving streaming or
ajax...but that would not be the same as a static html.

 

[Jonathan N. Little]

That guarantee differs from my experience.

I think you are mistaken on the causality of the issue.

I can't see the server-side code in my browser.

Of course you cannot, if you did then the server is misconfigured. As
far as the browser is concerned it is just HTML.

 

[Jonathan N. Little]

Ed Mullen wrote:

I know that php processing is server-side. I also know that server-side
instructions can affect such things as "on-click" actions, among other
things.

No it cannot. The "on-click" event is handled by the browser. Client
side JavaScript can, but PHP "knows" nothing about your client-side
JavaScript. PHP and any server-side will know nothing baout was is done
client-side until there is an HTTP request. Otherwise we are taking
about Ajax, which is JavaScript and still not PHP.

 

[Neil Gould]

I think you are mistaken on the causality of the issue.

So... in your opinion, I really *do* know what's causing Ed's problem? I had
no idea! ;-)

 

[Tim Streater]

So...when one *escapes* HTML via a PHP instruction ...

What does this mean, if anything?

 

[Neil Gould]

No it cannot. The "on-click" event is handled by the browser. Client
side JavaScript can, but PHP "knows" nothing about your client-side
JavaScript. PHP and any server-side will know nothing baout was is
done client-side until there is an HTTP request.

So...when one *escapes* HTML via a PHP instruction triggered by user action,
nothing else happens? My suggestion was to *eliminate* that possibililty and
see how the page behaves. If you really believe this is an unreasonable
approach, then perhaps you have a better suggestion for Ed?

 

[dorayme]

....

As I said before, I have much more complex fixed headers in some HTML pages
that work as expected in the latest versions of FF, so something else might
be at play here. So, making troubleshooting easier comes down writing the
page as HTML to see if the scrolling problem persists. If it goes away, then
you know where to start looking.

You have all the resources at hand to show any PHP generated page's
html that is the source of the web page you see. If you just have a
browser like FF with no add-ons like the useful Web Developer (from
which you can recover resources like the HTML and CSS more easily and
even live-alter things just to see what would happen if you changed
things)

1. Get the page up in your browser and View
Source or Page Source (the HTML that the
browser is using to display the page at that
moment)

2. Select all, then copy and paste it into
your favourite text editor, name the file
"test.html"

3. Inspect the head of the "test.html" for
links to stylesheets, go to those links one
at a time, starting with the topmost one.
Copy and paste the CSS into the STYLE element
in the head of "test.html".

4. Inspect the HTML markup for links to
images (and perhaps other things like movies)
that are meant to display on the webpage.
Work out the full paths to them and
substitute those for the relative paths. This
will get them to display. If you can't do
this for any reason just alter the links to
pictures of your own the same size (or sized
in the IMG element to be the same or via CSS)
as the ones on the live website.

The resulting website page, if all goes well, should look and behave
as the original. At least you can test your worries about php, it will
have no php in it. If you are worried that you even see urls within
your "test.html" sporting .php endings, change the endings to .html -
actually clicking links is going to be irrelevant browser scrolling
behaviour so it hardly matters what they are.

Or you could short circuit all of this and look at the first URL I
gave at the beginning of the thread that tests for browser's scrolling
behaviour with fixed headers where you can see exactly what is
happening, you are also welcome to change it in any way you please to
stop unwanted scrolling behaviour. You can instead inspect Ed's later
test url and see if your techniques can help him.

If you are having trouble looking up things from the past in your
newsreader, you can go to Google Groups and the thread is all there,
you can inspect Ed's original url or *his* later test url:

<https://groups.google.com/forum/?hl=en#!topic/alt.html/b2_5Fv7pqMo[1
01-125-false%5D>

 

[dorayme]

So... in your opinion, I really *do* know what's causing Ed's problem? I had
no idea! ;-)

No, that is not what is being said. What is being said is that the
mere fact that ".php" appears in urls in the html doc behind the
webpage has no causal bearing on the scrolling behaviour, nothing more
and nothing less. You can test this for yourself as explained in
another post.

 

[Neil Gould]

What does this mean, if anything?

"Escaping" from HTML is when an instruction in HTML page causes the next
step in the processing to run server-side code. In PHP:

http://www.php.net/manual/en/language.basic-syntax.phpmode.php

The same concept applies to other scripting languages.

 

[Tim Streater]

"Escaping" from HTML is when an instruction in HTML page causes the next
step in the processing to run server-side code. In PHP:

http://www.php.net/manual/en/language.basic-syntax.phpmode.php

The same concept applies to other scripting languages.

Are you trying to wind me up? By the time the html page has arrived at
the browser there is no PHP code in it. It's already been executed in
the server. If you think otherwise, I suggest you reread the link you
posted, this time for comprehension.

 

[Tim Streater]

Neil Gould wrote:
dorayme wrote:

No, that is not what is being said. What is being said is that the
mere fact that ".php" appears in urls in the html doc behind the
webpage has no causal bearing on the scrolling behaviour, nothing more
and nothing less. You can test this for yourself as explained in
another post.

Mr Gould appears to have a very limited grasp of how all this stuff
works. Or possibly none at all.

 

[Jonathan N. Little]

"Escaping" from HTML is when an instruction in HTML page causes the next
step in the processing to run server-side code. In PHP:

http://www.php.net/manual/en/language.basic-syntax.phpmode.php

The same concept applies to other scripting languages.

Makes no difference what the server-side script outputs the browser only
sees is indistinguishable from a static HTML document. It is how a
webserver works.

 

[Neil Gould]

You have all the resources at hand to show any PHP generated page's
html that is the source of the web page you see.

The server-side code is what is in question, and you can't see that with a
browser. I'm just suggesting to Ed that he eliminate that variable as part
of troubleshooting the page, and as I said to Jonathan, if you have a better
suggestion, let Ed know.
--
best regards,

Neil



If you just have a

 

[Neil Gould]

Are you trying to wind me up? By the time the html page has arrived at
the browser there is no PHP code in it.

I didn't say that there was, and that isn't the point at all. It appears
that you (and others) are under the erroneous impression that server-side
code can't affect the way a page behaves.

It's already been executed in
the server. If you think otherwise, I suggest you reread the link you
posted, this time for comprehension.

Eliminating variables is a well-established way to troubleshoot any problem,
and that's all I've suggested. Rather than toss out insults, why not toss
out a suggestion to help Ed?