473,597 Members | 2,113 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Setting focus on div with Mozilla

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.

Is there any reason (according to standard or something else) why
Mozilla can't scroll without setting the focus, and is there any other
way to do it.

--
/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.
Jul 21 '05 #1
20 12288
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
Jul 21 '05 #2
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.
Jul 21 '05 #3
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
Jul 21 '05 #4
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
Jul 21 '05 #5
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/>
Jul 21 '05 #6
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
Jul 21 '05 #7
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.
Jul 21 '05 #8
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.
Jul 21 '05 #9
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/>
Jul 21 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
8710
by: Guus Ellenkamp | last post by:
I want to use a second window to link to and put new content in it and pop up is some link is clicked. How to set the focus to the second window if it's already open. With what I do now, the window stays below my main window.
4
2390
by: Scott Navarre | last post by:
Hi, I have Red Hat 8.0 and have the default Mozilla browser that comes with it. I am programming in javascript and have come across something problematic. Given the following code: <HTML> <HEAD> </HEAD> <BODY> <FORM>
7
9932
by: Phl | last post by:
hi, I can use the following code to set focus to standard html elements but if I try to do the same for a custom element, it seems to complain that it does not support a focus method. Does anyone know what is the problem, if there is a work around? thank you
6
5012
by: Geoff | last post by:
When trying to focus a field in Firefox, I get the following error: Error: " nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: file:///C:/Documents%20and%20Settings/Edd/Desktop/test.html :: valText :: line 24" data: no] Source File: file:///C:/Documents%20and%20Settings/Edd/Desktop/test.html Line: 24 Anyone have any ideas as to why this is happening?
31
2828
by: Benno Bös | last post by:
If I use the following construct in the frame "main" for a link to an extern site: <A HREF="http://www.any.xy" TARGET="extern"> the Browser is creating the window "extern", loading the page www.any.xy an setting the focus to "extern". But when I go return to "main" without closing "extern", a click to an other link (e.g. www.2nd_any.xy) on "main" does not setting the focus to "extern".
2
3087
by: Peter Wright | last post by:
Hi all. Hopefully this should demonstrate the problem I'm having: http://flooble.net/~pete/focus-problem-demo/ (I'm testing it in Mozilla only, but I'm not sure if it's actually a Mozilla-only problem) I'm capturing the focus and blur events for the document, updating a
6
2021
by: joe | last post by:
Hi Everyone, could anyone comment on the following problem: I have a textbox being appended to a cell in a table, and am trying to call focus() on like this: <snip> c01.removeChild(answerbox); answerbox=document.createElement('input'); answerbox.addEventListener("change",check_answer,false); answerbox.style.fontSize=FONTSIZE; answerbox.style.backgroundColor=COLOR_ANSWBG;
4
3593
by: Csaba Gabor | last post by:
Up until a few weeks ago, javascript code like window.open("http://mydomain.com", "windowName"); would always bring my new or reused window to the top, with focus. Lately, Firefox (Deer park alpha 2) only brings it to the top if the window is new. If it's being reused, the window does not come to the foreground (with IE 6 it does). Is there a new way in Mozilla/Firefox that I can ensure that this
3
1656
by: register_allocation | last post by:
I have a frameset where I call a JavaScript function in the onLoad method: .... <frameset cols="..." onLoad="setFn()"> ... <frame name="data_frame" ...> </frameset> In setFn, I am dynamically loading the contents of the 'data_frame', which works fine. I then want to set focus to the 'data_frame':
0
8272
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
8035
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
8258
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
5847
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5431
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
3886
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
3927
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2404
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
0
1238
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.