Help w/changing from hyperlink to pop-up box

HTML & CSS
1

I’d like help w/changing from hyperlink to some type of pop-up box, so that instead of the user leaving the Form page to read the Terms, a pop-up box appears containing the Terms. A greybox is used elsewhere on the site, using this

rel="gb_page_center[600, 635] "

, does that help? Should that be somehow integrated into this code:

<td><input type="checkbox" name="agree" id="agree" value="agree" /> <label for='agree'>Check Box To Agree To The
	<a href="http://www.websiteslink/">Terms</a>?</label></td>

Thanks. I look forward to any help.

2

It sounds like you have some javascript at wok here. Most folks would use java script to open and position a new window with the url of your terms and conditions, but how it works will depend on the specific script being called.

If all you want , however is just a new window that DOESNT close the existing form window, and know .js or dont want to risk it ( some people have .js turned off in which case your page would simply not work) … you can just add target=“_blank” to you link, this will open THAT SPECIFIC LINK in a new tab or window.

You could also just do the .js inline (ugh)


<a href="http://www.websiteslink/" onclick='window.open( "http://www.websiteslink/", "myWindow", "status = 0, height = 600, width = 635, resizable = 0" ); return false'>Terms</a>

I assumed that the numbers given were a width and a height respectively and you wanted no status bar on the popup and

BTW keep in mind that whether they leave the page or you open a new wind they are not still in the form , so the “read and agreed” check box still has to be checked in the original form ( but you probably already knew that)

3

I understand what you mean. Here is the bit that does it. http://www.websitecodetutorials.com/code/javascript/js-accessible-pop-up-window.php

Alternatively, if you want to make it prettier just use fancybox.

4

Hmm. I cannot believe it has been suggested target _blank be misused within this thread. It was obvious JS was being hooked to the ‘rel’ attribute.

Deprecated elements and attributes were done so for a good reason many of them to do with semantics; separating structure (markup) from presentation (style sheets), e.g. “Separation of Concerns”, Content (HTML), Presentational (CSS) and Behaviour (JavaScript) - spawning windows is behaviour. Plus accessibly related issues. APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE, and U (all deprecated).

An advantage of applying none deprecated markup can be interoperability. Misusing the target _blank solely for spawning a ‘popup’ style window can become an accessibility and usability issue since it breaks the back button, etc. If you absolutely must open a link in a new window (or tab), explicitly warn the user with a clear indication that the page will open in a different window.

Though obviously you are supposed to use scripts if you want to spawn a new window not related to a frame and that is why Strict doesn’t use it. So it’s best to use unobtrusive JavaScript for the new window. Everything client side is under the control of the visitors to the site.

The ‘target’ attribute (when applied to an anchor) can be used in any Transitional document and typically is supposed to be associated with a Frameset hence why is has never been deprecated for Transitional documents.

Essentially the ‘target’ attribute is used with frames to specify in which frame the link should be rendered obviously you can have target on more elements than the anchor; _blank renders the link in a new, unnamed window.

Why historically people got upset about “target” attribute disappearing from Strict onwards is because it could also be referenced via scripting languages. In either case the anchor target was specifically designed for the Frameset rather than Transitional.

The user is a blackbox, if you use _blank for the sake of spawning then the ‘web author’ is essentially ‘dictating’ that the user will have to view the new page somewhere else. Leaving no direct means of getting back or focus or indication the new window has opened for that matter.

Looking at SPF links, I’d agree that the forum has members that login, in which case they may want to have more than one page instance open. Therefore if you wanted external site links to be opening in a ‘new instance’ then you could alter the browser configuration file to allow that or use client-side script. Thus those both user groups are catered for, i.e. user-agents with or without JS. Therefore the web author would allow the ‘user freedom’ instead of restricting user freedom and imposing the author’s own idea onto the visitor.

Going onto a tangent: Flock mentality? Allow the site to dictate their actions and thus many ‘mindless comply’ and resign themselves to a new window (or tab) spawning as ‘normal’ behaviour. Because they cannot; or do not know how to do otherwise; or are happy being oblivious; or don’t think for themselves.

I assume in essence what is being asked; is why would something as perverse as _blank have to be used when obviously JS is the appropriate tool? Thus this mystic figure of 5% sometimes touted (non JS enabled browsers) is likely to be the people that would prefer not to see a new instance being spawned by default. Thus those people can make up their own minds of how to open a new page. What is worse; when there isn’t indication that the link on many sites will attempt such a feat.

I don’t think anyone is arguing that in some instances a new window would be good; it’s more the case of how the author writes the method or (informs or doesn’t) the user that the link has been designed to open in such a way.

Even when I wrote: Spot the Error 3: Calling all Sleuths! and added multiple errors and made it like a minefield… I wasn’t so dense that I add something as ‘obsolete’ as target _blank as an error because nobody in the last 13-years should have been using it outside of a Frameset environment. The mind truly boggles.

5

Hmm. I cannot believe it has been suggested target _blank be misused within this thread. It was obvious JS was being hooked to the ‘rel’ attribute.

Yup and I humbly stand corrected. :blush:

However I did mention:

It sounds like you have some javascript at wok here. Most folks would use java script to open and position a new window with the url of your terms and conditions, but how it works will depend on the specific script being called.

But w/o seeing the actual .js, I don’t think it would be prudent to link to merely call the fame function as it could be doing a lot of other things as well. My suggestion was a “patch solution for laymen” ( same with suggesting inline js/css) on the assumption that the OP wanted that effect for some reason unknown.

Aside from the deprecation I think it’s bad to require the user to split his/her attention between two windows anyway. PERSONALLY, I would think that this would be an awesome case for an AJAX modal overlay. or just include the terms in to the same doc,and just style the display , maybe toggle with a class switch.

Readers should be advised to take Robert’s comment into SERIOUS consideration with regards to the use of the target attribute.

6

Call me a sinner, but this looks like one of those few times where using a new (but only if small) window (or, instead, a javascripted modal, but then you’ve got all the accessibility work that a new window would actually mostly do for you) would be a usability benefit.

Usually when users click a link, they want to go to the next link. However if you’ve just filled out the whole damn form and the last question is some dumb-a$$ checkbox saying YES I READ AND AGREE THAT MY FIRST-BORN MAY BE TAKEN, the user probably doesn’t really want to move to a whole new page and possibly lose everything which was filled in…
… even though the browser might have caching on and even though the user might be savvy enough to know how to right-click-open-in-new-tab.

The real solution to this though is to ask users BEFORE they start filling out the form to read the terms. Then have the “DID YOU READ THE TERMS???” question be one of the first. Solves all the other problems.

7

Yes, exactly during the UX design you would (re)design the form if at all possible. So you wouldn’t have this scenario of the possibility of the user being distracted by additional popup windows or wasting time filling parts of the form before reading the “main terms”. Perhaps it could be Mephistopheles that would write a form that offered to the option to read as to whether you agree to sell your soul. Though not have it mandatory as to whether you click to open or continue blindly…