Ed's Odd scrolling issue

[dorayme]

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:

Works fine in mine, temporary hiccup. Apologies to you.

 

[dorayme]

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

My Mac is different to average, it has special software insisted upon
by my minders back on my distant home planet, it sometimes interferes
with things. All fixed now.

Look Jonathan, I know you want a Mac badly, why not just simply give
in and go get one! <g>

 

[dorayme]

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.

My point was not about why you quoted it. It was about you using it to
see for yourself to see that the php has nothing to do with the
original issue.

In another post I pointed out that there have been URLs quoted of
simple webpages that do not use PHP at all and exhibit the problem.

And I have posted ways for you to overcome your problem with access to
earlier posts in a thread.

You said you have had no trouble with scrolling behaviour from fixed
headers in your designs. So what are you doing that Ed is not doing
that is relevant? Got a simple html/css only cut down example of your
work?

The *source* of the problem is not the CSS. It is that browser
scrolling behaviour reactions are not what is wanted. And the general
solution is a bit more complicated than might be thought (much on this
has been discussed - at least by me).

 

[dorayme]

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

In one of Neil's posts from Feb 7, he sigs *and* then quotes below the
sig a good amount of stuff that I said. At least that is how it
appeared on my reader. This was the post where neither his sig nor my
stuff disappeared on hitting reply in MT-NW.

It also had a small bit without the quote mark below his name. There
were a few return spaces between his "Neil" and the stuff. When you
hit reply to this post, does all disappear from just under above his
two dashes in your usenet reader, Tim? what about you, Jonathan?

See Neil's post

<https://groups.google.com/forum/#!msg/alt.html/HoU6srTvGLM/cZLWvHLtoMw
J>

I assumed his sig block was malformed but it appears there was another
issue. It may not be my newsreader. Or maybe it is technically
malformed in just his one post because of the text below.

 

[Tim Streater]

In one of Neil's posts from Feb 7, he sigs *and* then quotes below the
sig a good amount of stuff that I said. At least that is how it
appeared on my reader. This was the post where neither his sig nor my
stuff disappeared on hitting reply in MT-NW.

It also had a small bit without the quote mark below his name. There
were a few return spaces between his "Neil" and the stuff. When you
hit reply to this post, does all disappear from just under above his
two dashes in your usenet reader, Tim? what about you, Jonathan?

See Neil's post

<https://groups.google.com/forum/#!msg/alt.html/HoU6srTvGLM/cZLWvHLtoMw
J>

I assumed his sig block was malformed but it appears there was another
issue. It may not be my newsreader. Or maybe it is technically
malformed in just his one post because of the text below.

The quick brown fox jumped over the lazy dog.

I did "Follow up via posting" in Thoth, snipped nothing (unusual for
me), and this is what you get.

 

[Jonathan N. Little]

My Mac is different to average, it has special software insisted upon
by my minders back on my distant home planet, it sometimes interferes
with things. All fixed now.

Look Jonathan, I know you want a Mac badly, why not just simply give
in and go get one! <g>

Ssssh closet apple-fanboy. I don't think so. This system here might be
my last Winbox.

 

[TK]

That's the thing... it could be a variety of issues. Since his page works in
older versions of FF, I suspect that his problem is rooted in some HTML/CSS
usage that older browsers ignore.

Not that is relevant to his problem, AFAICT. The fixed-header pages I have
work properly in newer versions of FF, but are mostly based on HTML 4.01 &
CSS2. There are many such examples on the web.

I copied Ed's page complete, renamed it htm, and it displayed the
described problem exactly (on my local drive) - it is not a php related
issue. I did have to remove the leading / on the css/img addresses for
the page to display their effects.

 

[Neil Gould]

You said you have had no trouble with scrolling behaviour from fixed
headers in your designs. So what are you doing that Ed is not doing
that is relevant?

That's the thing... it could be a variety of issues. Since his page works in
older versions of FF, I suspect that his problem is rooted in some HTML/CSS
usage that older browsers ignore.

Got a simple html/css only cut down example of your work?

Not that is relevant to his problem, AFAICT. The fixed-header pages I have
work properly in newer versions of FF, but are mostly based on HTML 4.01 &
CSS2. There are many such examples on the web.

The *source* of the problem is not the CSS.

How can you be sure? Have you located the HTML issue that causes the
behavior? See my comments above.

It is that browser
scrolling behaviour reactions are not what is wanted. And the general
solution is a bit more complicated than might be thought (much on this
has been discussed - at least by me).

As I see it, there are not infinite possibilities, here. If the cause of the
problem is not in the server-side code, and it's not in the CSS, then it
must be in the HTML of Ed's page, which is not complex.

 

[TK]

What happened *before* you removed the leading / on the CSS address? If the
page scrolled properly even though the content may not appear as desired it
points the finger at his CSS as being the culprit.

I did have to remove the leading / on the css/img addresses for the page
to display their effects (scrolling problem).

I think (and always have) it is a css problem. Firefox has always been
more picky imho. Close to correct is not good enough and some of the
"errors" it finds seem to be suggestions in some cases.

 

[Neil Gould]

I copied Ed's page complete, renamed it htm, and it displayed the
described problem exactly (on my local drive) - it is not a php
related issue. I did have to remove the leading / on the css/img
addresses for the page to display their effects.

What happened *before* you removed the leading / on the CSS address? If the
page scrolled properly even though the content may not appear as desired it
points the finger at his CSS as being the culprit.

 

[dorayme]

dorayme wrote: ....

Not that is relevant to his problem, AFAICT. The fixed-header pages I have
work properly in newer versions of FF, but are mostly based on HTML 4.01 &
CSS2. There are many such examples on the web.

Ed himself gave a test case very early in the original thread. It used
no php and needed nothing but your favourite doc type and css - he
wanted pretty for some reason but we can eliminate all that and easily
put a 4.01 doctype on.

You could look at that, and demonstrate how you would go about
producing that basic look (minus the pretty CSS, no need for CSS3)
that works to scroll as you and Ed want it to scroll in FF at least
(if you you are not interested in browsers in general).

Use your 4.01 and CSS2 as his mainly does.

How can you be sure? Have you located the HTML issue that causes the
behavior?

What was "the" cause of 9/11? It's complicated! The matter is an
interaction between a styled page and various browsers. Different
browsers can and do give different results. Even the same browser,
like FF, can give different results depending on the text size of the
user.

Styling BODY element with top margins etc. has uncertain results in
different browsers vis a vis scrolling. Even user text size can affect
the results. Take a look at:

<http://dorayme.netweaver.com.au/fixedHeaders/bodyTopMargining.html>


the inconsistency between FF's Page Down and Click under scroll handle
is evident at normal user text size. But alter it on your own browser
(by say Zoom Texting Up) and neither works as you would want. In
Safari, nothing works as you would want.

What is needed is a different approach. Best is probably to avoid
fixed header that go all the way across the viewport at the top, they
take up valuable viewport space for a start, but at the very least
keep them very small in height to minimise browser differences and
unwanted reactions vis a vis scrolling

If the cause of the
problem is not in the server-side code, and it's not in the CSS, then it
must be in the HTML of Ed's page, which is not complex.

How do you avoid it? What is your *basic strategy* in all *your*
webpages that employ fixed headers but do not exhibit Ed's problem
that you have talked about?

 

[dorayme]

Styling BODY element with top margins etc. has uncertain results in
different browsers vis a vis scrolling. Even user text size can affect
the results. Take a look at:

<http://dorayme.netweaver.com.au/fixedHeaders/bodyTopMargining.html>

In fact many other ways of styling also have the same uncertain results

<http://dorayme.netweaver.com.au/fixedHeaders/contentTopMargining.html>

where the body element is left alone, the content dive is styled to be
below the header. As in the first url, FF does things differently to
Safari. In the former, the distinction between Page Down and Click
Under scroll handlers remains unsatisfactory and worse, completely
fails when user ups his or her text size under bothe Page Down and
Click Under. In Safari, the situation is unsatisfactory at all user
text sizes.

Similar remarks apply to anothe rway, padding the top of the content
area:

<http://dorayme.netweaver.com.au/fixedHeaders/topPaddingContentFixedHea
der.html>

I will say it again: there is no standard I know of that browsers are
following in this matter. If you think there are, cite it. If you
think there should be, say how it should be unambiguously worded.

 

[Neil Gould]

Hi Ed,

Okay, this is getting a tad silly. I detailed elsewhere what I use PHP
for on my sites and that it has nothing to do with scrolling issues.
[...]

Perhaps you haven't had a chance to follow all the chatter on this, so let
me clarify that the whole idea of eliminating the PHP was to reduce the
number of variables for troubleshooting. Once that is done, the PHP issue is
closed.

More on point, on Feb 6th, Jonathan and I had an exchange which ended as
such:

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.

This was confirmed, IMO, when on Feb 8th, Terry Kimpling ran some tests on
your page that revealed:

I did have to remove the leading / on the css/img addresses for the page
to display their effects (scrolling problem).

I think (and always have) it is a css problem. Firefox has always been
more picky imho. Close to correct is not good enough and some of the
"errors" it finds seem to be suggestions in some cases.

I think that you can resolve the problem by examining your CSS related to
the fixed header.

 

[dorayme]

I think that you can resolve the problem by examining your CSS related to
the fixed header.

He can examine it till his eyeballs hurt and it won't help unless he
takes a sensible detailed general proposal to a meeting with browser
maker bosses. Failing that, he could take a .44 magnum and insist the
scrolling works as he wants for *his* particular valid pages.

 

[jfaerber172]

Ssssh closet apple-fanboy. I don't think so. This system here might be
my last Winbox.

Take care,
Jonathan

next is the pine box?

 

[Jonathan N. Little]

next is the pine box?

For Windows maybe... Convert the last to Linux.

 

[dorayme]

<http://dorayme.netweaver.com.au/fixedHeaders>

/bodyTopMargining.html

/contentTopMargining.html

/topPaddingContentFixedHeader.html

In case anyone is interested, there are all sorts of other ways to go
in having fixed headers. One of the downsides of all of the above (all
of which have less than ideal page down or click under scrollbar
handles results in probably all browsers) is having to decide on a
height for the header and/or top margin for the content below. One way
to avoid having to do this - gaining a truer flexibility without need
for javascript - is to give the content a dummy header (there is no
real need to style it but you could if you can think of one):

/dummyHeader.html

Hope to God that CSS is always on for your users on this last one! <g>

 

[Neil Gould]

He can examine it till his eyeballs hurt and it won't help unless he
takes a sensible detailed general proposal to a meeting with browser
maker bosses. Failing that, he could take a .44 magnum and insist the
scrolling works as he wants for *his* particular valid pages.

Perhaps you are conflating "troubleshooting" with "shooting for trouble"?
;-D

By now, it should be apparent that I prefer logic and objective tests to
determine the cause of problems. TK has established that Ed's page as
straight HTML /does scroll properly/ in FF *until the CSS is linked*, which
proves that the scrolling problem is somewhere in the CSS. My _guess_ is
that it's associated with the fixed-position header, but it could lie in the
other body elements, too. The bottom line is that if Ed wants the page to
work as he stated he wants, he can get it to do so by changing the CSS.

 

[dorayme]

By now, it should be apparent that I prefer logic and objective tests to
determine the cause of problems.

Nothing pretentious or banal or self-deprecating or sense of humoured
about that statement!

TK has established that Ed's page as
straight HTML /does scroll properly/ in FF *until the CSS is linked*,

Your statement (not TK's) is about as sensible as saying that the Twin
Towers were perfectly ok until they were hit by those planes. What on
earth does "properly" mean where the *essential* context of the
problem is missing, namely browser reactions to fixed header css?

which
proves that the scrolling problem is somewhere in the CSS.

It proves nothing of the sort. The problem is not *in* the css.

My _guess_ is
that it's associated with the fixed-position header,

Of course it is *associated* with this. It is that browsers in general
have no good algorithms to scroll in the way you want with fixed
headers, at least not in the simple and legal HTML/CSS setups we have
been looking at.

Not even Page Down always works as wanted in fixed header contexts in
various browsers.

 

[dorayme]

Mozill DOES have a good algorithm for this and it is implemented with
Page Down which works reliably as I noted in my OP.

Let's say that FF on many OSs does and does not do what you say it
does and does not do. The wider issue is surely not about this one
browser but about browsers generally. If it is the case that there is
some good algorithm that all browsers could use to fix your particular
concern, then great! But could this really be? And might it not have
unintended consequences?

It is best either not to worry about it since many browsers will not
do what you want or else to redesign. In fixed header designs, at
least scrolling in other ways (moving the scrollbars manually, turning
mouse wheels and finger scrapes on trackpads work well afaik.

As before, it DOES work in Moz-based browsers I've tested.

Not in one I am looking at right now in FF 27 on my Mac under some
conditions of user text and viewport size. Your test case, as are
mine, are *fragile*, a bit more text in the header to take up more
height and you won't get Page Down working if my tests are anything to
go on.


There are a lot of other browsers that people use where Page Down and
Click Under Scroll bar does not quite happily do, are you not worried
about those?

Seems to me all they need to do is use the same algorithm for
click-in-vertical-scrollbar.

I admire your optimism that the architecture of different browsers
lends itself to algorithmic portability. You are bolder than me in how
things seem to you in what appears prima facie not too apparent.