Isn't valid XHTML Strict. Looks like a workaround needs to be devised using JS.
Has anyone come up with an alternative solution for Moodle?
See ( MDL-9851 ) for an example of the side effect of this issue (I expect we're pushing bad xhtml out with the resources).
Hi Dan,
The "banishment" of the target attribute in XHTML strict is the topic of many discussions on the Web. Just type xhtml strict target _blank in Google and see for yourself the pros and cons. See for instance: How evil is the target attribute?
Personally, when I am surfing the Web, I do want external links to open in new windows (or, preferably, in new tabs). I hate it when an external link opens in the window I am actually browsing. Just to make sure the latter does not happen, I usually right-click on links and specifically ask for "new tab" location.
I do appreciate that this is very subjective and that other people may hold exactly the opposite view.
What I find irritating, however, is that the people in charge of XHTML strict have taken the decision of "deprecating" the target attribute, thus favoring one point of view, rather than letting web pages designers free of their choice.
Joseph
There is an XHTML strict solution in use already in the moodle code. Sadly, I can't remember which one they went for, but a search of the code may find it, or someone who remembers may post here. It is probably worth using the same technique everywhere, to keep the codebase consistent.
I've found various *popup_window() functions in in lib/weblib.php although none seem to be focused with fullscreen new windows.
See link_to_popup_window() ... the key trick in there is this bit:
This will change the DOM to add the target "on the fly", which means that it's not in the XHTML normally and will not affect validation. It's terrible that we need to do this, but there you go.
onclick="this.target='$name'";
This will change the DOM to add the target "on the fly", which means that it's not in the XHTML normally and will not affect validation. It's terrible that we need to do this, but there you go.
> It's terrible that we need to do this, but there you go.
Agreed. From what Matt was telling me, somehow the logic is that end-users can define what's going to happen on-click via their web-browser settings, just like they can override CSS today.
But as the "spec" doesn't provide a correct way for us to do this, we are using this JS trick that it's pretty near impossible to override. And that seems to be the emerging "standard" approach. So in that sense is fire-and-motion, a lot of effort just to stay in the same broken place.
Not the best part of the xthml standard
(other bits we still love!)
Agreed. From what Matt was telling me, somehow the logic is that end-users can define what's going to happen on-click via their web-browser settings, just like they can override CSS today.
But as the "spec" doesn't provide a correct way for us to do this, we are using this JS trick that it's pretty near impossible to override. And that seems to be the emerging "standard" approach. So in that sense is fire-and-motion, a lot of effort just to stay in the same broken place.
Not the best part of the xthml standard
We are discussing the same matter in MDL-17922
Instead of using the target parameter, we can use the rel parameter to specify the type of relationship of the link to the page that contains the link, so it is semantically correct. Then in the onclick trigger we specify a Javascript function that takes a look at the rel parameter and decide what to do with the link, either stay in the same window, make a new window, etc.
This javascript function could either change the target parameter "on the fly", or trigger the window.open function with the parameters that we want.
Instead of using the target parameter, we can use the rel parameter to specify the type of relationship of the link to the page that contains the link, so it is semantically correct. Then in the onclick trigger we specify a Javascript function that takes a look at the rel parameter and decide what to do with the link, either stay in the same window, make a new window, etc.
This javascript function could either change the target parameter "on the fly", or trigger the window.open function with the parameters that we want.
I know that's an old discussion, but the target attribute is still a bone of contention... and it's apparently still there in Moodle 2.0.
In Moodle 2.0, TinyMCE's toobar offers an Insert/edit link feature which offers a choice of targets. Selecting e.g. the _blank target attribute results in non-validation of the resulting page (in http://validator.w3.org/).
What is the current position of Moodle regarding the target attribute? I'm all for keeping the possibility to select a target attribute, never mind what the WC3 validation gurus decree.
Amusingly, it seems that the target attribute is going to fall into favor again.
HTML5 has introduced several new attributes to various elements that were already part of HTML4:
... the target attribute for the a and area elements is no longer deprecated, as it is useful in Web applications, e.g. in conjunction with iframe.
See here,
Joseph
I'm for keeping this attribute as it prevents leading users off your site when providing external links. A lot of users won't know how to open a link in a new tab or browser window.
I agree.
In addition, it's required when using frames/iframes for uploaded resources - I've added it back in on my local respository.
While I support web standards, there's more important things in life than worrying about whether you've used a deprecated attribute or not (you'll note that it's still supported everywhere). If we're using ugly javascript hacks to "fool" the validator in to passing the page, we may as well just use the target attribute in the first place and be done with it.
Just my opinion, of course
To add fuel to your rant, note that target= is no longer deprecated in HTML 5.
So back to the future 
Tim, that's what I said in my message dated Monday, 1 November 2010, 11:02 AM.
See target="_blank" for Moodle Docs for some application of this new found insight
So to summarise, then:
- The target attribute is not valid XHTML Strict
- The target attribute is supported in the browsers that Moodle supports
- The target attribute will almost certainly be valid HTML 5
- Moodle's coding guidelines specify code must be valid XHTML Strict
So there's a few standpoints we can take moving forward:
- We've implemented javascript workarounds now, so we'll stick with them permanently.
- We're committed to complying with the standards, so we'll stick with the workarounds until a final HTML 5 spec is published, and the target attribute will be allowed if/when we switch to that.
- We're committed to complying with standards, but we'll be pragmatic and tolerate usage of the target attribute.
As expressed above, I favour option 3. However I'd understand support for either of the other options. Of course there may be another standpoint I've missed, and I'm not trying to give anyone an ultimatum. Just trying to bring something useful from this discussion