Patrick H. Lauke wrote: Veine K Vikberg wrote:
So it's not WAI that's unforgiving, but Bobby in its miopic
application of the guidelines (which are, at this stage, already quite
out of date in many areas such as the one discussed here).
There is really a quite simple solution, which is what you
use window.open .
Ted Drake wrote:
Could someone give me the appropriate replacement for target=_blank. I can't
remember the correct javascript statement that opens it in a new window.
I'm sure others could use it as well.
Thank you
Ted Drake
Web Content Editor
CSA Travel Protection
a href=wharever.com onkeypress=window.open(this.href); return false;
onclick=window.open(this.href); return false;Whatever.com/a
HTH
~Veine
At 09:28 AM 12/6/2004 -0800, you wrote:
Could someone give me the appropriate replacement for target=_blank. I
can't remember the correct javascript
Veine K Vikberg wrote:
a href=wharever.com onkeypress=window.open(this.href); return
false; onclick=window.open(this.href); return false;Whatever.com/a
*Don't* use onkeypress, as Mozilla browsers - and rightly so - treat a
TAB as
a keypress as well. Using onkeypress makes it impossible for users
I'm a bit confused by the (this.href) code. Should I replace that with the page
in the href= section or is it looking back at the href and use that url?
I understand the repetition for keypress/onclick are for those without a mouse
and those with a mouse. n'est-ce pas?
Ted
-Original
At 10:03 AM 12/6/04, Patrick H. Lauke wrote:
*Don't* use onkeypress, as Mozilla browsers - and rightly so - treat a TAB as
a keypress as well. Using onkeypress makes it impossible for users to TAB
beyond
that particular link.
Isn't it true that, if one did use onkeypress, the attached event
At 10:11 AM 12/6/04, Ted Drake wrote:
I'm a bit confused by the (this.href) code. Should I replace that with the
page in the href= section or is it looking back at the href and use that url?
-Original Message-
From: Veine K Vikberg [mailto:[EMAIL PROTECTED]
a href=wharever.com
Ted Drake wrote:
Could someone give me the appropriate replacement for target=_blank. I can't
remember the correct javascript statement that opens it in a new window.
I'm sure others could use it as well.
Rather than a replacement it's best to include both,
a href=popup.html target=_blank
unless, of course, you are using a DTD that doesn't include
target=_blank, such as XHTML 1.0 strict or XHTML 1.0.
On 2004-12-07 8:07 AM, Matthew Cruickshank wrote:
Rather than a replacement it's best to include both,
a href=popup.html target=_blank onclick=window.open(...);return
falsepopup/a
Just use target=_blank and use my DTD which is modified to allow the
target=_blank
!DOCTYPE html PUBLIC XHTML 1.01 Strict
http://www.neester.com/DTD/xhtml-target.dtd;
Matthew Cruickshank wrote:
Ted Drake wrote:
Could someone give me the appropriate replacement for
target=_blank. I can't
At 06:03 PM 12/6/2004 +, you wrote:
Veine K Vikberg wrote:
a href=wharever.com onkeypress=window.open(this.href); return false;
onclick=window.open(this.href); return false;Whatever.com/a
*Don't* use onkeypress, as Mozilla browsers - and rightly so - treat a TAB as
a keypress as well. Using
At 10:59 AM 12/6/2004 -0800, you wrote:
Aside, while it may be convenient to embed javascript in HTML tags by way
of illustration, let me reiterate the oft-made point that doing so in
practice is a mistake, for at least these two reasons:
1) User agents that don't support the scripting language
At 07:51 AM 12/7/2004 +1100, you wrote:
Just use target=_blank and use my DTD which is modified to allow the
target=_blank
!DOCTYPE html PUBLIC XHTML 1.01 Strict
http://www.neester.com/DTD/xhtml-target.dtd;
One of the more resourceful ways of getting around the problem with
target=new that I
Paul Novitski wrote:
You can find an excellent introduction to scripting events on
Peter-Paul Koch's http://www.quirksmode.org/
Another excellant resource is Unobtrusive Javascript
(http://www.onlinetools.org/articles/unobtrusivejavascript/)
**
Veine K Vikberg wrote:
Well, my link was given for XHTML Strict, in where my solution is the
only way to both make sure it is to the greatest extent accessible as
well as validating the code.
Let me explain a little more;
You missed my point completely: keep the onclick, but ditch the
At 11:54 PM 12/6/2004 +, you wrote:
Veine K Vikberg wrote:
Well, my link was given for XHTML Strict, in where my solution is the
only way to both make sure it is to the greatest extent accessible as
well as validating the code.
Let me explain a little more;
You missed my point completely:
Veine K Vikberg wrote:
and if the goal was only XHTML compliance
I would agree with you to 100% on the issue of not using onkeypress for
the reason above.
I actually never mentioned anything about XHTML validation in my
original reply, but yes.
However, the WAI is not as forgiving and this is
At 02:28 AM 12/7/2004 +, you wrote:
However, the WAI is not as forgiving and this is a device-dependent
attribute, where redundant input methods are required for the same
element. There are five instances where WAI gives us no choice but to use
redundancy:
I find it interesting how you
Veine K Vikberg wrote:
If you try and validate anything towards the standards at Bobby (which
is the measurement my clients in the public sector uses) there is no way
you can get around the redundancy, if you only do onclick it gives you
an error at level 2, that is what I mean with
19 matches
Mail list logo
