link target

Im not a big fan of the "taget" attribute because is not In XHTML Strict.

Since all of the core themes use XHTML 1.0 strict, modules should also use that so the default theme functions all work together like they are supposed to.

But I can see needs for this too. A walk aroud this issue is to use javascript to open a new tabs/window.

Its possible to add a class to a link
<a href="node/1" class="newwindow">My node link</a>

and then let jQuery make the magic

Drupal.behaviors.openlinksinnewwindow = function(context) {
  $('a.newwindow', context).click(function() {
    window.open($(this).attr('href'));
    return false;
  });
}

But I dont know if this should me in Linkit core.

Grate, I hope they will understand that they are now contrbuting to a better web.

hope they don't take away my scrollwheel click :)

Since we're building on a new D7 version, and target attribute is not deprecated in HTML5, we're considering to allow a target="_blank" option when creating links.

My suggestion is that it's turned off by default (since it's "bad web practise"), but the checkbox can be turned on in Linkit general settings.

Thoughts?

I dont think we should include the target attbriute in any verison.

target attribute is not deprecated in HTML5

Yes thats right, but HMTL5 is very forgiving and for example "" is also ok in HTML5 as far as I can see. That doesn't mean that we should think that this is fine.

The target attribute was deprecated in (X)HTML Strict by a reason. Its bad for accessibility, and I still follow that rule.

Many huge web applications like Facebook open external links in a separate window. Of course it should be possible to do this in Drupal as well. The question is rather if it's Linkit's task to do it or not. If there is another solution available, like a filter module that parses external links, maybe that's better.

AFAIK all browsers support target="_blank" and many customer requests it. I think it's bad web too, but let them if they want to.

Sure, we could exclude this from Linkit, but please provide an alternative then, where we can point the users when we get feature requests in the issue queue.

EDIT: The jQuery solution provided in #1 requires the users to remember a class, which IMO maybe is a little too complicated.

The question is rather if it's Linkit's task to do it or not.

Quick answer, no, its not Linkits task to do this.

In the 7.x-2.x version there will be possible to hook into the attributes to create others.
The target attribute can easely be implemented that way, but again, I strongly dont think that this belongs to Linkit core.

Feel free to write a quite ealy plugin to Linkit that extends the attrivbutes with a target attribute.

Also, be aware of that Linkit 7.x-2.x will strip all attribites that is not present as a "Linkit attribute" (hooked or core).

OK, I respect your decision on this issue.

Also, be aware of that Linkit 7.x-2.x will strip all attribites that is not present as a "Linkit attribute" (hooked or core).

Why is that?

Because there is some IE bugs (no shit!) that can't handle some attribute update, and we also don't what so save a lot of crap the editors put into links, as we dont need it. Mostly Ckeditor.

I will put this to issue back to closed (won't fix) as this is has noting to do with L-Core.

If you need the target attribute, just add this function to a custom module:

function MODULENAME_linkit_attributes_alter(&$attributes) {
  $attributes['target']['#type'] = 'select';
  $attributes['target']['#size'] = 1;
  $attributes['target']['#title'] = t('Target');
  $attributes['target']['#default_value'] = '';
  $attributes['target']['#options'] = array(
    '' => t('None'),
    '_blank' => t('New window (_blank)'),
    '_top' => t('Top window (_top)'),
    '_self' => t('Same window (_self)'),
    '_parent' => t('Parent window (_parent)'),
  );
}

OK, target attribute is bad for usability, except when linking to pdf. See this article from thé usability experts: http://www.useit.com/alertbox/open_new_windows.html. Linking to pdf is one of the common use cases of linkit. So I think it should be considered, though perhaps only in combination with the file plugin.

just my 2 cents...

I must agree with fietserwin. PDF (and other file) linking is a common use case, and one where a _blank target makes a lot of sense in my opinion.

This one (#11) did not work for me when using Linkit 7.x-2.1. I used this, in a custom module:

/**
 * Implements hook_linkit_attributes().
 */
function YOURMODULENAME_linkit_attributes($profile) {
  $attributes['target'] = array(
    '#type' => 'select',
    '#title' => t('Target'),
    '#default_value' => '',
    '#options' => array(
      '' => t('None'),
      '_blank' => t('New window (_blank)'),
      '_top' => t('Top window (_top)'),
      '_self' => t('Same window (_self)'),
      '_parent' => t('Parent window (_parent)'),
    ),
    '#weight' => 1,
  );
  return $attributes;
}

After clearing the caches, go to: admin/config/content/linkit/list/default/edit

There's an 'HTML attributes' tab. Expand it, and enable the new HTML Attribute 'Target'. Now it's possible to add a target attribute via the WYSIWYG editor (using the Linkit button).

or for those who don't feel comfortable with making their own module I have created http://drupal.org/project/linkit_target.
It is the function from #14. in a module.

Could we offer a Class field, and offer some predefined classes in the Linkit admin for users to select from in a dropdown list?

StephenOTT, is this a separate request from the target attribute? I am having trouble seeing what it has to do with the target attribute?
Also you could use the above patch at #14 to create the class drop down.
I don't think it would take much to add to the admin panel where you could add a list of classes)
But if its not related to target perhaps we should discuss in a separate thread.

JOsh

Sorry meant to reference comment numbers: Was referring back #1 and #7 related to being too complicated.
Just about adding that little extra UX options that make it so much more usable.
If you think this should be a separate issue then sure we can split it.