Link TARGET Attribute Enhancement

[randau]

I would like to use the Link Target attribute, but am
inhibited by the likelihood of a newly opened browser window
completely hiding the Parent browser window. Thus offering
the illusion that you're still in the same browser, but the
Back Button no longer works.

I've done some experimentation and came up with the
conclusion that Microsoft's IE browser has a relatively
small likelihood of that happening, but that Netscape's
browsers have a considerably higher likelihood of it
happening.

MICROSOFT BROWSER:
The Microsoft IE-6 browser opens new Target windows using
the Partial Screen window size of the Parent browser whether
or not the Parent is currently in Full Screen mode. The
only way this becomes a problem is if the Parent's Partial
Screen window size virtually covers the entire screen. That
is the user has, at some point, dragged the Partial Screen
window boundaries out to fill the entire screen.

NETSCAPE BROWSERS:
Netscape's browsers open new Target windows using the size
of the Parent browser or a Background browser immediately
beneath the Parent browser, if one exists. The likelihood
of either being Full Screen is relatively high.

WHY USE THE TARGET ATTRIBUTE:
Some reasons that I would like to use the Target attribute
are: I like having separate browser windows opened when
linking to a different web site or to information that's
made more useful by being able to view two windows at the
same time or swap between them. More often than not, you
don't think about opening a link in another window yourself
till after the fact. You don't always know whether or not
the link is to another web site. It may just be an internal
link. Then there's how many users that don't bother or even
know how to open links in new windows.

As much as I'd like to use the Target attribute in my web
site postings, I think I'll cease doing so, because of the
significant probability of some users being subjected to
full screen or virtually full screen browser windows
completely covering the parent browser. And, then being
under the illusion that they're still in the same browser,
but the Back Button no longer works.

ENHANCING THE LINK TARGET ATTRIBUTE:
I'd like to see the link Target attribute enhanced with some
way of controlling the Target window so that "when opened"
it cannot be Full Screen Size nor a Partial Screen Window
that virtually covers the whole screen. What the user does
with the size after it's opened is their prerogative.

Also, reuse of open Target windows should load the newly
linked web page in Foreground instead of Background which
now makes it appear as though nothing's happened. There
ought to be some option for bringing it to the Foreground
when loaded with a new web page.

--
randau
Oregon, USA

I read and post from the Google Groups web site using a Spam
collecting email address that I don't use for anything else.
So if someone wants to contact me, go to the bottom of my
Home page: http://www.proaxis.com/~randau2/home.htm

 

[Joel Shepherd]

Some reasons that I would like to use the Target attribute
are: I like having separate browser windows opened when
linking to a different web site ...

And what do your _visitors_ like?

Hint: if _you_ like having a separate window open, you can do that using
the browser of your choice. Check the documentation if you're not sure
how.

Your visitors who like having a separate window open can do the same, if
they like.

And your visitors who _don't_ want a separate window open can continue
using their browser just as they like ... as long as you don't use the
Target attribute at all.

Simple, isn't it?

 

[Adrienne]

Gazing into my crystal ball I observed Joel Shepherd

And what do your _visitors_ like?

Hint: if _you_ like having a separate window open, you can do that using
the browser of your choice. Check the documentation if you're not sure
how.

Your visitors who like having a separate window open can do the same, if
they like.

And your visitors who _don't_ want a separate window open can continue
using their browser just as they like ... as long as you don't use the
Target attribute at all.

Simple, isn't it?

I, for one, do not like links opened up in a separate window or tab. I use
mousegestures a lot, and so I rarely look up to see the state of the back
button. There I am, happily gesturing, and nothing happens. Then I look
up and <voice family="Homer Simpson">Doh!</voice> the back button is
disabled.

 

[Toby Inkster]

I'd like to see the link Target attribute enhanced with some
way of controlling the Target window so that "when opened"
it cannot be Full Screen Size nor a Partial Screen Window
that virtually covers the whole screen.

Err... it can be:

<script type="text/javascript">
var h = screen.height * 3 / 5;
var w = screen.width * 3 / 5;
var winsettings = "height=" + h + ",width=" + w +
",scrolling,resizable,location,menubar,toolbar,status";
</script>

<a href="foo" target="_blank"
onclick="return !window.open(this.href,this.target,winsettings);">link</a>

Though I still don't recommend opening links in new windows on a normal
web page. I'll make an exception for "web applications", where sometimes
they can be handy, and you can expect the user to have a certain degree of
experience and training in using the application.

 

[Travis Newbury]

And what do your _visitors_ like?

What if they liked it too? Would it be ok then?

Simple, isn't it?

Yea it actually is

 

[Arne]

What if they liked it too? Would it be ok then?

You droppet the answer to that, when you cited the abowe:
"Your visitors who like having a separate window open can do the same,
if they like".

Going from site to thruu links I find, gets me ending up with a lot of
windows to close when I like to end my surfing. Opening in tabs or
just the same window for eatch site is just more simple.

Heck, don't people ever learn to use the "History" feature in the
browsers? No, because clueless "webbmasters" started to use "target"
even of they don't have a site with frameset.

--
/Arne

Top posters will be ignored. Quote the part you
are replying to, no more and no less! And don't
quote signatures, thank you.

 

[Travis Newbury]

Going from site to thruu links I find, gets me ending up with a lot of
windows to close when I like to end my surfing. Opening in tabs or
just the same window for eatch site is just more simple.

Heck, don't people ever learn to use the "History" feature in the
browsers? No, because clueless "webbmasters" started to use "target"
even of they don't have a site with frameset.

You know, I never seem to have an issue with this no matter how much I
browse. Must be the sites i visit.

 

[Justin Wood (Callek)]

And what do your _visitors_ like?

Hint: if _you_ like having a separate window open, you can do that using
the browser of your choice. Check the documentation if you're not sure
how.

Your visitors who like having a separate window open can do the same, if
they like.

And your visitors who _don't_ want a separate window open can continue
using their browser just as they like ... as long as you don't use the
Target attribute at all.

Simple, isn't it?

Just to re-iterate as well.

The Target attribute in HTML is deprecated, as is Frames entirely.

The only "legitimate" use of target (though not technically documented
as legitimate) is when using with an IFRAME, though imho IFRAME's should
not exist either as they defeat the purpose of "allowing a user to find
where they are" (which was why FRAMEs are deprecated).

unless you are creating a web-app leave window.open and target to no-one.

If you want all external links (at least on your own site) to open in a
new window [for yourself, _you_ cannot claim to know what _every_
visitor to your site wants at any given time] simple right-click on the
link and click "Open in new window".

To also add more information, with IE my |target="_blank"| pages open
fullscreen, it is a windows/[IE] setting to toggle this...do not ask me
where it is, been a long while since I had any use for IE outside of
windows update. [and occasional required activeX pages for my use].

Any further questions I would be glad to answer for you.

~Justin Wood (Callek)

 

[Travis Newbury]

If you want all external links (at least on your own site) to open in a
new window [for yourself, _you_ cannot claim to know what _every_
visitor to your site wants at any given time] simple right-click on the
link and click "Open in new window".

I agree you can not know what all your visitors preferences are. But
what I disagree with is the fact that you think you need to. Opening a
new window, or targeting/reusing a window you have opened is an
essential part of web applications so it should never go away. But it
can also be useful in a website.

Personal opinion, no argument intended.

 

[Alan J. Flavell]

disagree with is the fact that you think you need to. Opening a new
window, or targeting/reusing a window you have opened is an
essential part of web applications

"Essential"? It's going to have a hard time of it with the browser
settings that I use, then.

 

[Justin Wood (Callek)]

I agree you can not know what all your visitors preferences are. But
what I disagree with is the fact that you think you need to. Opening a
new window, or targeting/reusing a window you have opened is an
essential part of web applications so it should never go away. But it
can also be useful in a website.

The question then is, "are you a web application"? if so, what makes
your piece of code "need to be new window".

If nothing other than "convienence" _please_ keep the href the same, and
simply do an |onclick="window.open(...);"| or some such, so that when
*I* want to open such a link in a new tab, it will let me, or if I want
to open it in a new window with my settings it will not break anything, etc.

As in I have found in some so-called professional web-apps, I see a link
I _know_ I want in a new window, I right-click, "Open in new window", it
does not work (due to some scripting policy with the page, usually
href="javascript:" type stuff) then I get frustrated, and normal-click
the link, and sigh when it actually opens in a new window, _that_ is
counter intuitive.

Not to mention the frustration if I wanted teh link in a new tab.

You do not need to know what your visitors preferences are is my point,
DO NOT PRETEND TO, simply leave the settings "normal" (as in, a click on
a link opens "local" to the page, same window, same frame if they are in
frames) if you are a web-app provide settings of some sort to allow a
_user_ to specifically change this if you feel you must, but do not do
it by default.

default should make all users able to do all things they want, open in
same page, or use their browsers mechanics to open in other means.

Personal Opinion, and one I do take personally,
~Justin Wood (Callek)

 

[Travis Newbury]

The question then is, "are you a web application"? if so, what makes your piece of code "need to be new window".

Completely depends on the application. One example we use all the time
is a web conference application with pop up features like a white board,
or slide annotation.

Remember, web applications don't have visitors, they have users.

 

[Justin Wood (Callek)]

....

Remember, web applications don't have visitors, they have users.

Well then let me prose this to you, are you following the recomendations
I put forth about keeping href="" to an actual page "which works" for
your pop-ups, *or* are you depriving your USERS from simple features
such as self-chosen "open in new tab" etc.

And as such, you should provide these users an option to turn off all
"new window" loads, [that your app does] (imho).

Though I feel we have gone waay off topic at least for the Mozilla
Newsgroup, and as such this is all I will post there. [I do not
subscribe to any of the other ones this message seems to go to, if it
does actually get passed through is beyond my comprehension]

~Justin Wood (Callek)

 

[Travis Newbury]

And as such, you should provide these users an option to turn off all
"new window" loads, [that your app does] (imho).

You haven't a clue what a web based application is. It's not a web site.
It has nothing to do with accessibility, javascript, pop up windows,
using flash or any other personal preference you might have.

 

[Chris Morris]

And as such, you should provide these users an option to turn off
all "new window" loads, [that your app does] (imho).

You haven't a clue what a web based application is. It's not a web
site. It has nothing to do with accessibility, javascript, pop up
windows, using flash or any other personal preference you might have.

Really? Certainly in the UK, legislation would require a web based
application to be accessible in a large number of cases. As I
understand it US and European legislation is similar.

As someone who both writes and uses web based applications, I find it
very useful (as do the users) to be able to use the application in
various browsers+settings.

Conversely we've had numerous complaints about a bought in web
application that only works in a narrow range of browsers+settings.

Possibly working for an organisation that has five officially
installed browsers (one of which is officially supported) and who
knows how many different user-installed ones, on at least four
different operating systems (three officially supported to some
extent), gives me a different idea of the importance of making web
applications browser-independent.

 

[Travis Newbury]

have.
Really? Certainly in the UK, legislation would require a web based
application to be accessible in a large number of cases. As I
understand it US and European legislation is similar.

I believe you are mistaken. A web based application does not have the
same accesibility restrictions as a website. Read the regs again and
you will see.

Web applications are not generally open to the public, and you are
given a set of requirements to run them. For Fidelity investments
asset management web application (and most banks for that matter)
require javascript to be turned on. Webex, Live meeting, and Centra
all have browser restrictions and you also need to downlaod specialized
plugins and activeX Hardly what you would call accesibility.

Yet they all enjoy a huge following even in the UK. (with no lawsuits)

 

[Chris Morris]

I believe you are mistaken. A web based application does not have the
same accesibility restrictions as a website. Read the regs again and
you will see.

The audience is much smaller, yes. That doesn't absolve people of the
responsibility to cater for people with disabilities within that
audience.

I'm only really familiar with UK legislation (and I'm a web developer,
not a lawyer) but I can't think of any part of the UK legislation that
would give the exception you describe. If I've missed something please
tell me what.

Web applications are not generally open to the public,

Irrelevant, at least in the UK. The Disability Discrimination Act 1995
protects:
(Part II) Employees
(Part III) People to whom you provide a service
(Part IV) Applicants to educational establishments and students

Part III does not require you to provide the service to everyone for
it to be a service you provide. A bank could not use as its defence
that disabled people could bank with someone else, for example.

Likewise Part II covers one of the most common uses of web
applications.

and you are given a set of requirements to run them. For Fidelity
investments asset management web application (and most banks for
that matter) require javascript to be turned on. Webex, Live
meeting, and Centra all have browser restrictions and you also need
to downlaod specialized plugins and activeX Hardly what you would
call accesibility.

Indeed not.

One of the reasons I don't bank online is because all the banking
sites I've seen *require* javascript, often Internet Explorer,
etc. for their online banking interfaces, despite none of the key
functionality (seeing how much money my account has, transferring
money between accounts, log in, statements) requiring [1] Javascript
to implement. I therefore - probably unfairly - trust their security
measures to have been installed and coded competently about as much as
I can see evidence of competence in the front-end design.

[1] I can see how careful use of Javascript, etc. could make doing
some of this faster, more efficient, less error-prone, whatever. I
have no problem with Javascript being used to do that. That's not the
same thing.

Yet they all enjoy a huge following even in the UK. (with no lawsuits)

No lawsuits *yet* - though there have been several threatened that
were settled out of court. Anyone who could show that they were - as a
result of their disability - substantially disadvantaged in the
provision of service (or denied service) by the requirements of a web
application would be entitled to be provided with a "reasonable
alternative".

The reasonable alternative needn't be web-based, but a court might
decide that it should be to avoid 'substantial' disadvantage (so
requiring someone to travel several miles to the local branch of the
bank to do something someone without that disability could do over the
internet might be regarded as substantial disadvantage).

 

[Travis Newbury]

One of the reasons I don't bank online is because all the banking
sites I've seen *require* javascript, often Internet Explorer,
etc....

Thank you. When you purchase or use a web application, you are
agreeing to follow the rules needed to run that application. It is no
more discriminating for a web based application to require popup
windows (javascript, flash, etc...) than it is for Yahoo radio to
require something that will play sound in order to use it. It is just
a requirement of the software.

 

[Chris Morris]

Thank you. When you purchase or use a web application, you are
agreeing to follow the rules needed to run that application. It is no
more discriminating for a web based application to require popup
windows (javascript, flash, etc...) than it is for Yahoo radio to
require something that will play sound in order to use it. It is just
a requirement of the software.

Firstly: That's my _personal_ reason for not using certain web
applications. That's not the reason that someone with particular
disabilities would have. I have a choice to use or not to use that
application. Someone else may not have that choice.

It's reasonable to ask someone to have particular hardware/software to
use something *up to the point* where they can't do that because of a
disability. At that point - under UK law, at least - it becomes the
responsibility of the _service provider_ to provide a reasonable
alternative.

Secondly:
Yahoo radio needs sound because radio is a sound-based medium. There
is no other practical [1] way to implement radio.

Web applications that use Javascript (flash, pop-ups, etc) fall into
two categories:

1. those where it's genuinely necessary to use that to get the
required functionality and it's just not practical to provide the
same functionality otherwise.

2. those where it could quite easily be done without using any of
those, but it requires (*not* 'works better with' - *requires*)
them anyway.

Case 2 is the problematic one, and the reason that I personally don't
trust some banking sites and why some people may be _unable_ to use
those sites.

Case 1 is fine - the main web application I've written unavoidably
uses Javascript (and recent Mozilla/IE only Javascript, at that) for
one of the main pieces of functionality. However, it doesn't require
Javascript to do any of the other functions, and if you don't have
Javascript there is a substitute - though inevitably with less
functionality - that lets you in theory do the same thing.

I've no objection to web applications that use Javascript (or
whatever) because that's the *only* way to do something, and it has to
be done that way. I use some myself.

Likewise I've no objection to web applications that will work without
Javascript but are easier to use with Javascript because of (e.g.)
additional client-side input validation, dynamic auto-completion of
forms, etc. Again, I use some myself.

What I object to is web applications that require Javascript, not
because there's no sensible way to do it without it, but because the
developer of the web application didn't implement that sensible way. I
tend to avoid these because I'm not sure what else (like security,
data integrity, etc) they didn't implement sensibly. Other people will
avoid them because it is literally impossible for them to use them.

[1] Actually, if voice recognition software improved enough, it might
be possible to make a sound driver that converted (either client or
server side) from sound to a transcript. But for now, not practical.

 

[JT]

Chris Morris wrote:
:No lawsuits *yet* - though there have been several threatened that were
settled out of court.:

Names and details?