Lachy

Don’t Target Me!

I hate the target attribute! Sure, it has it’s place in HTML, but it has been abused by so many people, it is just annoying. There isn’t really any specific twit for this blog, it’s more of a general overview of the excessively annoying habbit that many authors have.

Why is it Bad?

It’s bad because it attempts to force the user to open a new window. It should be obvious to many people with the excitement over tabbed browsing that allows a user to manage all pages in a single window, that multiple windows are disliked.

Basically, the author of a website should not have any control over the users application, in any way whatsoever. It has been known for long time that opening new windows confuses users. Not only that, it affects users in the following ways:

• A user has to close the window, or at least switch windows, to get back to where they were.
• The back button does not work, including the back button some people, like myself, have on their mouse. That means instead of just holding my hand still and operating my back and forward buttons with my thumb, I have to move my hand to the close button (or use a keyboard shortcut) which takes time. For me, back and foward buttons on the mouse are as essential as the scroll wheel, so when website breaks them, I get annoyed.
• It clutters the desktop and taskbar. I like to keep no more than 5 (or sometimes 6) windows open on my desktop at one time. This includes e-mail, calendar, browser, development environment (text editor, IDE, or whatever I'm using) and sometimes a Windows Explorer window for quick access to my files. If there are any more than that, the buttons on the task bar become too small, there’s too many windows on the desktop and therefore it takes longer to decide which which window I want and where it is located.

Despite these facts, why do people continue to use this user-hostile act? I don’t really understand it, but some think, as Nielsen mentions, that people will remain on their site longer. At least, that’s how my boss tried to explain why the target attribute, unfortunately, must be used for external links at work. Well, this is a myth, not only because (as Nielsen also mentions) the user cannot return in the normal way, but because they’re not looking at your site anyway. They have a new window in front of it, so any reason to open the new window is defeated since any extra time the browser window spends on your site, is spent elsewhere by the user.

Solution

Thankfully, there is a solution to this epidemic. There are extensions, such as the Single Window extension that traps links that would open a new window, but instead opens a new tab. However, I still don’t think that’s right either — I should be the one to decide when a new tab opens. There is also a preference in Mozilla called browser.block.target_new_window which causes any link with a target attribute that is not targetting an existing window or frame, to open in the same window/tab. It is also possible to use a user stylesheet to give some indication when an author is the using the target attibute. I find Chris Pederick’s userContent.css to be the most effective for this purpose. Even though I like to use the browser preference and the user stylesheet (I didn’t particularly like Single Window myself), it’s not a perfect solution and the idea that people think they have the right to control my user agent still bugs me.

There are still some links that always open a new window, unless I explicitly drag the link to the tab bar to open it in an existing or new tab, as desired. These kind of links annoyingly occur in Gmail. Any external link in an e-mail, and even some internal links to different sections of Gmail, try to unconditionally force a new window. These links use a combination of the target attribute and a JavaScript function in the onclick event handler. Disabling JavaScript is not an option in this situation because doing so completely destroys all other functionality in Gmail. I’ve known about this for a long time and have been plainning to give Gmail a Net Twit award. But there is just so much to write about and so little time, so this will have to come at some time in the future (Hopefully) if I ever get around to writing it.

So, in conclusion, It’s my window and I’ll open it if I want to! Please do not force a new window, and please encourage others to drop this bad habbit also.

posted by Lachlan Hunt on Tuesday, October 12, 2004 12 comments

Is IE Really Better?

This weeks Net Twit Award goes to Jim Ley for his comment about IE. I had a good laugh; Hixie framed his copy, and I took a photo of mine:

Jim Ley, 2004-08-19

But this comment at the end of his recent email, is just being arrogant.

posted by Lachlan Hunt on Friday, August 20, 2004 3 comments

False Sense of Security

I'm sure we're all aware of the ridiculous copyright laws and terms of use statements that so many companies have on their websites. They vary in content but their message is essentially the same. it's usually something like you cannot use repoduce any content on our site, or use any images without permission or something along those lines. That's fair enough, people have the right to protect their work. Well, it turns out there are some people who are so over zealous about their copyright, they go to great lengths just to prevent any user obtaining any of their content… Well, at least, not without a fight, but hey, that's what they think. They don't realise that in the process, they're making their site innaccessible to so many people for little, or no benefit.

Many of you would have heard of the Odeon debacle as talked about by Zeldman and Dave Shea, about how Matthew Somerville created an Accessible Odeon site, but was forced to close it down for various reasons including copyright. Well, the twittiness of the Odeon site doesn't even compare to the twittiness and accessibility issues with Share2s.com's product! (Though it is still worthy of a Net Twit award, which I'll write about later)

Share2s.com have come up with WebPage Protector — a product designed to encrypt the content of any static HTML file. It does this by parsing the enitre document, and outputting JavaScript that has encoded every character as an entity. They've published a sample page to demonsrate what it can do. Firstly, for those of you who haven't already figured this out; this is a serious accessbility problem! Try viewing the document with JavaScript disabled, or in a user agent that doesn't even support JavaScript — you won't see a thing!. Not only does this mean that users that use user agents such as Lynx, JAWS, or other limited ability device such as a PDA or mobile phone without JavaScript, search engines such as Google will be unable to index the site well. But I figure any twit willing to destroy their site in this way doesn't deserve to have their site listed anywhere.

They've published a few lists of features, which I'll go through now to prove that the script is entirely useless, and point out where they breach guidelines such as the WAI WCAG. Unless explicitly stated, each method of bypassing has been performed using Mozilla, Firefox and Opera.

Encrypt HTML to hide the source code

Enrypted using a complicated JavaScript technique that encodes everything with an entity and require a self decrypting script to convert it to a lot of document.write statements that eventually writes the real source code for the document. This violates Guideline 6 of WCAG 1.0.

Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

In Mozilla, this is easily bypassed. Simply pressing Ctrl+A and then selecing View Selection Source from the context menu reveals the entire source code in the DOM. I could not do this with Opera.

Disable offline use, prevent Save As… function to save image

I was not able to determine how exactly this is done, however it does mean that any user who wishes to download the page for viewing later offline cannot do so. I could not find any specific guidline that deals with this, but it's quite obvious that this causes unexpected behaviour for the user.

After viewing the source from the previous step, copy and paste the source into a plain text editor and save as HTML. Then, you need to either disable JavaScript or edit the source code and remove the script manually.

There seems to be some code in there that prevents the page displaying when (I'm assuming) the URI does not match the sites domain. Because I was unable to aquire the source with Opera, this also could not be done.

Set No Cache

This means that whenever a user revisits the site, the entire page including all text, images and any other content need to be downloaded again. For user's with a slow connection, and especially for sites with relatively large pages, the user has to wait a lot longer to view the page again.

This can be done using the HTTP Expires header, and does not require JavaScript, but that is intended for pages where the content is frequently updated, and/or it would be a security risk if the page were cashed. ie. Aany content from a secure site, such as an online banking site.

Presumably, this was to prevent any user searching the cache for images files or other content.

I didn't bother checking the cache, I'd already, already saved all the files with Mozilla, however I believe that it must use an IE specific meta tag or something, just like everything else in this encrypted page.

Fully disable the right mouse-click context menu

This disables a feature that the page author should not have any control over. User agents should prevent web page scripts from interacting the the user agent's interface because it interferes with the user's ability to use the application easily. This also applies to preventing the document from being saved as well.

Descent user agents, such as Mozilla and Opera have options to prevent scripts controlling the user interface such as context menus, the status bar and opening or moving windows.

Presumably, this feature was designed to prevent user's from saving images. Even IE can bypass this feature simply by pressing Print Screen on the keyboard, and cutting out and saving the picture with an image editor.

Disable text and picture highlight select,Disable image Drag drop

Again, this interferes with the user agent's interface and thus the user's expectations and ability to use the application and website are impaired.

This did not work in Mozilla or Opera.

Disable Image Tools Bar in IE6

Presumeably, this is to prevent the user using the save, and other buttons provided on that toolbar. This also interferes with the application interface, and thus has the same problems as disabling the context menu and secting text.

Need I say more? Who give a crap, they're annoying anyway! This is IE specific, so it doesn't apply to Mozilla or Opera, so there is no need to bypass it.

Hide display links and address and messages in status bar

The status bar provides valuable information about the link being clicked. Looking at the URI displayed in the status bar for links can indicate to the user that the link is a fragment identifier, a link to an page on the same site or a file, or a link to another resource on another website. Not all users use this, and some choose to hide the status bar.

However for users who do use that feature, their usability of the application will also be impaired as for the 3 previous points.

Again, Mozilla has the option to disable the ability for scripts to change the status bar, and Opera displays the URI in a tooltip text, so it is not affected.

Disable Smart Tags

This is another IE specific feature, and I do not exactly know what Smart Tags to on websites, however, this again interferes with the application interface.

This appears to be performed using an IE specific meta element, which after saving the source code, can be easily removed and thus opened in IE.

Disable Web pages printed

This interferes with one of the most used application features that every user knows how to do, and do so quite often. The accessibility issues are obvious, but this violates Guideline 9 because the page depends on the screen medium and, in particular, user agents that support JavaScript.

This feature did not work in Mozilla or Opera, however this is the easiest feature to by pass. Pressing Print Screen on the keyboard, and creating the page in an image editor will enable printing.

Compress the Html code before encrypt

Ever heard of deflate, or g-zip compression done on the fly by the server? What a waste of time. This may actually be true, I didn't compare the source code sizes.

Nothing to bypass here… Move along people, move along …

Bypass any web content Filter and “Fire Wall” and get more visitors to your site

In the process, you are preventing access to any user who has JavaScript disabled or not supported. Also, any site that is going to trigger a content filter or fire wall to block the page is going to be something that most users wouldn't want to see anyway.

There was no reason to even try to test this, it's a pointless feature.

Stop junk mail and spam

… and every user of a user agent that does not support JavaScript.

Not if I ever find your email address! expect to be abused!

posted by Lachlan Hunt on Tuesday, July 27, 2004 0 comments