Open Link in a New Window

HTML attribute (valid in HTML5 now):

Inline JavaScript way:

Need front-end development training?

Frontend Masters is the best place to get it. They have courses on all the most important front-end technologies, from React to CSS, from Vue to D3, and beyond with Node.js and Full Stack.

Need front-end development training?

Frontend Masters is the best place to get it. They have courses on all the most important front-end technologies, from React to CSS, from Vue to D3, and beyond with Node.js and Full Stack.

Comments

I think some code might have gotten stripped there. Feel free to email me at [email protected] to fix.

Using the second approach opens the href in my current (parent) window too. i.e. my current window and new window both points to href value. I don’t want my parent window to be changed

My purpose was to open a link in new window,

i tried this, but my parent window(which has link) becomes blank when i click on the link.

It doesn’t work because it should be:

onclick=”window.open(this.href,’_blank’); return false;”

it doesnt though

Target-blank is not strict xhtml (it might be considered as behaviour that should not be placed in the mark-up) and it can make people angry when used on every link, especially the internal ones. But sometimes it can be useful, if there’s an external link among many internal links.
Personally I prefer to use CSS-Content to set a “(ext)” behind those links via auto-detection (attr).

I’d say it’s a bad practice. Because if I want to open link in new window, jsut press shift+mouse key. Or middle button (to open in new tab).

I’d say it’s the best practice to use target=”_blank”, because it simply works.
There are people who don’t know that you can press the middle mouse button or other shortcuts. Nobody will see it at the end. Why should I not break the rule on this point?

How with auto open in new windows?

sorry, i’m newbie in CSS 😀

Thanks! PDFs don’t seem to honor _blank.

hey Jason, for PDF’s use, target=”_new”

This snippet was very useful, thank you!

I think this article is misleading, it clearly states that target=”_blank” is invalid which isn’t true. It’s perfectly valid in both HTML5 and XHTML 1.0 Transitional. It’s only invalid in the strict DTD, but who uses that?
There’s no real reason not to use the target attribute, every browser supports it and will support it for the foreseeable future. And besides, why use JavaScript for something that the browser can do natively?

any benefit/downside to using html instead of JS or vice versa?

This sort of thing should br strongly discouraged. Only ever should a website had a teeny tiny sprinkle of target=»_blank» atop its icing. It is entirely the user’s choice as to whether they want another tab/window opened or not. It doesn’t matter if some users don’t know how to click with the middle-button; who are we to force new tabs upon those who do know how to open links in new tabs for the sake of the few ignorant users out there.

I’ve come across quite a few websites where links open in new tabs when they just shouldn’t and it’s frustrating, because I wanted the link to open in the current tab.

Leave target=»blank» alone unless you absolutely need it.

Perfect! exactly what i’m looking for. thanks 🙂

There actually IS a need for links to open in a new windows… sometimes. I am designing and coding a site which collects data from users which requires them to upload files (images and pdf documents). The overall process involves employees filling out a form and then uploading receipt scans/images for reimbursement. This needs to be viewed by an admin intranet site within the office. I have a nice page displaying the claim in a cute form, easily printable if required, and links to the relevant file uploads.

I don’t want those links to take over the parent window. They are additional info to the data displayed in the parent window, so they are required to open in a new window or tab (based on browser preference settings) while leaving the parent windows alone. Frequently both windows will be examined and compared together. Hard to do if only one is open at a time!

And no, our accounts team are not IT knowledgeable enough to recognise how/when to choose to open a link in a new windows. They expect it done for them. And quite rightly so too.

Having said that, this is a rare case and I would not normally utilise this in any other way or for any other reason. It bothers me that using target=”_blank” is not acceptable in strict html5 mode. I always code my html/css/php to perfect strict acceptance levels. Well…. I did until now. This is the exception. :/

Make a link open a new window (not tab) [duplicate]

Is there a way to make a link open a new browser window (not tab) without using javascript?

5 Answers 5

With pure HTML you can’t influence this — every modern browser (= the user) has complete control over this behavior because it has been misused a lot in the past.

HTML option

You can open a new window (HTML4) or a new browsing context (HTML5). Browsing context in modern browsers is mostly «new tab» instead of «new window». You have no influence on that, and you can’t «force» modern browsers to open a new window.

In order to do this, use the anchor element’s attribute target [1] . The value you are looking for is _blank [2] .

JavaScript option

Forcing a new window is possible via javascript — see Ievgen’s excellent answer below for a javascript solution.

(!) However, be aware, that opening windows via javascript (if not done in the onclick event from an anchor element) are subject to getting blocked by popup blockers!

_{[1] This attribute dates back to the times when browsers did not have tabs and using framesets was state of the art. In the meantime, the functionality of this attribute has slightly changed (see MDN Docu)}

_{[2] There are some other values which do not make much sense anymore (because they were designed with framesets in mind) like _parent , _self or _top .}

Open link in new tab or window [duplicate]

Is it possible to open an a href link in a new tab instead of the same tab?

4 Answers 4

You should add the target=»_blank» and rel=»noopener noreferrer» in the anchor tag.

Adding rel=»noopener noreferrer» is not mandatory, but it’s a recommended security measure. More information can be found in the links below.

It shouldn’t be your call to decide whether the link should open in a new tab or a new window, since ultimately this choice should be done by the settings of the user’s browser. Some people like tabs; some like new windows.

Using _blank will tell the browser to use a new tab/window, depending on the user’s browser configuration and how they click on the link (e.g. middle click, Ctrl +click, or normal click).

set the target attribute of your element to «_tab»

EDIT: It works, however W3Schools says there is no such target attribute: http://www.w3schools.com/tags/att_a_target.asp

EDIT2: From what I’ve figured out from the comments. setting target to _blank will take you to a new tab or window (depending on your browser settings). Typing anything except one of the ones below will create a new tab group (I’m not sure how these work):

Знакомство с новым элементом dialog

Привет, Хабр! Представляю вашему вниманию перевод статьи «Meet the New Dialog Element» автора Keith J. Grant.

HTML 5.2 представил новый элемент dialog для нативных модальных окон. На первый взгляд, он кажется довольно простым (так и есть), но поигравшись с ним я обнаружил, что он имеет несколько замечательных возможностей, которые легко упустить.

Я встроил полноценное демо в конец статьи, но если вы захотите взглянуть на него во время чтения, вы можете найти его здесь.

Вот пример базовой разметки для окна диалога:

Атрибут open означает, что диалог виден. Без этого атрибута диалог будет скрыт до тех пор, пока вы не используете JavaScript, чтобы он стал видимым. Без всякой стилизации диалог выглядит следующим образом:

На странице он спозиционирован абсолютно, так что он появится впереди всего контента, как можно ожидать, и он горизонтально центрирован. По умолчанию, его ширина равна ширине контента внутри.

Базовые операции

В JavaScript есть несколько методов и свойств для облегчения работы с элементом dialog. showModal() и close() — два метода, которые, возможно, понадобятся вам больше всего.

Когда вы используете showModal() для открытия диалога, на страницу добавляется фон, блокирующий взаимодействие пользователя с контентом вне модального окна. По умолчанию фон полностью прозрачный, но вы можете сделать его видимым с помощью CSS (подробнее об этом ниже).

Нажатие Esc закроет диалог, а также вы можете создать кнопку закрытия с вызовом метода close().

Есть еще третий метод, show(), который также показывает модальное окно, но без сопутствующего фона. Пользователь сможет взаимодействовать с элементами за пределами диалога.

Поддержка браузерами и полифилл

На данный момент dialog поддерживается только в Chrome. Firefox предоставляет базовую стилизацию, однако для применения JavaScript API пользователь должен явно включить эту функцию. Я думаю, в скором времени Firefox включат его по умолчанию.

Благо, у нас есть полифилл, который поддерживает и поведение JavaScript, и стилизацию по умолчанию. Для его использования установите dialog-polyfill в npm, или используйте старый добрый тег script. Полифилл работает в IE9 и выше.

При использовании полифилла, каждый диалог на странице должен быть инициализирован:

Этот прием не заменит нативное поведение диалога для браузеров, которые поддерживают его.

Стилизация

Открывать и закрывать модальное окно приятно, однако это выглядит не очень профессионально. Добавить стилизацию так же просто, как и стилизовать любой другой элемент. Фон может быть стилизован с помощью нового псевдоэлемента ::backdrop.

Для старых браузеров, использующих полифилл, этот псевдоэлемент не сработает. В этом случае полифилл добавляет элемент .backdrop, который следует прямо за диалогом. Вы можете стилизовать его с помощью CSS как-то так:

Добавим немного больше разметки для стилизации. Общепринятый подход: разбить диалоговое окно на заголовок, тело и подвал:

Добавив немного CSS, вы можете сделать так, чтобы модальное окно выглядело точно так, как вам нужно:

Больше контроля

Частенько мы хотим немного обратного взаимодействия с пользователем через диалоговое окно. Когда диалог закрывается, вы можете передать строковое значение в метод close(). Это значение присваивается свойству returnValue DOM-элемента dialog, так что вы можете прочесть его позже:

Также есть другие события, к которым вы можете подписаться. Два очень полезных: close (срабатывает при закрытии окна) и cancel (срабатывает при нажатии Esc для закрытия окна).

Единственная недостающая вещь — возможность закрыть модальное окно при клике на фон, но есть обходной путь. Клик по фону вызывает событие клика на dialog как на целевом элементе. И если вы создадите диалог так, что дочерние элементы будут заполнять все пространство диалогового окна, эти дочерние элементы будут целевыми для любых кликов внутри диалога. Таким образом, вы можете подписаться на события клика по диалогу, и закрыть его когда непосредственной целью клика будет само окно диалога:

Это не идеально, но работает. Пожалуйста, дайте мне знать, если найдете лучший способ отслеживания кликов по фону.

Рабочее демо

Я много поработал над демо ниже. Поиграйтесь с ним и увидите, что еще можно делать с элементом dialog. Демо включает полифилл, так что оно будет работать в большинстве браузеров.

Читают сейчас

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Clubhouse запускает прямые денежные переводы

[Перевод] HTML5 Адаптивные изображения

О HTML5 в инфографике

Средняя зарплата в IT

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 33

Есть еще третий метод, show(), который также показывает модальное окно, но без сопутствующего фона. Пользователь сможет взаимодействовать с элементами за пределами диалога.

Видите ли, с момента высказываний о html5 появилась спецификация на разработку custom тэгов. И фреймворки типа полимера (только в качестве примера). И сейчас, на мой взгляд, вопрос стоит именно так — нафига добавлять в спецификацию хоть какие-то новые элементы, когда написание своего уже давно не является чем-то запредельно сложным, а разметка в итоге выглядит ровно так, как нам тут нарисовали (то есть, как угодно, так и будет выглядеть)?

Если вы посмотрите на библиотеку элементов того же полимера, вы увидите, что там диалоговых окон полно. И других элементов, не входящих в стандарт, тоже полно. Давайте их теперь все в спецификацию html6 затащим?

Что же до очевидности поведения… ну практика показывает, что это совсем неоднозначная штука, и очевидным люди могут считать вещи совершенно разные. Было бы лучше, если бы поведение а) легко настраивалось и б) можно было эти настройки узнать, как заглядывая, так и не заглядывая в документацию.

Всплывающее окно, возможно, и проще, а вот модальное нет.

На данный момент dialog поддерживается только в Chrome. Firefox предоставляет базовую стилизацию, однако для применения JavaScript API пользователь должен явно включить эту функцию. Я думаю, в скором времени Firefox включат его по умолчанию.

Демо включает полифилл, так что оно будет работать в большинстве браузеров.

Модальное окно без этого элемента стандартными средствами сделать фактически невозможно, так как модальность подразумевает недоступность элементов под модальным окном для устройств ввода, что крайне сложно / невозможно имитировать.

чем не подходит?

Так можно же fixed-оверлеем перекрыть все, и тем самым предотвратить взаимодействие со всеми элементами. Еще для пущей надежности можно сделать

…
Пока писал понял о чем вы, проверил у себя, действительно при открытом «модальном» окне можно пожмякать TAB и попасть в форму в которую можно ввести какие-нибудь данные.

Интересно, чем обусловлено такая неконсистентность в названиях?

Почему бы не сделать showModal и hideModal? Или openModal и closeModal?
Мало того что глаголы не совпадающие, так ещё и существительное опциональное

Modal — модификатор. show и showModal. Закрытие одинаково.

close относится к атрибуту open.

У меня у одного такое подспудное ощущение, что модальные окна должны были умереть еще четверть века назад?

Ведь модальное окно блокирует любое взаимодействие с приложением. И в некоторых случаях, например при сохранении может быть решает какую-то проблему. Чтобы сохраняемые данные не изменились перед сохранением. Однако, даже тут технологии ушли так далеко, что даже кнопки сохранить во некоторых приложениях не стало.

И мне обидно за пользователей. Почему неспособность разрешить каку-то техническую проблему ложится на плечи пользователя? «Пусть сам решает».
Хотя именно принятие решения, это самый «болезненный» для человекого мозга процесс.

Я помню презентацию TimeMachine от Аpple и эту фразу: «We back up everything». Просто и понятно. Никаких условий о которых нужно помнить. Подключил диск и забыл. Не нужно понимать как это работает. Не нужно беспокоиться ни о чем. Бери и пользуйся. «Мы, технические специалисты, решили твою проблему для тебя, пользователь. Мы разгрузили твой мозг, чтобы ты смог использовать его для творческой работы». Компьютерные технологии должны (да обязаны даже) упрощать жизнь, а не усложнять ее.

И еще больший вопрос у меня возникает вот из-за чего. Ребята, запомните этот момент. Изначально сомнительное решение становится частью стандарта. Стандарта. Мирового, общепризнанного стандарта. Вы все свидетели этого. Чтобы потом не спрашивать, откуда берутся все эти окаменелости. Когда-то достигается та точка где прогресс переходит в регресс.

HTML5 был долгожданным и нужным глотком свежего воздуха.Его долго вынашивали, и не зря. Но прошло время и он стал идти на поводу у чьих-то хотелок.

У нас на проекте я тоже наблюдал похожий сценарий. Был сделан фреймворк, он умел не все, но по ходу дела в него без разбору стали добавлять все хотелки разработчиков, («хотите? сделаем! проще добавить чем думать») и теперь страшно стало им пользоваться потому что баги, баги, баги, и нет им конца.

Вобщем, «Давайте делать паузы в пути . », как говорится в песне.