|
|||||||
New to SitePoint Forums? Register here for free!
|
![]() |
|
|
Thread Tools | Display Modes |
|
|
#1 |
|
SitePoint Articles
Join Date: Apr 2001
Posts: 0
|
Article Discussion
This is an article discussion thread for discussing the SitePoint article, "New-Window Links in a Standards-Compliant World"
|
|
|
|
|
|
#2 |
|
SitePoint Member
Join Date: Jun 2004
Location: Northern Ireland
Posts: 17
|
Really helpful - thanks!
|
|
|
|
|
|
#3 |
|
Also available in Large
![]() ![]() ![]() ![]() ![]() ![]() Join Date: Sep 2002
Location: Walsall, UK
Posts: 1,971
|
This seems like a reasonable approach to a problem that is definitely causing confusion to developers. My concern though is that if "target" is being phased out of XHTML, why would it be available in the DOM? It might be legible for now, but I can see the target object in the DOM being phased out too to match the XHTML standards.
Thanks for a useful tutorial anyway! |
|
|
|
|
|
#4 |
|
SitePoint Community Guest
Posts: n/a
|
I agree with bigsi on this one. However for the time being it is an excellent solution to the problem. We can only hope CSS3 implements target:self,top,parent,blank etc.
|
|
|
|
#5 |
|
SitePoint Zealot
![]() ![]() Join Date: Aug 2003
Location: Mexico
Posts: 158
|
I was pointed to this article right after posting a question in the forums, actually my qustion was equivalent to this article's title.
In answer to bigsi: If XHTML is suposed to get rid of every presentation, and behaviour tags is because those tasks will be taken by CSS and JS (or similars). In this particular case, the "target" is purely behaviour, so it remains as a Javascript task, just as "font" is now a CSS duty. Thinking that way, I don't see why could DOM quit supporting target, or CSS supporting font because of XHTML standards. |
|
|
|
|
|
#6 |
|
SitePoint Enthusiast
![]() Join Date: Jul 2004
Location: Nottingham
Posts: 89
|
Agreed, it is behaviour - but what do people think about the accessibility issues surrounding the opening of new windows?
|
|
|
|
|
|
#7 |
|
SitePoint Community Guest
Posts: n/a
|
this is too much like work. it's easier to just use something like this: http://liquidpulse.net/articles/xhtml/general/opening_new_windows_in_xhtml_strict/introduction
It's easier to understand for non-programmers, it's accessable, and it degrades gracefully if the user doesn't have javascript, or has it disabled. |
|
|
|
#8 |
|
SitePoint Community Guest
Posts: n/a
|
This is more of a better option if javascript was disabled.
<a title="User Profile" href="http://www.sitepoint.com/users.asp?ouid=4" onclick="window.open(this.href, 'popupwindow', 'width=400,height=300,scrollbars,resizable'); return false;">View User Detials</a> |
|
|
|
#9 | |
|
SitePoint Enthusiast
![]() Join Date: Jul 2004
Location: Nottingham
Posts: 89
|
Quote:
|
|
|
|
|
|
|
#10 |
|
SitePoint Community Guest
Posts: n/a
|
and without js ? because that script doesn't works in firefoz 0.93
|
|
|
|
#11 |
|
SitePoint Community Guest
Posts: n/a
|
If pop-ups are disabled it just opens in the window. And the url is still visible as a normal link.
|
|
|
|
#12 |
|
SitePoint Community Guest
Posts: n/a
|
and standards compliance is better???
|
|
|
|
#13 |
|
SitePoint Community Guest
Posts: n/a
|
What about the simple fact that I HATE it when any site opens links in new windows?
|
|
|
|
#14 |
|
SitePoint Community Guest
Posts: n/a
|
"New-window" links are evil... but sometimes they can be convenient (for showing original-sized images, or help texts, or stuff like that). For those cases, this is really helpful. The fact that the link still works when popups are being blocked is only added value.
|
|
|
|
#15 |
|
SitePoint Member
Join Date: Sep 2004
Location: san francisco
Posts: 0
|
Will this solution work even where Javascript is disabled? I am wanting to know what the best solution is where you have links within a site, such as the local weather, but you don't want people to leave your site or have to hit their back button. I've always understood it to be that if you just link them away from your site, even to check weather, they might not come back. But it seems that MS new automatic security settings block all Javascript, so even my date/time js won't work where js is disabled. Does the above solution for external links present the same problem?
Thanks! |
|
|
|
|
|
#16 |
|
SitePoint Zealot
![]() ![]() Join Date: Feb 2001
Posts: 176
|
I'd use something like that if my visitors could choose. Here is a variation on the script that looks promising. It puts a checkbox to let the user decide, then remembers their preference with a cookie.
Personally, I'd prefer that the default was not a new window, just a choice. I tried it on a test page and for some reason it's not working quite right when I tested it, but may be helpful for others here. |
|
|
|
|
|
#17 |
|
SitePoint Community Guest
Posts: n/a
|
A note about the "rel" attribute used for the anchor <a>. In the w3c Rec, you could read this at link-types:
"Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types." Looked at the source of this page, I didn't found profile definition in the <head profile="">. To be standard, you should use this. ;-) P.S.: first time I heard about profiles. |
|
|
|
#18 |
|
SitePoint Enthusiast
![]() Join Date: May 2004
Location: Alberta, Canada
Posts: 87
|
Why is W3C reporting that there is no such attribute as 'rel' (xhtml Strict or Transitional)?
This method works very elegantly, except it won't validate. Is there any way to make it so that it will without reverting back to html 4? |
|
|
|
|
|
#19 |
|
SitePoint Community Guest
Posts: n/a
|
I have been using this theory for quite a few websites, but I did run into a problem. If the page is large, and/or download speeds are slow, then clicking a link will happen before the onLoad event is triggered.
|
|
|
|
#20 |
|
SitePoint Enthusiast
![]() Join Date: Dec 2003
Location: Bishkek
Posts: 74
|
I think browsers will be for a long time support target attribute.
|
|
|
|
|
|
#21 |
|
SitePoint Enthusiast
![]() Join Date: Oct 2003
Location: Canada
Posts: 32
|
annother nice thing about doing it this way is that you can still right-click > open in new window and you don't get a stupid JS error, because it isn't using JS to open the window.. just change the target value.
|
|
|
|
|
|
#22 |
|
SitePoint Community Guest
Posts: n/a
|
i think puzanov is just missing the point here (like millions other... including browser coders...):
it's not about "supporting" it's about "conforming"! unless ALL THINGS conform, we'll keep having to deal with 75934594 hacks for some browser redmond-based... that's the point in "Standards"... |
|
|
|
#23 |
|
SitePoint Community Guest
Posts: n/a
|
Why on earth didn‘t they keep target in HTML? There should obviously be an easy way to open a link in another window.
And yes, I think the method provided in this article is too much of a hassle to be the standard in the future. |
|
|
|
#24 | ||
|
☆★☆★
![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jan 2002
Location: in transition
Posts: 21,477
|
Quote:
Quote:
![]() |
||
|
|
|
|
|
#25 |
|
SitePoint Community Guest
Posts: n/a
|
In comment to: "vgarcia Nov 1st, 2004 @ 11:47 AM MST"
When using Javascript's "window.open()" the links will not work when javascript is unavailable; thus making it less accessible. |
|
![]() |
| Bookmarks |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
| Display Modes | |
|
|
|
All times are GMT -7. The time now is 14:11.










Linear Mode
