Re: [WSG] a quick target question
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 should be
doing anyway: separate out the behavioral layer. A very good source is
/Unobtrusive JavaScript
/(http://www.onlinetools.org/articles/unobtrusivejavascript/).
Bobby *DOES NOT* examine external JavaScript files, so it will be none
the wiser. If you think it might be cheating, think again; you're just
protecting it from it's own (well documented) flaws.
Here's your anchor: a href=wharever.com class=popupWhatever.com/a
In an EXTERNAL JavaScript file have:
function addLoadEvent(func) {
var oldOnload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
oldOnload();
func();
}
}
}
function getElementsByClassName(className, node){
node = node||document; // Defaults to document object if no node is
given.
var all = node.all||node.getElementsByTagName('*');
var arr = new Array();
for(var i=0; iall.length; i++){
if(all[i].className == className){
arr[arr.length] = all[i];
}
}
return arr;
}
function addPopUps () {
var i;
var popups = getElementsByClassName(popup);
for (i=0; ipopups.length;i++) {
popups[i].onclick = function (){window.open(this.href);return
false;};
}
}
if (document.getElementByTagName) {
addLoadEvent(addPopUps);
}
Note:* Much of the above I originally adapted from various sources.
While I haven't tested addPopUps, I adapted it from working code I've
written. Also, if needed, getElementsByClassName can be easily adapted
to handle tags with multiple class names by using a regular expression.
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] a quick target question
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 http://www.csatravelprotection.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** . ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 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 http://www.csatravelprotection.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.805 / Virus Database: 547 - Release Date: 12/3/2004 Veine K Vikberg http://www.vikberg.net Professional Web Guru
Re: [WSG] a quick target question
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 to TAB beyond that particular link. Onclick is, despite its name, device independent, as the vast majority of browsers (I'm actually compiling a list which I'll publish later tonight) trigger the event via the keyboard as well (in the case of a link, hitting enter will trigger the onclick) -- Patrick H. Lauke _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] a quick target question
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 Message- From: Veine K Vikberg [mailto:[EMAIL PROTECTED] 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 statement that opens it in a new window. I'm sure others could use it as well. Thank you ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 handler could examine the key value and allow TAB to pass through untrapped? I'm not one to advocate unnecessarily complicated code when a simpler method is close at hand, but 'impossible' is a strong assertion. Regards, Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] a quick target question
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 onkeypress=window.open(this.href); return false; onclick=window.open(this.href); return false;Whatever.com/a The keyword 'this' refers to the object at hand: in this context, this refers to the a element in the Document Object Model. You can find an excellent introduction to scripting events on Peter-Paul Koch's http://www.quirksmode.org/ 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 or any of the functions used in the script will throw an untrappable error. Better to apply behavior to objects on the page from a safe distance whereby nothing occurs when the script is unsupported. The most common way to do this is to engage an initialization script with the window.onload event which checks specifically for support before adding behavior to objects on the page. 2) Separating content (HTML markup) from behavior (script) from style (CSS) is A Good Thing because modular software is easier to maintain, and because old, cranky, or idiosyncratic browsers can more easily be protected from components they don't support. I would therefore mark up that tag (uniquely identified so a script can find it easily) simply as: a id=unique123 href=whatever.comWhatever.com/a or: div id=unique123 a href=whatever.comWhatever.com/a /div and apply the behaviors separately from a linked script. Regards, Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 onclick=window.open(...);return falsepopup/a This is so older browsers, and search engines, can follow popup links, but newer browsers that use the onclick ignore the href because of onclick's 'return false'. See http://www.alistapart.com/articles/popuplinks/ .Matthew Cruickshank http://holloway.co.nz/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 This is so older browsers, and search engines, can follow popup links, but newer browsers that use the onclick ignore the href because of onclick's 'return false'. -- You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away. -Antoine de Saint-Exupery ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 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 onclick=window.open(...);return falsepopup/a This is so older browsers, and search engines, can follow popup links, but newer browsers that use the onclick ignore the href because of onclick's 'return false'. See http://www.alistapart.com/articles/popuplinks/ .Matthew Cruickshank http://holloway.co.nz/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- Chris Stratford [EMAIL PROTECTED] http://www.neester.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 onkeypress makes it impossible for users to TAB beyond that particular link. Onclick is, despite its name, device independent, as the vast majority of browsers (I'm actually compiling a list which I'll publish later tonight) trigger the event via the keyboard as well (in the case of a link, hitting enter will trigger the onclick) 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; The above mentioned code is the HTML 4.x target=new in a newer fashion, where the new window is launched by passing the href attribute to the window open object's method. The return false is returned from the event handler. If Java script is enabled the false returned is prohibited from being processed and the Java script event handler does it's task. Now in the event of Java script turned off, the link is a 'normal' href link, which will be carried out by the browser, and the user can visit that link, however in the same window as they were in (not opening in a new window). It's basically a catch-all scripting to be as accessible as possible. Since my prime concern with most of the web sites I build is accessibility this is the script that will work for most occations, and this code is not platform/device dependent. The reasoning is to provide onclick for mouse users and onkeypress for using a keyboard. I do this to make sure that the most users can access the pages I build (my target is supporting down to NS/IE 4.x) *IF* there was a way of completely not using Java script I would go with that, but there is no way around the issue as I have found, since the latest statistics I saw on the Java script subject was that 20-25% has it turned off in their browser, and that Flash is now ahead in usage. That maybe be all good and well, however the usage of Flash makes the accessibility issues larger (however can be solved) but few wants to pay the difference in development cost. HTH, Regards ~Veine Veine K Vikberg http://www.vikberg.net Professional Web Guru
RE: [WSG] a quick target question
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 or any of the functions used in the script will throw an untrappable error. Better to apply behavior to objects on the page from a safe distance whereby nothing occurs when the script is unsupported. The most common way to do this is to engage an initialization script with the window.onload event which checks specifically for support before adding behavior to objects on the page. 2) Separating content (HTML markup) from behavior (script) from style (CSS) is A Good Thing because modular software is easier to maintain, and because old, cranky, or idiosyncratic browsers can more easily be protected from components they don't support. I would therefore mark up that tag (uniquely identified so a script can find it easily) simply as: a id=unique123 href=whatever.comWhatever.com/a or: div id=unique123 a href=whatever.comWhatever.com/a /div and apply the behaviors separately from a linked script. Paul; Interesting solution you have come up with here, however, thinking validation versus functionality here, this is the same idea of a 'catch-all' handling, however, I am not sure that your script linked to this can give both on-click and on key press to the user can it? If so I would love to see an example of your code, or even better in a working page somewhere :) Regards ~Veine Veine K Vikberg http://www.vikberg.net Professional Web Guru
Re: [WSG] a quick target question
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 have seen, however since it's not endorsed by W3C to be included in Strict I think there is a reasoning for that: http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_targetmodule Basically if I recall correctly, the Strict version of any HTML DTD has ever had the target attribute included (forgive me if I am wrong but I started to build in HTML 2.x and my memory of such times are fading), the only two DTD's that are allowing it is XHTML Frameset and Transitional, and if all other fails the fall back id to step back down on the DTD's. Regards ~Veine Veine K Vikberg http://www.vikberg.net Professional Web Guru
Re: [WSG] a quick target question
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/) ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 onkeypress, as it otherwise means users can't tab past your link. Onclick is triggered by the keyboard as well, so there's no need for a matching onkeypress. -- Patrick H. Lauke _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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: keep the onclick, but ditch the onkeypress, as it otherwise means users can't tab past your link. Onclick is triggered by the keyboard as well, so there's no need for a matching onkeypress. I know that keyboard users with Mozilla will get stuck at the link, I did not miss that point, and I think that is an issue that Mozilla needs to address shortly, since it's non compliant behavior. I am following W3C guidelines for XHTML validation, and I follow WAI Content Accessibility Guidelines 1999/05/05, Support Level: AAA ( http://www.w3.org/TR/WAI-WEBCONTENT/ ) For the XHTML there is no need to put in redundant code, the code will validate with either the onclick or the onkeypress, or both used redundantly as my example was, 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. 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: onclick with onkeypress onmouseup with onkeyup onmousedown with onkeydown onmouseover with onfocus onmouseout with onblur These event handlers responds to what the user does, weather it is key press, mouse clicks, voice activated etc. Most of these event handlers are only for eye candy, or to get a users attention, but onclick/onkeypress is a part of the functionality of the page and must be presented device independent to achieve even AA WAI standards. This is the reference to WAI standards for the above; http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/#tech-device-independent-events These are the guidelines I follow, and I have the hopes that the browser market would start to adhere to (or at least attempt to) the standards, I know .. I know... it's Utopia, but what can one do? Regards ~Veine Veine K Vikberg http://www.vikberg.net Professional Web Guru
Re: [WSG] a quick target question
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 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 refer to WAI as unforgiving and leaving you no choice. Of course, accessibility is not the rote mastery of a set of guidelines, but also involves a level of judgement. Thanks for the long and exhaustive rundown of what WAI is, what event handlers are etc...but I think you'll find that I am quite well versed in the subject matter. One thing to note: even people at the W3C agree that onclick is effectively a misnomer of what should really have been called onactivation. There *is* no device independent equivalent: onkeypress is just as device dependent, if not more, as onclick - however, onclick is de-facto triggered by a variety of devices, not just mouse buttons. Do a search around the subject of whether or not onclick is to be considered device dependent or device independent, and you'll find that modern thinking on the issue is that onclick *is* device independent. Even on the actual WAI IG list, the subject seems almost unworthy of a prolonged discussion http://lists.w3.org/Archives/Public/w3c-wai-ig/2004JanMar/0512.html These are the guidelines I follow, and I have the hopes that the browser market would start to adhere to (or at least attempt to) the standards, The standard have holes in them. For true device independence, truly independent handlers such as (fpr lack of appropriate terminology) onactivation for onkeypress, and something like onactivatortriggererd for onmousedown/keydown or onactivatorreleased for onmouseup/keyup would be needed. Currently, even some of the doubled up event triggers only seem to cover mouse and key/switch activation, and don't cover things like voice...but I digress. But I'm happy to respect that you follow the guidelines, but I must point out that it's not as cut and dry as you may think. -- Patrick H. Lauke _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] a quick target question
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 refer to WAI as unforgiving and leaving you no choice. Of course, accessibility is not the rote mastery of a set of guidelines, but also involves a level of judgement. 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 unforgiving. (I am in the US btw, and governmental bodies here needs to see that the pages are validating with Watchfire tools) Thanks for the long and exhaustive rundown of what WAI is, what event handlers are etc...but I think you'll find that I am quite well versed in the subject matter. One thing to note: even people at the W3C agree that onclick is effectively a misnomer of what should really have been called onactivation. There *is* no device independent equivalent: onkeypress is just as device dependent, if not more, as onclick - however, onclick is de-facto triggered by a variety of devices, not just mouse buttons. Do a search around the subject of whether or not onclick is to be considered device dependent or device independent, and you'll find that modern thinking on the issue is that onclick *is* device independent. Even on the actual WAI IG list, the subject seems almost unworthy of a prolonged discussion http://lists.w3.org/Archives/Public/w3c-wai-ig/2004JanMar/0512.html Well, from what my tired brain can read, you are saying that there is no device independent equivalent, so that is why WAI validators ask for the redundancy? I couldn't agree more with the people at W3C here, that it is in fact as misnomer, but then why hasn't it been picked up by WAI I wonder? These are the guidelines I follow, and I have the hopes that the browser market would start to adhere to (or at least attempt to) the standards, The standard have holes in them. For true device independence, truly independent handlers such as (fpr lack of appropriate terminology) onactivation for onkeypress, and something like onactivatortriggererd for onmousedown/keydown or onactivatorreleased for onmouseup/keyup would be needed. Currently, even some of the doubled up event triggers only seem to cover mouse and key/switch activation, and don't cover things like voice...but I digress. Agreed that it's like a Swiss cheese at points, and pretty solid at others, however it's the best we have to work with at the present time, and as the regulations for some governmental sites here in the US are to at least fulfill WAI AA, if not AAA, I see no other choice for me to continue to use both, even though I would rather not, since the validator crave it because it's in the WAI standards. But I'm happy to respect that you follow the guidelines, but I must point out that it's not as cut and dry as you may think. No, indeed it isn't I'm afraid. If I could only convince people in decision making positions I would stop using it in a heartbeat Regards ~Veine Veine K Vikberg http://www.vikberg.net Professional Web Guru
Re: [WSG] a quick target question
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 unforgiving. 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). Well, from what my tired brain can read, you are saying that there is no device independent equivalent, so that is why WAI validators ask for the redundancy? I couldn't agree more with the people at W3C here, that it is in fact as misnomer, but then why hasn't it been picked up by WAI I wonder? Because WAI are not the ones working on the (X)HTML standard. In XHTML 2.0 it will come down to the specific implementation of device independent DOM User Interface Events http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html (in this case, DOMActivate), so there's hope... If I could only convince people in decision making positions I would stop using it in a heartbeat Unfortunately dumb mechanical validators like Bobby (checking against outdated guidelines) have done more harm than good in this respect. I too hope that decision makers will see that accessibility is often a continuum, rather than simply a list of checkpoints that need to be fulfilled blindly (no pun intended) -- Patrick H. Lauke _ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
