Setting focus on div with Mozilla

Arne <in*****@domain .invalid> wrote:

During testing <div style="overflow :auto;"> in CSS I noticed the
mousewheel would work in Mozilla only after I made a <a href="#">some
text</a> link and clicked on that, within the div.

It appears as if Mozilla needs to have the focus set on that div in
order for the mousewheel to work. That's all that link does. The
mousewheel works perfectly in IE without the link. It scrolls the div
even if there is a scrollbar on the page.

Now consider a keyboard user, for them your scrolling thingy is also a
nightmare to use. Which is why creating any scrollable viewport within
the main viewport is considered a usability no-no.

--
Spartanicus

Once upon a time *Spartanicus* wrote:

Arne <in*****@domain .invalid> wrote:

During testing <div style="overflow :auto;"> in CSS I noticed the
mousewheel would work in Mozilla only after I made a <a href="#">some
text</a> link and clicked on that, within the div.

It appears as if Mozilla needs to have the focus set on that div in
order for the mousewheel to work. That's all that link does. The
mousewheel works perfectly in IE without the link. It scrolls the div
even if there is a scrollbar on the page.

Now consider a keyboard user, for them your scrolling thingy is also a
nightmare to use. Which is why creating any scrollable viewport within
the main viewport is considered a usability no-no.

Read again what I wrote: I'm *testing* it but have so far no intention
or need to use it.

Why am testing? That's because there is sites 'out there' that use
scrolling div's and I discovered that I could not use my mousewheel to
scroll when I used Mozilla. In IE it works by placing the cursor
anywhere inside the div.

With the link inside the div the scrolling works on IE even for
keyboard users, even if it may be a nightmare the keys takes you thru
the links and when the link in the div is focused you can scroll it
with the arrow keys.

So my question still stands open, why does that work in other browsers
and is there a way (others than I described abow) to make it work? But
remember now, I know about the "usability no-no" but I would like to
know since I would like to use the scrolling on sites where they use
the scrolling div's.

If the "usability no-no" is the reason why standard compliant (is it
the right word?) browser don't support it, then why support the
scrolling divs at all?

--
/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.

Arne <in*****@domain .invalid> wrote:

I would like to use the scrolling on sites where they use
the scrolling div's.

If that is the case then the question belongs in a group specific to
your browser, not a group devoted to www authoring such as this.

--
Spartanicus

On Sun, 17 Jul 2005 20:22:11 GMT, Spartanicus
<in*****@invali d.invalid> wrote:

Now consider a keyboard user, for them your scrolling thingy is also a
nightmare to use. Which is why creating any scrollable viewport within
the main viewport is considered a usability no-no.

I never thought about that before, in terms of scrollable tables. I
presume the same would apply?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

In article
<ke************ *************** *****@news.spar tanicus.utvinte rnet.ie>,
Spartanicus <in*****@invali d.invalid> wrote:

Arne <in*****@domain .invalid> wrote:

During testing <div style="overflow :auto;"> in CSS I noticed the
mousewheel would work in Mozilla only after I made a <a href="#">some
text</a> link and clicked on that, within the div.

It appears as if Mozilla needs to have the focus set on that div in
order for the mousewheel to work.
Makes sense, doesn't it? I think every GUI I ever used required focus on
an object before that object can be manipulated.
That's all that link does.
Sounds like Mozilla doesn't offer a way to activate the object (your
DIV), but due to its capability of setting focus to *hyperlinks* you get
the result you see.

I'd consider this bad UI design.
The
mousewheel works perfectly in IE without the link. It scrolls the div
even if there is a scrollbar on the page.

I presume you mean you can set focus to the DIV somehow, even when it
doesn't contain a hyperlink? I can't imagine it 'just works' - then how
would IE know when to scroll the viewport and when a child?
Now consider a keyboard user, for them your scrolling thingy is also a
nightmare to use. Which is why creating any scrollable viewport within
the main viewport is considered a usability no-no.

I don't see the logic there. It's up to the browser vendor to ensure the
user can access whatever object he may want/need to access in whatever
way the user might want that.

I don't see specific browsers' limitations as a reason to 'dumb down' a
site (which would mean dumbing it down for everybody, including those
who use a more powerful browser).

--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>

Sander Tekelenburg wrote:

In article
<ke************ *************** *****@news.spar tanicus.utvinte rnet.ie>,
Spartanicus <in*****@invali d.invalid> wrote:

Arne <in*****@domain .invalid> wrote:

During testing <div style="overflow :auto;"> in CSS I noticed the
mousewheel would work in Mozilla only after I made a <a href="#">some
text</a> link and clicked on that, within the div.

It appears as if Mozilla needs to have the focus set on that div in
order for the mousewheel to work.

Makes sense, doesn't it? I think every GUI I ever used required focus on
an object before that object can be manipulated.
Your use of 'focus' is out of context - the OP was using focus in the
sense of DOM elements. A DIV element does not have a focus property or
method, and therefore can't have focus in the that sense.

Mouse wheel scrolling and DOM element focus have no direct relationship.
There is no W3 standard that defines what the document's response
should be to any mouse-scroll event.

Browser developers are therefore left to their own devices as to how to
interpret mouse-scrolling, which is no doubt responsible for the fact
that the response of various browsers to mouse-wheel events is inconsistent.
That's all that link does.

Sounds like Mozilla doesn't offer a way to activate the object (your
DIV), but due to its capability of setting focus to *hyperlinks* you get
the result you see.

I'd consider this bad UI design.
IE needs the suggested A element in order to provide keyboard navigation
of a scrolling div too. No doubt you also consider that bad UI design.
The
mousewheel works perfectly in IE without the link. It scrolls the div
even if there is a scrollbar on the page.

I presume you mean you can set focus to the DIV somehow, even when it
doesn't contain a hyperlink? I can't imagine it 'just works' - then how
would IE know when to scroll the viewport and when a child?

The OP means that in IE if you put the cursor over the div then it
scrolls (if it can) in response to mouse wheel scrolling, not the page.
You can't 'set focus' on a div.

IE 'knows' when to scroll because it has been programmed to provide
certain behaviour. If the cursor is over the page, the page is
scrolled. If a scrollable div is below the cursor, the div is scrolled.
If it can't be scrolled in the direction indicated, the page is
scrolled if possible.

Now consider a keyboard user, for them your scrolling thingy is also a
nightmare to use. Which is why creating any scrollable viewport within
the main viewport is considered a usability no-no.

I don't see the logic there. It's up to the browser vendor to ensure the
user can access whatever object he may want/need to access in whatever
way the user might want that.

And it's up to developers to present usable pages. Developers should
not depend on non-standard, browser-dependent behaviour to allow access
to content.

I don't see specific browsers' limitations as a reason to 'dumb down' a
site (which would mean dumbing it down for everybody, including those
who use a more powerful browser).

So dysfunctional pages that prevent access to parts of their content for
certain users are OK? Those users being ones dependent on keyboard or
other non-pointing-device navigation.

I think you are out of step with one of the fundamental tenets of web
design. Restricting accessibility for no good reason is, in some
jurisdictions,i n breach of laws regarding accessibility.
--
Rob

Once upon a time *Spartanicus* wrote:

Arne <in*****@domain .invalid> wrote:

I would like to use the scrolling on sites where they use
the scrolling div's.

If that is the case then the question belongs in a group specific to
your browser, not a group devoted to www authoring such as this.

Did that, but no response so far. I'll guess they know Mozilla but
maybe not to much CSS? :)

--
/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.

Once upon a time *Sander Tekelenburg* wrote:

In article
<ke************ *************** *****@news.spar tanicus.utvinte rnet.ie>,
Spartanicus <in*****@invali d.invalid> wrote:

Arne <in*****@domain .invalid> wrote:

>During testing <div style="overflow :auto;"> in CSS I noticed the
>mousewheel would work in Mozilla only after I made a <a href="#">some
>text</a> link and clicked on that, within the div.
>
>It appears as if Mozilla needs to have the focus set on that div in
>order for the mousewheel to work.
Makes sense, doesn't it? I think every GUI I ever used required focus on
an object before that object can be manipulated.

True of course. :)
The question is why moving the cursor on the object don't set the
focus, as in IE.

> That's all that link does.
Sounds like Mozilla doesn't offer a way to activate the object (your
DIV), but due to its capability of setting focus to *hyperlinks* you get
the result you see.

I'd consider this bad UI design.
> The
>mousewheel works perfectly in IE without the link. It scrolls the div
>even if there is a scrollbar on the page.

I presume you mean you can set focus to the DIV somehow, even when it
doesn't contain a hyperlink? I can't imagine it 'just works' - then how
would IE know when to scroll the viewport and when a child?

With IE the focus is set just by moving the cursor to the div, no
clicking needed. As long as there is scrollable content in the div the
focus stays, then the viewport is scrolled if there is a scrollbar for
the viewport.

It seams that with IR the 'point' is where you have the cursor when
you start scrolling. With the link in the div it works in IE for
keyboard users also, but not in Mozilla even if the focus is moved to
the link with keys.

--
/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.

In article <0u************ **@news.optus.n et.au>,
RobG <rg***@iinet.ne t.auau> wrote:

Sander Tekelenburg wrote:
[...]

I think every GUI I ever used required focus on
an object before that object can be manipulated.

Your use of 'focus' is out of context - the OP was using focus in the
sense of DOM elements. A DIV element does not have a focus property or
method, and therefore can't have focus in the that sense.

Yes, I considered writing "focus/select/activate" but didn't because I
thought it was obvious enough what I meant :)

But I don't see how the DOM is even relevant. If a browser presents
something within a scrollable area, it should offer the user useful
methods to interact with that. I think that's all there is to it.

[...]
There is no W3 standard that defines what the document's response
should be to any mouse-scroll event.
I don't see why there should be. W3C is no UI implementation authority
(although here and there in theor specs they point out some obvious UI
things).
Browser developers are therefore left to their own devices as to how to
interpret mouse-scrolling, which is no doubt responsible for the fact
that the response of various browsers to mouse-wheel events is inconsistent.
Indeed.

[...]
IE needs the suggested A element in order to provide keyboard navigation
of a scrolling div too. No doubt you also consider that bad UI design.
Yep.

[...]

I don't see the logic there. It's up to the browser vendor to ensure the
user can access whatever object he may want/need to access in whatever
way the user might want that.

And it's up to developers to present usable pages. Developers should
not depend on non-standard, browser-dependent behaviour to allow access
to content.

I couldn't agree more, but I don't see how it applies to this case.
Webpages should be HTTP- and HTML-dependant only. But if a browser
decides to accept a suggestion to render something with a scrollbar, it
should provide the user with a good mechanism to interact with that. If
it does not, it shouldn't have honoured that presentational suggestion
in the first place. The only way in which this affects "liquid design",
is that as an author you should anticipate that a browser might not
honour your suggestion to present something scrollable. Design things so
that in that case the usability/accessibility of the page doesn't
seriously degrade.

I don't see specific browsers' limitations as a reason to 'dumb down' a
site (which would mean dumbing it down for everybody, including those
who use a more powerful browser).

So dysfunctional pages that prevent access to parts of their content for
certain users are OK?

Show me how it is the page that prevents access. As far as I can see it
is the browser.
Those users being ones dependent on keyboard or
other non-pointing-device navigation.
I know. Are they dependant upon Microsoft or Mozilla too? Can't they
pick a browsing environment that *does* work well? If it doesn't exist,
can't they develop one, or pay for having one developed? Why should we
sit on our hands waiting for non-inventive companies to move the Web to
maturity?
I think you are out of step with one of the fundamental tenets of web
design.
The only thing this has to do with webdesign is that with Web publishers
dumbing pages down to avoid bugs/lousy behaviour in browsers, thus
hiding how sad the quality of most browsers is, they're contributing to
browsers, and thus the Web, to remain as infantile as it is. If on the
other hand Web publishers would just go ahead and make use of what the
HTML and CSS standards have to offer, most browsers' problems would be
visible to everyone - browser developers would feel much more pressure
to start producing quality. (Would make the Web cheaper too, as Web
publishers wouldn't have to waste time tracking and avoiding other
developer's bugs.)

F'r instance: if Web publishers would use the LINK element en masse,
there wouldn't be a need anymore to copy the same functionality to the
BODY. By not using it, there is little incentive for browser developers
to 'waste' resources on such a thing.
Restricting accessibility for no good reason is, in some
jurisdictions,i n breach of laws regarding accessibility.

A law that allows convicting one person for another's mistakes, assuming
such a law exists, is a bug.

--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>