Re: Odd scrolling issue

Discussion in 'HTML' started by dorayme, Jan 21, 2014.

  1. dorayme

    dorayme Guest

    In article <>,
    Ed Mullen <> wrote:

    > Okay, here's a weird one.
    >
    > Someone was perusing one of my Web sites and said, to paraphrase:
    >
    > "If I click in the vertical scroll bar below the handle the page scrolls
    > down more than one full screen."
    >
    > That is, the vast majority of pages (I've checked many) will scroll so
    > that the bottom of the first page is now at the top. The pages on my
    > site scroll up past that, so that the content of the initial screen is
    > above the top of the page. Meaning that the user will be missing, not
    > see, some content.
    >
    > http://edmullen.net/mozilla/moz_combine.php
    >

    ....

    > Only the Moz-based browsers exhibit the problem. Although, oddly enough,
    > they scroll properly using the Page Up and Page Down keyboard buttons.
    >


    On my Mac Safari, it happens too.

    > I have tested this on a variety of sites online and most do not exhibit
    > this but several do.
    >
    > While it seems to be a problem with the Mozilla core core, it also seems
    > to be somehow HTML/CSS related too since some pages don't do this but
    > all of mine do. Any thoughts welcome.


    You are right about this. A simple

    <body style="margin:0;">
    <div><img src="Malgorzata-Dydek.jpg" alt="Tallest woman in the world"
    width="1000" height="3000">

    does not exhibit the problem.

    With CSS off, the problem on your page largely goes away (there is a
    slight difference between click below handles and page down, but only
    slight)

    I suspect it is to do with your *fixed* #doc_header in your default
    CSS.

    --
    dorayme
    dorayme, Jan 21, 2014
    #1
    1. Advertising

  2. On 22.1.2014 0:55, dorayme wrote:
    > In article <>,
    > Ed Mullen <> wrote:
    >> Only the Moz-based browsers exhibit the problem. Although, oddly enough,
    >> they scroll properly using the Page Up and Page Down keyboard buttons.


    > On my Mac Safari, it happens too.


    And I can reproduce the behavior in my Win Chrome also.

    > I suspect it is to do with your *fixed* #doc_header in your default
    > CSS.


    It seems so, as removing position:fixed *fixes* the problem.

    More info:

    https://bugzilla.mozilla.org/show_bug.cgi?id=780345

    --
    Best wishes, Osmo
    Osmo Saarikumpu, Jan 22, 2014
    #2
    1. Advertising

  3. dorayme

    dorayme Guest

    In article <>,
    Ed Mullen <> wrote:

    > dorayme wrote:
    > > In article <>,
    > > Ed Mullen <> wrote:
    > >
    > >> Okay, here's a weird one.
    > >>
    > >> Someone was perusing one of my Web sites and said, to paraphrase:
    > >>
    > >> "If I click in the vertical scroll bar below the handle the page scrolls
    > >> down more than one full screen."
    > >>

    ....
    > >>
    > >> http://edmullen.net/mozilla/moz_combine.php
    > >>

    > > ...
    > >
    > >> Only the Moz-based browsers exhibit the problem. Although, oddly enough,
    > >> they scroll properly using the Page Up and Page Down keyboard buttons.
    > >>



    As I said, other browsers also exhibit the issue bothering you.


    > >
    > > I suspect it is to do with your *fixed* #doc_header in your default
    > > CSS.
    > >

    >
    > Hmm. Now the question is, given my layout, how to develop some strategy
    > for incrementally disabling various rules in my CSS to try to figure it
    > out. Hmm.
    >
    > But! Also, why isn't this happening across different browsers? I'm
    > loathe to go chasing my CSS tail if this a browser-dependent issue.
    >
    > As I said in my OP, it seems to be both HTML/CSS on a particular page
    > AND Mozilla-based browsers' handling of it.
    >
    > Quite mysterious!


    All I can offer you is a cleaner test and a couple of suggestions,
    others can add others:

    <http://dorayme.netweaver.com.au/underFixedHeaderScrollingTest.html>

    --
    dorayme
    dorayme, Jan 24, 2014
    #3
  4. dorayme

    dorayme Guest

    In article <>,
    dorayme <> wrote:

    > In article <>,
    > Ed Mullen <> wrote:
    >
    > > dorayme wrote:
    > > > In article <>,
    > > > Ed Mullen <> wrote:

    ....
    > > >>
    > > >> http://edmullen.net/mozilla/moz_combine.php
    > > >>

    ....
    > >

    ....
    > > Quite mysterious!

    >
    > All I can offer you is a cleaner test and a couple of suggestions,
    > others can add others:
    >
    > <http://dorayme.netweaver.com.au/underFixedHeaderScrollingTest.html>


    I have begun noticing the same thing for other sites that used fixed
    headers, they may be taking following the sort of advice i mention in
    my link above (namely, not worrying about it!) See, for example:


    <http://app.nytimes.com/#2014/01/25/nytfrontpage/fatal-bomb-attacks-in-
    egypt>

    --
    dorayme
    dorayme, Jan 26, 2014
    #4
  5. dorayme

    dorayme Guest

    In article <>,
    Ed Mullen <> wrote:

    > dorayme wrote:
    > > In article <>,
    > > dorayme <> wrote:
    > >
    > >> In article <>,
    > >> Ed Mullen <> wrote:
    > >>
    > >>> dorayme wrote:
    > >>>> In article <>,
    > >>>> Ed Mullen <> wrote:

    > > ...
    > >>>>>
    > >>>>> http://edmullen.net/mozilla/moz_combine.php
    > >>>>>

    > > ...
    > >>>

    > > ...
    > >>> Quite mysterious!
    > >>
    > >> All I can offer you is a cleaner test and a couple of suggestions,
    > >> others can add others:
    > >>
    > >> <http://dorayme.netweaver.com.au/underFixedHeaderScrollingTest.html>

    > >
    > > I have begun noticing the same thing for other sites that used fixed
    > > headers, they may be taking following the sort of advice i mention in
    > > my link above (namely, not worrying about it!) See, for example:
    > >
    > >
    > > <http://app.nytimes.com/#2014/01/25/nytfrontpage/fatal-bomb-attacks-in-
    > > egypt>
    > >

    >
    > dorayme, your insights are always appreciated.
    >
    > My perspective is this.
    >
    > Someone may not like the design attitude of a fixed header. So be it.
    >


    Well, this is not at all in question. We are assuming fixed headers.


    > But the page(s) validate, both HTML and CSS. The issue I described
    > originally comes down to one of the Mozilla rendering engine incorrectly
    > handling such a case. And it only does it with one function,
    > click-in-vertical-scroll-bar, NOT Page Down keyboard. So, there is code
    > to in the application to do it right, they bjust need to apply it to all
    > the GUI cases, not just one.
    >


    Well, I keep saying it is *not just* Mozilla. I will try not to say it
    again. <g>


    > Hence, the browser is broken, not the page. So, as I was loathe in the
    > old days to special code for IE versions, I will not now special code
    > for Mozilla browsers.
    >
    > Also, Mozilla has for decades boasted about its "standards compliant"
    > attitude. So, hey, comply this.


    Looking at the link I gave you to test with, are any of your
    non-Mozilla browsers scrolling the bottom-most number to *under* the
    fixed header on either page down key or on click under scroll handle?
    What CSS would you add to stop this happening in non-Mozilla browsers?

    I am trying to simplify what is happening so you can develop a
    strategy.

    --
    dorayme
    dorayme, Jan 26, 2014
    #5
  6. dorayme

    Neil Gould Guest

    Ed Mullen wrote:
    >> dorayme wrote:
    >> [heavily snipped]
    >> It depends on how you fill and further style:
    >>
    >> <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>
    >>
    >> It might solve your problem. <g>

    >
    > ;-) But, it's NOT my problem, it's the Mozilla-based browsers'
    > problem.
    >

    Ed, you've nailed the issue, Mozilla screwed up their code in newer
    browsers. All of these pages work properly in FF12, which shows that it is
    not your code that is the problem. Firefox for Android *really* screws up
    sites with fixed headers, and there are many, from very large organizations
    that use this type of header. So, I agree with your approach of not trying
    to "code your way around" this problem.
    --
    best regards,

    Neil
    Neil Gould, Jan 27, 2014
    #6
  7. dorayme

    dorayme Guest

    In article <>,
    Ed Mullen <> wrote:

    > dorayme wrote:
    > > In article <>,
    > > Ed Mullen <> wrote:
    > >
    > >> dorayme wrote, then Ed Mullen, then dorayme, then maybe Roger Rabbit...
    > >> anyway...

    > >
    > >>>>>>
    > >>>>>> <http://dorayme.netweaver.com.au/underFixedHeaderScrollingTest.html>
    > >>>>>

    > >
    > >> The links you gave don't really demonstrate the issue since the first
    > >> one the scrolling text is not under the fixed header.

    > >
    > > There is no colour set on the background of the header so that you can
    > > see where the numbers scroll to under the top of the viewport. The
    > > header is deliberately widthed so that you can see it too and read the
    > > writing, the relevant bit of it being its *height*, the scrolling
    > > numbers not interfering with you seeing them clearly when they go
    > > above the bottom of the header. It demonstrates the issue if you take
    > > these two things into account. You can see exactly how high in the
    > > viewport different browsers page-down and click-under-handle down.
    > >

    >
    > the text is offset to the right and does not flow up under the fixed
    > header. What am I missing?
    >


    You are missing that you do not need to see the numbers disappear
    completely, all you need to see is how they are placed in the viewport
    with respect to the height of the header. You can see exactly where
    the numbers are scrolling up to behind what would be the full width
    header with a background if one styled it so.

    ....


    > >
    > > <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>
    > >
    > > It might solve your problem. <g>

    >
    > ;-) But, it's NOT my problem, it's the Mozilla-based browsers' problem.
    >


    Being so exasperated by something (so much that it drives you to drink
    - see below), sounds like you have a problem with it! <g>

    ....

    > >> What is annoying is that Page Down works just fine in the Mozzies. So,
    > >> the code is in there to do this correctly.

    > >


    ....

    > > Even page-down does not work in some other good browsers.

    >
    > But you ignore my point: Page Down in those browser works fine. So,
    > the code exists in the browser to do it right. It simply isn't applied
    > to the "click in the vertical scroll area" part of the UI. Their Page
    > Down and Page Up keyboard functions work fine. All they need to do is
    > apply the same routine to the "click in the vertical scroll area" function.
    >


    It is not ignoring your point to point out that there other browsers
    which exhibit the same "problem" with not only click under scroll bar
    handles but also with Page Down.


    > And, if we're having different results in our tests, well, even more
    > evidence that something is amiss in the browsers, not my validated HTMO
    > and CSS.



    Validated HTML and CSS cannot guarantee that browser chromes work as
    you expect. What you are seeing is not *against* any HTML or CSS
    standards *as far as I know* (I could be wrong, see below). They may
    be against some commonsense or against what you would want if you
    design with fixed headers but that is different. There are lots and
    lots of things like this. You must look after your health Ed and not
    let it drive you to drink. I am dispatching a team of health
    professionals to help you, it's ok, I have paid them.

    > Especially Mozilla browsers. For a decade or more I've been
    > using them in part because of their "supposed" adherence to the W3C
    > standards. The W3C defines and embraces postion:fixed. All I'm doing is
    > complaining about how a (supposedly) compliant browser screws it up.
    >


    It looks as if you know something I don't here. Is there something in
    the W3C standards that actually tackles the particular problem you
    have raised?

    > > Trying to tackle this problem from the author end may be a hiding to
    > > nothing.
    > >

    >
    > Yeah, it's annoying. But now fatal. And, there seems to be nothing to
    > do (for the author) about it.
    >
    > And the end-all seems to be this.
    >
    > I think I'll another have bourbon and just ignore this for now.


    --
    dorayme
    dorayme, Jan 27, 2014
    #7
  8. dorayme

    Ray_Net Guest

    Re: Odd scrolling issue suggestion

    In article <>,
    says...
    >
    > "Ray_Net" <> wrote in message news:...
    > > In article <>,
    > > says...
    > >> Make four pages
    > >> For all four User-Agents
    > >> Browsers

    > > Just one page shows the Mozilla browser bug.
    > > But the question is:
    > > Will it be corrected or never ?

    >
    > Will I would not <blink> ;) </blink
    > Never will Blank with IE
    > And it's not a bug.
    >

    If other browsers works correctly, it's a Mozilla bug !
    Ray_Net, Jan 27, 2014
    #8
  9. dorayme

    dorayme Guest

    In article <>,
    Ed Mullen <> wrote:

    > dorayme wrote:
    > > In article <lc5t2h$ftj$>,
    > > "Neil Gould" <> wrote:
    > >
    > >> Ed, you've nailed the issue, Mozilla screwed up their code in newer
    > >> browsers. All of these pages work properly in FF12, which shows that it is
    > >> not your code that is the problem. Firefox for Android *really* screws up
    > >> sites with fixed headers, and there are many, from very large organizations
    > >> that use this type of header. So, I agree with your approach of not trying
    > >> to "code your way around" this problem.

    > >
    > > If browsers don't do what you expect them to do with the markup and
    > > style you use, you should never modify your work?
    > >

    >
    > Of course not. But that isn't responsive to the case in discussion.



    It was meant to invite Neil Gould to say interesting things relevant
    to the question of under what circumstances an author should modify
    their HTML/CSS and design and when not.


    > ... I'm suprised you'd comment
    > like that, omitting knowledge of previous facts of this discussion. ;-)


    It was not a comment, it was a question, and it was a serious one.

    What facts was I *omitting*?

    And please cite the relevant HTML/CSS or any other industry standard
    that all browser makers should be aware of that requires the page down
    and the click under scroll handler to behave as you are wanting.

    --
    dorayme
    dorayme, Jan 28, 2014
    #9
  10. dorayme

    dorayme Guest

    In article <>,
    Ed Mullen <> wrote:

    > dorayme wrote:
    > > In article <>,
    > > Ed Mullen <> wrote:
    > >
    > >> dorayme wrote:
    > >>> In article <lc5t2h$ftj$>,
    > >>> "Neil Gould" <> wrote:
    > >>>
    > >>>> Ed, you've nailed the issue, Mozilla screwed up their code in newer
    > >>>> browsers. All of these pages work properly in FF12, which shows that it
    > >>>> is
    > >>>> not your code that is the problem. Firefox for Android *really* screws
    > >>>> up
    > >>>> sites with fixed headers, and there are many, from very large
    > >>>> organizations
    > >>>> that use this type of header. So, I agree with your approach of not
    > >>>> trying
    > >>>> to "code your way around" this problem.
    > >>>
    > >>> If browsers don't do what you expect them to do with the markup and
    > >>> style you use, you should never modify your work?
    > >>>
    > >>
    > >> Of course not. But that isn't responsive to the case in discussion.

    > >
    > >
    > > It was meant to invite Neil Gould to say interesting things relevant
    > > to the question of under what circumstances an author should modify
    > > their HTML/CSS and design and when not.

    >
    > Understood. I'm just saying modifying my code and/or design is not an
    > appropriate answer/solution since I'm using standards compliant HTML and
    > CSS.
    >


    This goes against what authors have been (albeit reluctantly) doing
    for years and years, namely modifying the way they design to
    accommodate real word realities. "Standards compliant" HTML and CSS is
    good and you are to be commended for respecting it. But to say it is
    inappropriate course of action, something not to be considered, is a
    bridge too far and especially so if you are not sure that there is a
    standard for browser chrome behaviour in the specific circumstances
    you have been concerned about.

    ....

    > >
    > > And please cite the relevant HTML/CSS or any other industry standard
    > > that all browser makers should be aware of that requires the page down
    > > and the click under scroll handler to behave as you are wanting.
    > >

    >
    > Never said there was one. I suppose there might be but I don't think it
    > matters.


    It does not matter? If there is no standard, nothing agreed upon that
    is respected by browser makers, are they not free to do what they
    think best? If different browsers behave differently in respect to
    some styling, as has been the case for years where the standards are
    not clear or give no guidance, then it would seem reasonable for
    authors who are concerned about browser rendering and browser chrome
    differences not to be too sure in their exasperation that it is the
    browser's faults.

    There are issues about how a browser is to *know* when a fixed element
    is not make like a carpet under which scrolling content can hide.
    There are types of designs where authors might want their scrolling to
    appear in the fixed elements. The issue is not a simple one. The way
    browsers behave in respect to it might not be bugs to be corrected.

    However, it is true that if a browser does do Page Down one way, it
    *may* be reasonable to expect, as you do, for it to do click under
    scroll handler the same. But the issue is clouded, even dwarfed by
    that other browsers do neither as you want them to.

    Anyway, for anyone that is interested in these matters and who are as
    exasperated by the issue, one possible solution at least to consider
    is something along the lines of

    <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>

    If it is styled appropriately, it might well not be even ugly. Imagine
    a nice background image on the header, there are ways for it to be
    height fluid with a horizontal menu at its bottom, all not needing
    scrolling, the scrollbars becoming active and to the far right for the
    content when needed. It is just a thought, I know you will not use it.
    But others might find it interesting to play with. I confess I have
    not tested in in many browsers as yet.

    --
    dorayme
    dorayme, Jan 28, 2014
    #10
  11. dorayme

    Neil Gould Guest

    dorayme wrote:
    > In article <lc5t2h$ftj$>,
    > "Neil Gould" <> wrote:
    >
    >> Ed, you've nailed the issue, Mozilla screwed up their code in newer
    >> browsers. All of these pages work properly in FF12, which shows that
    >> it is not your code that is the problem. Firefox for Android
    >> *really* screws up sites with fixed headers, and there are many,
    >> from very large organizations that use this type of header. So, I
    >> agree with your approach of not trying to "code your way around"
    >> this problem.

    >
    > If browsers don't do what you expect them to do with the markup and
    > style you use, you should never modify your work?
    >

    Depends on who is paying. This case shows that there can be no end to having
    to come up with workarounds.
    --
    best regards,

    Neil
    Neil Gould, Jan 29, 2014
    #11
  12. dorayme

    Neil Gould Guest

    dorayme wrote:
    >
    > It does not matter? If there is no standard, nothing agreed upon that
    > is respected by browser makers, are they not free to do what they
    > think best?
    >

    Is that not the way that things were for many years prior to W3C? Should the
    designer be obligated to constantly revise their work without compensation,
    simply because some browsers decide to ignore the "generally accepted
    practices", much less agreed upon standards?

    > If different browsers behave differently in respect to
    > some styling, as has been the case for years where the standards are
    > not clear or give no guidance, then it would seem reasonable for
    > authors who are concerned about browser rendering and browser chrome
    > differences not to be too sure in their exasperation that it is the
    > browser's faults.
    >

    It's one thing for browsers to display poorly defined styling attributes
    incorrectly, and it's pretty easy as a designer to stay away from those
    things. However, this is a case where there is no excuse, since earlier
    versions of the FF browser work properly. I think it simply exposed the flaw
    in the "upgrade" per month concept that Mozilla launched into a few years
    ago. And, I don't feel obligated in any way to limit myself to those things
    that it gets wrong.
    --
    best regards,

    Neil
    Neil Gould, Jan 29, 2014
    #12
  13. dorayme

    Guest

    On Tuesday, January 28, 2014 10:13:18 PM UTC+1, dorayme wrote:
    > Anyway, for anyone that is interested in these matters and who are as
    > exasperated by the issue, one possible solution at least to consider
    > is something along the lines of
    >
    > <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>
    >
    > If it is styled appropriately, it might well not be even ugly. ...


    > dorayme


    great - found a styled page with menu (header) and good scrolling:
    http://kurier.at/politik/inland/noch-eine-frage-herr-bundeskanzler/48.771.037
    , Jan 29, 2014
    #13
  14. dorayme

    dorayme Guest

    In article <>,
    wrote:

    > On Tuesday, January 28, 2014 10:13:18 PM UTC+1, dorayme wrote:
    > > Anyway, for anyone that is interested in these matters and who are as
    > > exasperated by the issue, one possible solution at least to consider
    > > is something along the lines of
    > >
    > > <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>
    > >
    > > If it is styled appropriately, it might well not be even ugly. ...

    >
    > > dorayme

    >
    > great - found a styled page with menu (header) and good scrolling:
    > http://kurier.at/politik/inland/noch-eine-frage-herr-bundeskanzler/48.771.037


    On a quick test on my Safari, it does indeed scroll to expose the
    *very next* line tht was not previously visible (on both page-down and
    click-under-scrollbars). In a very strict way! It is super correct to
    the point of being user unfriendly. In normal page-downs and
    click-unders where there is no painted header acting like a carpet,
    what is visible at the bottom before the scroll appears at the top,
    thus giving useful reminder to the user of the context.

    --
    dorayme
    dorayme, Jan 29, 2014
    #14
  15. dorayme

    dorayme Guest

    In article <lcb9ub$cp7$>,
    "Neil Gould" <> wrote:

    > dorayme wrote:
    > > In article <lc5t2h$ftj$>,
    > > "Neil Gould" <> wrote:
    > >
    > >> Ed, you've nailed the issue, Mozilla screwed up their code in newer
    > >> browsers. All of these pages work properly in FF12, which shows that
    > >> it is not your code that is the problem. Firefox for Android
    > >> *really* screws up sites with fixed headers, and there are many,
    > >> from very large organizations that use this type of header. So, I
    > >> agree with your approach of not trying to "code your way around"
    > >> this problem.

    > >
    > > If browsers don't do what you expect them to do with the markup and
    > > style you use, you should never modify your work?
    > >

    > Depends on who is paying.


    OK, if a client noticed a problem on his mainstream browser that
    bothered him, that would be a reason, he's paying! If an author is
    exasperated by how one or more browsers do one or more things, there
    is a choice for the author to way up the exasperation of it against
    that of accommodating (ie. avoiding) it.

    > This case shows that there can be no end to having
    > to come up with workarounds.


    Not sure how it really shows that.

    --
    dorayme
    dorayme, Jan 29, 2014
    #15
  16. dorayme

    dorayme Guest

    In article <lcbanu$i03$>,
    "Neil Gould" <> wrote:

    > dorayme wrote:
    > >
    > > It does not matter? If there is no standard, nothing agreed upon that
    > > is respected by browser makers, are they not free to do what they
    > > think best?
    > >

    > Is that not the way that things were for many years prior to W3C? Should the
    > designer be obligated to constantly revise their work without compensation,
    > simply because some browsers decide to ignore the "generally accepted
    > practices", much less agreed upon standards?
    >


    Well, a few points. You perhaps don't know that Ed is a very wealthy
    man and would be loathe to accept any reasonable payment for web work
    (it would be a mere pittance to him). The second point is that we
    better distinguish standards from generally accepted practices in
    their relevance. And third, what are the generally accepted standards
    across browser*s* on this matter?


    > > If different browsers behave differently in respect to
    > > some styling, as has been the case for years where the standards are
    > > not clear or give no guidance, then it would seem reasonable for
    > > authors who are concerned about browser rendering and browser chrome
    > > differences not to be too sure in their exasperation that it is the
    > > browser's faults.
    > >

    > It's one thing for browsers to display poorly defined styling attributes
    > incorrectly, and it's pretty easy as a designer to stay away from those
    > things.


    OK, on this we agree.

    > However, this is a case where there is no excuse, since earlier
    > versions of the FF browser work properly. I think it simply exposed the flaw
    > in the "upgrade" per month concept that Mozilla launched into a few years
    > ago. And, I don't feel obligated in any way to limit myself to those things
    > that it gets wrong.


    I agree, as I have indicated previously, that it is reasonable to
    expect a particular browser to do some things consistently (albeit
    that are not covered by any particular authoritative standard).

    I don't understand your last sentence. No one is forcing anyone to do
    anything. It is all a matter of how exasperating the different courses
    of action are.

    Obviously there is an issue to do with FF. But the issue over browser
    response to fixed headers seems a wider one to me.

    --
    dorayme
    dorayme, Jan 29, 2014
    #16
  17. dorayme

    Ray_Net Guest

    Re: Odd scrolling issue suggestion

    In article <>,
    says...
    >
    > "Ray_Net" <> wrote in message news:...
    > > In article <>,
    > > says...
    > >> "Ray_Net" <> wrote in message news:...
    > >> > In article <>,
    > >> > says...
    > >> >> Make four pages
    > >> >> For all four User-Agents
    > >> >> Browsers
    > >> > Just one page shows the Mozilla browser bug.
    > >> > But the question is:
    > >> > Will it be corrected or never ?
    > >> Will I would not <blink> ;) </blink
    > >> Never will Blank with IE
    > >> And it's not a bug.
    > >>

    > > If other browsers works correctly, it's a Mozilla bug !

    >
    > Ask Mozilla to fix it
    > You do know how right
    >
    > Free Server
    > news.mozilla.org
    > No Log in needed
    >
    > News Group
    > mozilla.general

    They know it already - but i don't expect a cure.
    Ray_Net, Jan 30, 2014
    #17
  18. dorayme

    Ray_Net Guest

    In article <>, says...
    >
    > dorayme wrote:
    >
    > >
    > > It is not ignoring your point to point out that there other browsers
    > > which exhibit the same "problem" with not only click under scroll bar
    > > handles but also with Page Down.

    >
    > But you seem to ignore my several citations where I say that other
    > browsers do NOT exhibit this behavior. Also, that the Moz browsers DO
    > contain a function (Page Down keyboard function) that works as it
    > should. And, if the programmers would simply apply that code to a click
    > in the vertical scroll bar, well, no problem.


    ....
    ....
    In article <>,
    nickname: Hot-Text says...
    > Ask Mozilla to fix it
    > You do know how right
    >
    > Free Server
    > news.mozilla.org
    > No Log in needed
    >
    > News Group
    > mozilla.general
    >
    Ray_Net, Jan 30, 2014
    #18
  19. dorayme

    Gus Richter Guest

    On 1/29/2014 7:30 PM, Ed Mullen wrote:
    > wrote:
    >> On Tuesday, January 28, 2014 10:13:18 PM UTC+1, dorayme wrote:
    >>> Anyway, for anyone that is interested in these matters and who are as
    >>> exasperated by the issue, one possible solution at least to consider
    >>> is something along the lines of
    >>>
    >>> <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>
    >>>
    >>> If it is styled appropriately, it might well not be even ugly. ...

    >>
    >>> dorayme

    >>
    >> great - found a styled page with menu (header) and good scrolling:
    >> http://kurier.at/politik/inland/noch-eine-frage-herr-bundeskanzler/48.771.037
    >>
    >>

    >
    > Almost. But not in my Moz-based browsers. I still have to scroll up a
    > bit to ensure I'm not missing the context. In fact, it fails miserably
    > using keyboard Page Down. No, sorry, bad example unless you're tying to
    > prove my point.



    Ref: <http://codepen.io/anon/pen/FwAdr>

    Check out the method I used to modify someone elses submission.

    Your method is to wrap everything and the header is fixed and you have a
    problem.

    Here, the method is to separate the Nav div and the Wrapper Div into
    separate divs. The Nav div is fixed. Does it relate and help?

    --
    Gus
    Gus Richter, Jan 30, 2014
    #19
  20. dorayme

    Guest

    On Thursday, January 30, 2014 1:50:10 AM UTC+1, Gus Richter wrote:
    > >>> Anyway, for anyone that is interested in these matters and who are as
    > >>> exasperated by the issue, one possible solution at least to consider
    > >>> is something along the lines of
    > >>> <http://dorayme.netweaver.com.au/fixedContentUnderFixedHeader.html>
    > >>> If it is styled appropriately, it might well not be even ugly. ...
    > >>> dorayme
    > >>
    > >> great - found a styled page with menu (header) and good scrolling:
    > >> http://kurier.at/politik/inland/noch-eine-frage-herr-bundeskanzler/48.771.037
    > >>

    > > Almost. But not in my Moz-based browsers. I still have to scroll up a
    > > bit to ensure I'm not missing the context. In fact, it fails miserably
    > > using keyboard Page Down. No, sorry, bad example unless you're tying to
    > > prove my point.

    >
    > Ref: <http://codepen.io/anon/pen/FwAdr>
    > Check out the method I used to modify someone elses submission.
    > Your method is to wrap everything and the header is fixed and you have a
    > problem.
    >
    > Here, the method is to separate the Nav div and the Wrapper Div into
    > separate divs. The Nav div is fixed. Does it relate and help?
    >
    > Gus


    dorayme solved the problem by reducing the scrollbar
    range to the content div
    and you reducing the height of the menu -

    yes, it's true - my example doesn't help 100% now (menu height very small)
    but there is a little improvement at least.
    in the beginning it's a big field and when you scroll down
    the small height menu is "fixed" or what you call it

    yes, sorry - not that expected solution
    , Jan 30, 2014
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    120
  2. TK
    Replies:
    0
    Views:
    104
  3. Norman Peelman

    Re: Odd scrolling issue

    Norman Peelman, Jan 22, 2014, in forum: HTML
    Replies:
    0
    Views:
    132
    Norman Peelman
    Jan 22, 2014
  4. Neil Gould

    Re: Odd scrolling issue

    Neil Gould, Jan 23, 2014, in forum: HTML
    Replies:
    0
    Views:
    121
    Neil Gould
    Jan 23, 2014
  5. Neil Gould

    Ed's Odd scrolling issue

    Neil Gould, Feb 4, 2014, in forum: HTML
    Replies:
    76
    Views:
    651
    Ray_Net
    Feb 20, 2014
Loading...

Share This Page