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. 20  12266 
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
In article
<ke********************************@news.spartanic us.utvinternet.ie>,
Spartanicus <in*****@invalid.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.spartanic us.utvinternet.ie>,
Spartanicus <in*****@invalid.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,in 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.spartanic us.utvinternet.ie>,
Spartanicus <in*****@invalid.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 <3k************@individual.net>,
Arne <in*****@domain.invalid> wrote:
[...] The question is why moving the cursor on the object don't set the
focus, as in IE.
If you care, ask the Mozilla developers for such a feature. (And say
"hover over the object", so they'll understand what you mean ;))
[...]
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.
Ah, I see. I hadn't understood that earlier.
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.
I see. Sounds like it might be a useful implementation.
[...] With the link in the div it works in IE for
keyboard users also
How? How do you set that focus with the keyboard in IE?
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
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? :)
Whether or not you can use divs with a scrollbar in Mozilla has got
nothing to do with CSS.
--
Spartanicus
In article <0u**************@news.optus.net.au>,
RobG <rg***@iinet.net.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,in 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/>
Sander Tekelenburg wrote:
[...] 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.
I see. Sounds like it might be a useful implementation.
[...] With the link in the div it works in IE for
keyboard users also
How? How do you set that focus with the keyboard in IE?
In most browsers, pressing the 'tab' key will move between UI features
that can have focus (including the address bar or location field).
If a scrolling div contains an element that can have focus (A, INPUT,
BUTTON, LABEL etc.) then after a suitable number of 'tab' presses the
focus moves to those elements in turn.
The order in which elements are visited can be controlled using the
'tabindex' attribute.
<URL:http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex>
Once one of them has focus, the up/down arrow keys can be used to
scroll the div. If the scrolling does not contain any elements that
can have focus, it can't be scrolled with the keyboard.
The above behaviour occurs in Mozilla and IE.
--
Rob
Once upon a time *RobG* wrote: Sander Tekelenburg wrote:
[...]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.
I see. Sounds like it might be a useful implementation.
[...] With the link in the div it works in IE for
keyboard users also
How? How do you set that focus with the keyboard in IE?
In most browsers, pressing the 'tab' key will move between UI features
that can have focus (including the address bar or location field).
If a scrolling div contains an element that can have focus (A, INPUT,
BUTTON, LABEL etc.) then after a suitable number of 'tab' presses the
focus moves to those elements in turn.
The order in which elements are visited can be controlled using the
'tabindex' attribute.
<URL:http://www.w3.org/TR/html4/interact/forms.html#adef-tabindex>
Once one of them has focus, the up/down arrow keys can be used to
scroll the div. If the scrolling does not contain any elements that
can have focus, it can't be scrolled with the keyboard.
The above behaviour occurs in Mozilla and IE.
Not totaly the same in IE and Mozilla. When the link in the div is in
focus, it can be scrolled with both arrow keys and mouse. With Mozilla
I can't scroll the div with the keys, only with the mouse and that is
strange. Guess I have to take it to the Moz developers :)
--
/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.
Sander Tekelenburg wrote: In article <0u**************@news.optus.net.au>,
RobG <rg***@iinet.net.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 :)
Yes, 'activate' would likely have been a better word. X-Windows puts
'focus' on whichever window the cursor is over, even if it's in the
background - a feature I disliked. Keyboard input would often end up
in the wrong TTY session 'cos I'd move the cursor out of the way of
the 'current' window and accidentally give focus to a different window
& session.
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.
'The browser' doesn't design web pages, people do. If a person puts
content into an area that *no* browser provides keyboard navigation
to, then that is the person's fault, not the browsers'.
[...]
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",
OK, so you think browsers should not present scrolling divs.
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.
Precisely - the suggestion is don't use scrolling divs where
accessibility is important.
[...]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.
By expecting visitors to make use of features that browsers don't
provide, such as the ability to scroll a scrolling div using keyboard
navigation only.
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?
In the context of a special interest or intranet site, go for it. But
it's worth noting accessibility requirements for those sites where
public access is a requirement.
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
It's not a bug, the browsers work as designed and conform to the
relevant standards. The point on behaviour is moot - browser
developers have had great pressure exerted on them to follow
standards, they can hardly be taken to task for doing so.
If you don't like the standard, approach W3.org.
[...]
--
Rob
RobG wrote:
The order in which elements are visited can be controlled using the
'tabindex' attribute.
tabindex--ish. Tabindex might have been a good idea way back when WCAG
1.0 was written, but it sucks in practice. Please don't use it.
If the scrolling does not contain any elements that
can have focus, it can't be scrolled with the keyboard.
With a gecko browser, using type-ahead-find for any text, not just
links, usually works quite nicely. I'm a keyboard user, and couldn't
live without that feature. Kludges like tabindex are nowhere near as
good, and can actually impede keyboard navigation because they interfere
with browser features like type-ahead-find.
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
On Mon, 18 Jul 2005, kchayka wrote: RobG wrote:
The order in which elements are visited can be controlled using the
'tabindex' attribute.
tabindex--ish. Tabindex might have been a good idea way back when WCAG
1.0 was written, but it sucks in practice. Please don't use it.
Any views on tabindex=0 ?
Does it have any benefits (other than shutting-up an accessibility
checker), e.g does it actually mark an element at tab-able which
otherwise would not have been ?
Does it have any known disadvantages? (e.g your issue with type-ahead
find?).
thanks
Alan J. Flavell wrote: Any views on tabindex=0 ?
Does it have any benefits (other than shutting-up an accessibility
checker),
<g>
Of course, shutting up an accessibility checker is no reason to use
tabindex, or any other particular markup.
e.g does it actually mark an element at tab-able which
otherwise would not have been ?
Tab behavior and tabindex are browser-dependent to begin with. Many
browsers only tab to form fields, so tabindex on other elements will
likely just be ignored anyway. In a brief test I did, IE stopped on
heading elements with a tabindex, but mozilla did not, though Firefox
could have different behavior. IE and gecko are the only 2 browsers I
know of that will tab to elements other than form fields.
Does it have any known disadvantages?
In the mozilla build I tested, it has the same effect as not using
tabindex at all, at least as far as tab order goes. So it appears there
is neither an advantage nor a disadvantage to tabindex=0.
Sounds like unnecessary cruft to me. :)
However, I'd be interested how the current wave of popular screen
readers handle keyboard navigation with tabindex, since most use IE's
rendering engine. I believe JAWS does support tabindex, but I don't know
how it handles situations like navigating by headings mixed with
tabbing, when tabindex is defined. I don't even know if other readers
support tabindex at all.
Regardless, this is off-topic for ciaws, isn't it?
--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.
On Mon, 18 Jul 2005, kchayka wrote: Alan J. Flavell wrote:
Any views on tabindex=0 ?
Does it have any benefits (other than shutting-up an accessibility
checker),
<g>
Of course, shutting up an accessibility checker is no reason to use
tabindex, or any other particular markup.
Sure, point taken (although alt="" can also shut up an accessibility
checker - in some situations it's the right move for better reasons).
[...]
Regardless, this is off-topic for ciaws, isn't it?
Yes - I plead thread drift, and couldn't resist asking.
thanks for the comments.
In article
<42**********************@per-qv1-newsreader-01.iinet.net.au>,
RobG <rg***@iinet.net.auau> wrote: Sander Tekelenburg wrote:
[...]
[scrolling DIVs]
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.
'The browser' doesn't design web pages, people do. If a person puts
content into an area that *no* browser provides keyboard navigation
to, then that is the person's fault, not the browsers'.
A person cannot put content into a scrollable DIV. They can put it in a
DIV, and they can *suggest* the browser makes it scrollable. The browser
shouldn't honour that suggestion if the result creates a problem for the
user.
This is no different from suggesting colours. The result of a colour may
be that someone has trouble interacting with the content. So the browser
should only honour the suggestion if it does not screw up usability for
the user. For example, by allowing the user to override the
author-suggested CSS colour(s).
[...]
OK, so you think browsers should not present scrolling divs.
That's not what I said. I'm saying *if* a browser presents a DIV with
scrollbars, it should ensure the user can interact comfortably with it.
Else, it should simply not honour the author suggestion to make the DIV
scrollable.
No CSS author needs to consider that. A CSS author knows that all he can
do is make suggestions anyway. He knows some or all won't be honored.
When you suggest P {max-width: 60ex}, you know most browser will ignore
it, their users ending up with unpractical long lines. It is *not* the
author's job to then instead dumb things down to use fixed widths, or
even table abuse. It's the user's responsibility to either get a betyter
browser, or put pressure on browser developers to come up witha product
that is useable. (Which might mean the user will have to be willing to
pay. So what? TANSTAAFL.)
There are plenty such examples in HTML and CSS. Most browsers today,
even those that are supposedly so greatly standards-compliant still
ignore lots of HTML. (Example: just today I found that only 1 browser
that does something useful with the cite attribute to q and blockquote.
And it wasn't IE, Mozilla, Opera or Safari. So is the solution for
millions of web designers to not use the cite attribute, or for the 20
or so browser developers to get off their lazy ass?)
[...]
It's not a bug, the browsers work as designed
Indeed. Just not very *well* designed :) UI-wise.
and conform to the relevant standards.
There are no relevant standards concerning browser UIs. the CSS standard
hardly touches upon it, partly because every browser environment is
different and what solution makes sense in one environment might not
even be an option in another.
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
In article
<42**********************@per-qv1-newsreader-01.iinet.net.au>,
RobG <rg***@iinet.net.auau> wrote: Sander Tekelenburg wrote:
[...]
How? How do you set that focus with the keyboard in IE?
In most browsers, pressing the 'tab' key will move between UI features
that can have focus (including the address bar or location field).
Right. My favourite browser also allows tabbing through frames, to
activate them and then be able to scroll them. No keyboard required. IMO
it should do the same with other scrollable objects. (It does not. The
author reads this group. Hopefully he'll pick up this suggestion ;))
If a scrolling div contains an element that can have focus (A, INPUT,
BUTTON, LABEL etc.) [...]
Once one of them has focus, the up/down arrow keys can be used to
scroll the div. If the scrolling does not contain any elements that
can have focus, it can't be scrolled with the keyboard.
A Webpage that consists of only text can still be scrolled with the
keyboard in most browsers. And most browsers would allow tabbing to
alternate between activating the content area and the URL field. Nothing
to do with HTML specs, everything with UI design.
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
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...
|
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>...
|
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...
|
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 ::...
|
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...
| | |
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...
|
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);...
|
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...
|
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...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
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,...
|
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...
|
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...
|
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...
|
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...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
