Re: [WSG] IE's New JavaScript Blocking Feature
Derek Featherstone wrote: As for using onkeypress, if the validators (by which I assume you mean Bobby, et al) then, they need to get a clue. The automated tool is only there to help, not to be the final arbiter of what is and isn't accessible. Another solution is not to use in-line JavaScript. Unless they check external script files (which I don't think they do, but I could be wrong), they can't complain about what they don't know about. The truth is you should be separating your behavioral layer, anyway. For help with 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] IE's New JavaScript Blocking Feature
I may be missing something here but when WinXP SP2 was installed on all the PCs at work, all it seemed to block were (popup) windows that opened automatically (i.e. onLoad). A link that requires a click, such as: a href=http://google.com/; onclick=window.open(this.href, 'popupwindow','width=400,height=300,scrollbars=1,resizable=1'); return false;Google/a seems to work just fine. Jonathan Cooper Manager of Information / Website Art Gallery of New South Wales Sydney, Australia http://www.artgallery.nsw.gov.au [EMAIL PROTECTED] wrote on 27/11/2004 06:06:50 PM: Mark Harwood wrote: --- The best and only way i do pop-ups is href=http://google.com/; onclick=window.open(this.href, 'popupwindow', 'width=400,height=300,scrollbars,resizable');return false; this allows you to do whatever you like with the link and also makes it valid, right click-able and so forth.. --- Well I can see that it doesn't take long for the topics to 'off topic' in this list! :) As for the fix ... With the snippet of JavaScript that Mark supplied above, I still get the information bar and no JavaScript run unless you choose to allow it. This was the main problem and reason for the post actually. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Carriere Sent: Friday, November 26, 2004 12:37 PM To: Web Standards Group Subject: [WSG] IE's New JavaScript Blocking Feature I've got two questions but as they are different topics completely, I will separate them into two different threads. They kind of relate, but not enough, so here's the first one regarding IE's New JavaScript Blocking Feature: -- IE's new content blocking features are wreaking havoc on my methods and designs! For the longest time I've been using the included JavaScript w/ rel=external (http://www.sitepoint.com/article/standards-compliant-world) method to have links open up new browser windows while keeping the code valid. I know that I've got to use these methods to keep the code valid as standards compliance outlines that you shouldn't opening new content in different windows. BUT! With some of my applications, I'd like to have new windows open while keeping my code valid anyway. The extremely irritating this is, no IE has that lovely content blocker (added in with Service Pack 2) that cause the JavaScript to be blocked. Sure you can just tell it to include the content and off you go but for those that don't know any better, (and trust me, I to Tech Support for an ISP and there are a lot of people that don't know any better), it's a real pain and the chances that your pages will not be rendered properly are too high. Any thoughts? Ideas? Thanks -- LAWRENCE CARRIERE [EMAIL PROTECTED] www.lawrencecarriere.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 ** ** 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] IE's New JavaScript Blocking Feature
Mordechai Peller wrote: Another solution is not to use in-line JavaScript. Unless they check external script files (which I don't think they do, but I could be wrong) if your script attaches onclick behaviours on load via the DOM, i seriously doubt that bobby will pick this up. to do that, it would need to effectively run the javascript itself and then analyse the resulting DOM tree. so yes, that would be a good option (and agree about the separation, of course) 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] IE's New JavaScript Blocking Feature
The best and only way i do pop-ups is href=http://google.com/; onclick=window.open(this.href, 'popupwindow', 'width=400,height=300,scrollbars,resizable');return false; this allows you to do whatever you like with the link and also makes it valid, right click-able and so forth.. Remeber to put onKeypress too Mark Harwood -- Phunky.co.uk / Xhtmlandcss.co.uk / Zinkmedia.co.uk -- Currently looking for Freelance / Contract work ** 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] IE's New JavaScript Blocking Feature
On Friday, November 26, 2004 2:53 PM, Mark Harwood wrote: The best and only way i do pop-ups is href=http://google.com/; onclick=window.open(this.href, 'popupwindow', 'width=400,height=300,scrollbars,resizable');return false; this allows you to do whatever you like with the link and also makes it valid, right click-able and so forth.. Remeber to put onKeypress too Please, don't add onkeypress to this in the name of device independence... Onclick works just fine for keyboard users and for users that use alternative devices that emulate keyboard usage. If you add onkeypress you will quite possibly do more harm than good -- someone that uses a keyboard for navigation etc won't be able to go anywhere because the pop up will keep appearing. If I'm on that particular link myself, even pressing the tab key to move to the next link will cause the dialog to appear. Trying to open a new tab with Ctrl + T, or open my feedreader (Sage) with Ctrl + S will cause the popup to appear. It can actually become quite frustrating when onkeypress is used like this... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** 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] IE's New JavaScript Blocking Feature
Mark Harwood Remeber to put onKeypress too I'd disagree. I've had this rant before, but here goes: onclick is not a device specific handler. Onclick is also activated by the keyboard (e.g. hitting return when focus is on a link). It's a misnomer, and should really be onactivation or something. True, very old browsers may have only had onclick triggered by the mouse, but these are very rare. In addition, if somebody *was* using something like Netscape 4 and only using the keyboard, with this method they'd still get to the linked document, just that it won't pop up (as NN4.x is one of those that don't consider the keyboard to give off onclick events). So, accessibility wise, you're covered. Adding onkeypress can actually do more harm than good. Firefox (and I think Mozilla as well) *correctly* interpret *all* keys as onkeypress, even the TAB key. So, having something activate onkeypress will mean that keyboard users won't be able to tab beyond that particular link. 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] IE's New JavaScript Blocking Feature
OnActivation would proberly be better to use, only reason i state to use onKeyPress is that validators moan if u dont use it. But whatever way you activate the link, this is still the best way to get a pop up or a new page. On Fri, 26 Nov 2004 20:19 , Patrick H. Lauke [EMAIL PROTECTED] sent: Mark Harwood Remeber to put onKeypress too I'd disagree. I've had this rant before, but here goes: onclick is not a device specific handler. Onclick is also activated by the keyboard (e.g. hitting return when focus is on a link). It's a misnomer, and should really be onactivation or something. True, very old browsers may have only had onclick triggered by the mouse, but these are very rare. In addition, if somebody *was* using something like Netscape 4 and only using the keyboard, with this method they'd still get to the linked document, just that it won't pop up (as NN4.x is one of those that don't consider the keyboard to give off onclick events). So, accessibility wise, you're covered. Adding onkeypress can actually do more harm than good. Firefox (and I think Mozilla as well) *correctly* interpret *all* keys as onkeypress, even the TAB key. So, having something activate onkeypress will mean that keyboard users won't be able to tab beyond that particular link. 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 ** 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] IE's New JavaScript Blocking Feature
On Friday, November 26, 2004 3:57 PM, Mark Harwood wrote: OnActivation would proberly be better to use, only reason i state to use onKeyPress is that validators moan if u dont use it. That's the problem -- there is no onactivate, but that is what they probably should have called onclick though. As for using onkeypress, if the validators (by which I assume you mean Bobby, et al) then, they need to get a clue. The automated tool is only there to help, not to be the final arbiter of what is and isn't accessible. My vote: let the automated checkers moan about this all day. Ignore them. Don't add onkeypress in the name of accessibility and device independence... Best regards, Derek. -- Derek Featherstone [EMAIL PROTECTED] phone: 613.599.9784; toll-free: 1.866.932.4878 (North America) Web Development: http://www.furtherahead.com Web Accessibility: http://www.wats.ca Personal: http://www.boxofchocolates.ca ** 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] IE's New JavaScript Blocking Feature
On Fri, 26 Nov 2004 16:05 , Derek Featherstone [EMAIL PROTECTED] sent: My vote: let the automated checkers moan about this all day. Ignore them. Don't add onkeypress in the name of accessibility and device independence... Try telling that to SOCTiM who check all local council sites, they take the guidlines as if there written in stone! ** 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] IE's New JavaScript Blocking Feature
Think of onclick as a 2-action process: mouse down selects the object, mouse up - if still on-focus - activates the link, in this instance. Same for keyboard action: tab to object selects it, enter/return activates it. They do the same job, across all browsers. Tell you what, why not run a sequence of tests? Proof of pudding ... Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Harwood Sent: 26 November 2004 22:28 To: [EMAIL PROTECTED] Subject: RE: [WSG] IE's New JavaScript Blocking Feature On Fri, 26 Nov 2004 16:05 , Derek Featherstone [EMAIL PROTECTED] sent: My vote: let the automated checkers moan about this all day. Ignore them. Don't add onkeypress in the name of accessibility and device independence... Try telling that to SOCTiM who check all local council sites, they take the guidlines as if there written in stone! ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 24/11/04 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 24/11/04 ** 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] IE's New JavaScript Blocking Feature
Mike Pepper wrote: Think of onclick as a 2-action process: mouse down selects the object, mouse up - if still on-focus - activates the link, in this instance. Same for keyboard action: tab to object selects it, enter/return activates it. Oh, something just occurred to me: best make it explicit that we're talking about onclick behaviours on elements that receive focus via the keyboard (links, form elements). obviously, if you have applied onclick to something else (like a plain vanilla image, or a paragraph, etc), it won't be triggered by the keyboard because the user will not be able to even get to it. but that then becomes a more fundamental accessibility issue. Tell you what, why not run a sequence of tests? Proof of pudding ... I can knock something together this saturday and test in most recent-ish (from IE 4 onwards) browsers, if you like. Anybody who can test on Mac (ideally both OS 9 and OS X) and *nix (konqueror)? Send me a reply off list...I'll collate the results and re-post them here. Patrick -- _ 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] IE's New JavaScript Blocking Feature
Patrick wrote: Oh, something just occurred to me: best make it explicit that we're talking about onclick behaviours on elements that receive focus via the keyboard (links, form elements). obviously, if you have applied onclick to something else (like a plain vanilla image, or a paragraph, etc), it won't be triggered by the keyboard because the user will not be able to even get to it. but that then becomes a more fundamental accessibility issue. Good point ... which is why it's always good to have an image caption wrappered within the link to handle the onfocus/active event :o) I can knock something together this saturday and test in most recent-ish (from IE 4 onwards) browsers, if you like. Anybody who can test on Mac (ideally both OS 9 and OS X) and *nix (konqueror)? Send me a reply off list...I'll collate the results and re-post them here. Well done, mate. Mike Mike Pepper wrote: Think of onclick as a 2-action process: mouse down selects the object, mouse up - if still on-focus - activates the link, in this instance. Same for keyboard action: tab to object selects it, enter/return activates it. Oh, something just occurred to me: best make it explicit that we're talking about onclick behaviours on elements that receive focus via the keyboard (links, form elements). obviously, if you have applied onclick to something else (like a plain vanilla image, or a paragraph, etc), it won't be triggered by the keyboard because the user will not be able to even get to it. but that then becomes a more fundamental accessibility issue. Tell you what, why not run a sequence of tests? Proof of pudding ... I can knock something together this saturday and test in most recent-ish (from IE 4 onwards) browsers, if you like. Anybody who can test on Mac (ideally both OS 9 and OS X) and *nix (konqueror)? Send me a reply off list...I'll collate the results and re-post them here. Patrick -- _ 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 ** -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 24/11/04 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 24/11/04 ** 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] IE's New JavaScript Blocking Feature
Mark Harwood wrote: --- The best and only way i do pop-ups is href=http://google.com/; onclick=window.open(this.href, 'popupwindow', 'width=400,height=300,scrollbars,resizable');return false; this allows you to do whatever you like with the link and also makes it valid, right click-able and so forth.. --- Well I can see that it doesn't take long for the topics to 'off topic' in this list! :) As for the fix ... With the snippet of JavaScript that Mark supplied above, I still get the information bar and no JavaScript run unless you choose to allow it. This was the main problem and reason for the post actually. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Carriere Sent: Friday, November 26, 2004 12:37 PM To: Web Standards Group Subject: [WSG] IE's New JavaScript Blocking Feature I've got two questions but as they are different topics completely, I will separate them into two different threads. They kind of relate, but not enough, so here's the first one regarding IE's New JavaScript Blocking Feature: -- IE's new content blocking features are wreaking havoc on my methods and designs! For the longest time I've been using the included JavaScript w/ rel=external (http://www.sitepoint.com/article/standards-compliant-world) method to have links open up new browser windows while keeping the code valid. I know that I've got to use these methods to keep the code valid as standards compliance outlines that you shouldn't opening new content in different windows. BUT! With some of my applications, I'd like to have new windows open while keeping my code valid anyway. The extremely irritating this is, no IE has that lovely content blocker (added in with Service Pack 2) that cause the JavaScript to be blocked. Sure you can just tell it to include the content and off you go but for those that don't know any better, (and trust me, I to Tech Support for an ISP and there are a lot of people that don't know any better), it's a real pain and the chances that your pages will not be rendered properly are too high. Any thoughts? Ideas? Thanks -- LAWRENCE CARRIERE [EMAIL PROTECTED] www.lawrencecarriere.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 **
