W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2007

[whatwg] Target Attribute Values

From: Bill Mason <whatwg@accessibleinter.net>
Date: Sat, 28 Apr 2007 09:51:31 -0700
Message-ID: <46337B93.9080501@accessibleinter.net>
Matthew Paul Thomas wrote:
> On Apr 28, 2007, at 5:29 PM, Bill Mason wrote:
>> ...
>> I can tell you my experience at the company I'm currently working for,
>> as to why they mandate using "_blank" in some circumstances.
>> (Disclaimer: I don't endorse the policy, I just have to live with it.)
>> ...
>> 1) Fear that the user will follow some link away from our pages, and
>> never return to complete the form.  (I think this comes from sales
>> and/or marketing personnel.)
> 
> A common solution to that is to minimize links on the form, even to the 
> point of removing most global navigation. Sometimes form-specific links 
> are necessary (e.g. "By submitting this form you agree to our __terms of 
> service__ and __privacy policy__"), but links like those should use 
> named targets rather than _blank (because if someone opens one of those 
> links twice it's a mistake, they don't actually want two copies open).

While I agree in principle that minimizing links would be a good 
solution, it unfortunately conflicts with this company's position in 
this business space.  Our of our major "selling points" is that, unlike 
  our major competitors in this area, we do customize our forms etc. to 
match the look of the customer's site exactly.  And the customers who 
use our services like that because they prefer the path of the applicant 
from the school's admission pages to our hosted application pages to be 
seamless (i.e. the pages look the same/the transition is not 
particularly noticeable).

So to start minimizing the links -- which would basically mean making 
our pages and the customer's pages a mismatch -- would basically remove 
one of our major points of differentiation between ourselves and our 
competitors.

>> 2) Complaints from users who would follow the surrounding links
>> elsewhere and then lose their way back to the application form.  (This
>> would primarily occur when they started the application form -- which 
>> is typically multiple pages -- and go off following some other link to 
>> find some piece of information about the application process, finally 
>> losing their way to how they got into the form in the first place.)
>>
>> In both cases, I have no idea why the back button isn't enough for
>> everyone involved, or how people got lost in spite of having a back 
>> button.
>> ...
> 
> Because the Back button is a horribly awkward interface for navigating, 
> especially for getting back to pages you visited a few minutes ago. (In 
> some browsers the Back button has a visible associated menu, but it's 
> hard to open -- and it relies on page <title>s, which readers probably 
> didn't notice when first scanning those pages, again because of poor 
> browser design.)

So if that is the case (I'm not entirely convinced, but I don't want to 
turn the thread into an analysis of the back button), then when building 
pages for my company I have this situation:

1) Users follow links off our pages, and complain that they get lost and 
can't find their way back to our pages.

2) I cannot pare links out of the design to keep users from getting 
lost, or change to add warnings/advisories about leaving for another 
site if you follow those links (which was a topic elsewhere) [1]. 
Unless you count sticking advisories in the title attribute of the <a> 
tags, which I do since it's basically the only option I have.  I doubt 
they get noticed much in practice.

3) The back button is not considered reliable as a navigation aid if 
target=_blank is not in use.

That, in a nutshell, would be my company's use case for target=_blank.

[1] 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/011095.html

-- 
Bill Mason
Accessible Internet
whatwg at accessibleinter.net
http://accessibleinter.net/
Received on Saturday, 28 April 2007 09:51:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:34 UTC