Ed's Odd scrolling issue

[Neil Gould]

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.

Another way that server-side code works is to interact with user input,
which can be a wide variety of things including clicking on scroll bars and
page up/down keys. Eliminating that variable seems reasonable to me, even if
it is unlikely to be the source of the problem. I still don't see you
suggesting anything useful to help Ed resolve his problem.

 

[Jonathan N. Little]

Another way that server-side code works is to interact with user input,
which can be a wide variety of things including clicking on scroll bars and
page up/down keys.

No absolutely not. The *only* "interaction with the server is over http
via GET and POST requests, keystrokes events, mouse events, viewport
change, button clicks, all these thing and handled within the browser
and the server sees *none* of these. What can be confusing is is Ajax
which uses JavaScript to generate GET and POST requests to dynamically
update the page, but that is a whole other subject.

Eliminating that variable seems reasonable to me, even if
it is unlikely to be the source of the problem. I still don't see you
suggesting anything useful to help Ed resolve his problem.

You may have found an HTML or CSS issues, but you are still incorrect in
suggesting that it had anything to do with PHP, unless the PHP in
generating something different in the resulting HTML.

 

[Osmo Saarikumpu]

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.

Perhaps we could all aid Ed with his scrolling issue, if you would show
us an example.

 

[Jonathan N. Little]

Well, it's not just Ajax. ASP, ASP.NET, etc. can also generate http GET and
POST, and they don't require JavaScript to do so.

But the ASP or ASP.NET is doing it, it it the outputted HTML link or
form SUBMIT button.

 

[Tim Streater]

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.

Certainly not. But your poor phrasing left the distinct impression that
you thought that PHP code embedded in an HTML page arrived intact in
the browser and thereafter was somehow magically executed in the
server.

 

[Neil Gould]

No absolutely not. The *only* "interaction with the server is over
http via GET and POST requests, keystrokes events, mouse events,
viewport change, button clicks, all these thing and handled within
the browser and the server sees *none* of these. What can be
confusing is is Ajax which uses JavaScript to generate GET and POST
requests to dynamically update the page, but that is a whole other
subject.

Well, it's not just Ajax. ASP, ASP.NET, etc. can also generate http GET and
POST, and they don't require JavaScript to do so. It's been a while since I
wrote PHP pages since that language wasn't quite as robust as some others,
but I can accept that it may not be capable of such things. I still think
that eliminating that variable is a valid troubleshooting technique.

You may have found an HTML or CSS issues, but you are still incorrect
in suggesting that it had anything to do with PHP, unless the PHP in
generating something different in the resulting HTML.

I actually *do* think it's likely to be a CSS issue, particularly one that
older browsers ignore, but so far nobody has exposed such an issue.

 

[Neil Gould]

Perhaps we could all aid Ed with his scrolling issue, if you would
show us an example.

Why, you can't find pages on the web with fixed headers that behave as
expected in current FF versions? They're not rare.

 

[Jonathan N. Little]

Well, with ASP or ASP.NET, "submit" is not the only user action that can
launch a server-side routine, for example it is possible after escaping via
an "onclick" instruction. That really is not the point of my bringing it up,
anyway. I just think it's a good idea to reduce the number of variables when
troubleshooting a problem.

If by "escaping" you mean using serve-side so select block of pure HTML
during the loading of a page, i.e.,
<http://www.php.net/manual/en/language.basic-syntax.phpmode.php>
Once the server sends the page, what the browser gets is just HTML.
There so no more client/server interaction until you make another page
request from the server. To can scroll, page up or down, and click all
you wish, PHP or ASP will "hear" none of it without and HTML link or
from submit button. Anything else requires something client-side such as
JavaScript or ActionScript of Flash. The server-side has nothing to do
with this. That "onclick" instruction you keep referring to has nothing
to do with the server or the server-side script.

 

[Neil Gould]

Certainly not. But your poor phrasing left the distinct impression
that you thought that PHP code embedded in an HTML page arrived
intact in the browser and thereafter was somehow magically executed
in the server.

Your interpretation of my phrasing is peculiar. The quote that you replied
to has to do with the phrase "Escaping from HTML", which inherently implies
that there HTML is not invovled with whatever is going on server-side. My
comments prior to that were on reducing the number of variables that could
cause Ed's problem by writing the page as straight HTML. Do you *really*
have a problem with that?

 

[Neil Gould]

But the ASP or ASP.NET is doing it, it it the outputted HTML link or
form SUBMIT button.

Well, with ASP or ASP.NET, "submit" is not the only user action that can
launch a server-side routine, for example it is possible after escaping via
an "onclick" instruction. That really is not the point of my bringing it up,
anyway. I just think it's a good idea to reduce the number of variables when
troubleshooting a problem.

 

[Tim Streater]

If by "escaping" you mean using serve-side so select block of pure HTML
during the loading of a page, i.e.,
<http://www.php.net/manual/en/language.basic-syntax.phpmode.php>
Once the server sends the page, what the browser gets is just HTML.
There so no more client/server interaction until you make another page
request from the server. To can scroll, page up or down, and click all
you wish, PHP or ASP will "hear" none of it without and HTML link or
from submit button. Anything else requires something client-side such as
JavaScript or ActionScript of Flash. The server-side has nothing to do
with this. That "onclick" instruction you keep referring to has nothing
to do with the server or the server-side script.

Unless the onclick results in a form being submitted or an ajax request
being made.

 

[Jonathan N. Little]

Unless the onclick results in a form being submitted or an ajax request
being made.

I believe that is what I said. The "magic" in Ajax is client-side
JavaScript.

 

[dorayme]

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.

The better suggestion is in the part you quoted below. It will show
you that the issue has nothing to do with php.

 

[dorayme]

Jonathan N. Little wrote: ....

Another way that server-side code works is to interact with user input,
which can be a wide variety of things including clicking on scroll bars and
page up/down keys. Eliminating that variable seems reasonable to me, even if
it is unlikely to be the source of the problem. I still don't see you
suggesting anything useful to help Ed resolve his problem.

It is not wrong for Jonathan to have addressed a specific matter that
you have raised without addressing other matters.

Btw, Neil, not sure if you know, but your signature appears in many
newsreader software when replying to your posts, the replier wanting
it gone (it being unnecessary in the reply) and having to remove it by
hand. If it is formed in a special way, it gets removed on replies
automatically.

You can save repliers the trouble by

(newline)(dash)(dash)(space)(newline)

See Jonathan's signature block.

 

[Neil Gould]

Btw, Neil, not sure if you know, but your signature appears in many
newsreader software when replying to your posts, the replier wanting
it gone (it being unnecessary in the reply) and having to remove it by
hand. If it is formed in a special way, it gets removed on replies
automatically.

You can save repliers the trouble by

(newline)(dash)(dash)(space)(newline)

See Jonathan's signature block.

That is how my signature block is configured (and has been since the early
'80s, btw), and it works as expected in the readers I use. See if this makes
a difference in yours:

 

[Jonathan N. Little]

That is how my signature block is configured (and has been since the early
'80s, btw), and it works as expected in the readers I use. See if this makes
a difference in yours:

I saw nothing wrong with Neil's sig block. Must be one of those
Mac-things eh dorayme? ;-)

 

[Jonathan N. Little]

That was going to be my guess, too. As far back as my Mac Plus, Apple has
gotten ASCII EOL wrong. I would have thought they'd have fixed that flaw by
now! ;-D

Apple is always a bit contrary. Like I was dismayed to discover that the
*hand-held* iPhone iGnores handheld media types so you have to use an
additional media query on screen size in your stylesheets.

 

[Neil Gould]

I saw nothing wrong with Neil's sig block. Must be one of those
Mac-things eh dorayme? ;-)

That was going to be my guess, too. As far back as my Mac Plus, Apple has
gotten ASCII EOL wrong. I would have thought they'd have fixed that flaw by
now! ;-D

 

[Tim Streater]

I saw nothing wrong with Neil's sig block. Must be one of those
Mac-things eh dorayme? ;-)

Works fine on this Mac so <raspberry> to ya!

 

[Neil Gould]

The better suggestion is in the part you quoted below. It will show
you that the issue has nothing to do with php.

I quoted it because it seems that we're in agreement that eliminating the
server-side variable is a good idea (that is what your method accomplishes).
Now, if it actually does show what you claim it does, then the source of the
problem should be easier to locate by examining the CSS associated with the
header. I haven't gone through that, but Ed should.