Creating Valid New Window Popups for Multiple Markup Languages (XHTML4, HTML5, etc.)
Susurrus - February 23, 2007 - 23:10
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
The "target" attribute doesn't validate with the newest XHTML standards. In doing so, I've added a script found at http://www.456bereastreet.com/ that will create new windows for links in JS.
I've zipped up copies of all the files that I changed/added. There's an external image window for use with CSS, the JS file that I've modified slightly, and the module that includes that javascript.
The attached file is actually a ZIP file just renamed to get past the filter.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| userlink_changes.jpg | 7.44 KB | Ignored | None | None |
#1
That's a great patch, I hope it gets included. Modules shouldn't use deprecated or invalid XHTML, and this solves it very neatly.
#2
#3
I like the idea, but would prefer a more standard implementation. How does http://drupal.org/project/link do things? I haven't looked, but suspect that they are doing something more jQuery-like.
Eventually, I will get to this, but if someone can provide a patch that requires less (or more standard Drupal) Javascript, I'll get it in there. Please provide patches as described here -- that will help to make sure that they get applied in a more timely fashion.
Thanks,
Marc
#4
A validation fix would be good,
IMO the standards dropping the target attribute was a mistake,
A wider, better fix is required for all Drupal links that want to keep using target or its equivalent, not just this module
Although this script looks OK, it's not at all Drupaly.
Something similar should be rewritten using existing Drupal code and jquery. There's a much tighter implementation of addEvent available, and of course all the link scanner code is just one function in jquery.
Good concept, good suggested fix, but it requires different code.
#5
After a quick look at link.module and the project's issue queue, it appears that they're generating the same sort of markup that userlink.module is generating -- see this issue: http://drupal.org/node/145286
I still would prefer a patch with some Drupalized Javascript (the link.js file has a good example with the Drupal.linkAutoAttach function. There is a handbook page somewhere on how to write good auto-attaching javascript code for Drupal...
If someone provides a good patch for this, it'll get in there.
Thanks again,
Marc
#6
Moved to Drupal, as that's what should really handle this.
A good start would be [#97759]
We could add code to all pages that define links through
l()that have an 'external' attribute specified for the link. This could just be used internally by Drupal to attach this code to the page using a special class attached to these types of links.#7
According to the HTML5 (and I think XHTML5), the "target" attribute is no longer deprecated:
http://www.w3.org/TR/html5-diff/#new-attributes
I think what we need here is a way to determine how Drupal is serving its content and then modifying the output accordingly (see #145551: Enable loading and rendering into JSON, XML, etc.): HTML4/5 should use target, as it's less resource intensive and perfectly acceptable to do so, XHTML1.0 Strict/1.1 should use the jQuery method. I'm not sure how other formatting would work (RSS, JSON, etc.). I think the format specifier used in the resultant change in #145551: Enable loading and rendering into JSON, XML, etc., if there is one, or the theme should be used for format the output of l(), maybe through a
theme_l()function.