В 1990-х годах появилась мода поместить Javascript-код непосредственно в атрибуты <a> href, например:
<a href="javascript:alert('Hello world!')">Press me!</a>
И вдруг я остановился, чтобы увидеть это. Все они были заменены такими вещами, как:
<a href="#" onclick="alert('Hello world!')">Press me!</a>
Для ссылки, единственной целью которой является запуск Javascript-кода и не существует реальной цели href, почему рекомендуется использовать свойство onclick вместо свойства href?
Контекст выполнения отличается, чтобы увидеть это, попробуйте эти ссылки:
<a href="javascript:alert(this.tagName)">Press me!</a> <!-- result: undefined -->
<a href="#" onclick="alert(this.tagName)">Press me!</a> <!-- result: A -->
javascript: выполняется в глобальном контексте, а не как метод элемента, который обычно нужен вам. В большинстве случаев вы делаете что-то с или по отношению к элементу, на котором вы действовали, и лучше выполнять его в этом контексте.
Кроме того, он намного чище, хотя я бы вообще не использовал встроенный script. Просмотрите любые рамки для обработки этих вещей гораздо более чистым способом. Пример в jQuery:
$('a').click(function() { alert(this.tagName); });
Собственно, оба метода считаются устаревшими. Разработчикам вместо этого предлагается отделить все JavaScript во внешнем JS файле, чтобы отделить логику и код от подлинной разметки
Причиной этого является то, что он создает код, который легче поддерживать и отлаживать, а также способствует веб-стандартам и доступности. Подумайте об этом так: посмотрите на ваш пример, что, если у вас было сотни ссылок на странице, и вам нужно было изменить поведение alert для какой-либо другой функции, используя внешние ссылки JS, вам нужно будет только изменить привязка одного события в одном JS файле, в отличие от копирования и вставки кучи кода снова и снова или выполнения поиска и замены.
Пара причин:
Практика плохого кода:
Тег HREF должен указывать на ссылку гиперссылки на другое место. Используя тот же тег для функции javascript, которая на самом деле не принимает пользователя в любом месте, является плохой практикой программирования.
Проблемы с SEO:
Я думаю, что веб-сканеры используют тег HREF для сканирования по всему веб-сайту и связывают все связанные части. Вставляя javascript, мы нарушаем эту функциональность.
Доступ к доступности:
Я думаю, что некоторые читатели экрана не смогут выполнить javascript и могут не знать, как обращаться с javascript, пока они ожидают гиперссылки. Пользователь будет ожидать ссылки в строке состояния браузера при наведении ссылки, пока они видят строку типа "javascript:", которая может смутить их и т.д.
Вы все еще в 1990-х годах:
Основной совет заключается в том, чтобы ваш javascript был в отдельном файле и не смешивался с HTML-страницей страницы, как это было сделано в 1990-х годах.
НТН.
Я открываю много ссылок на новых вкладках - только для просмотра javascript: void(). Таким образом, вы раздражаете меня, как и вы сами (потому что Google увидит то же самое).
Другая причина (также упомянутая другими) заключается в том, что разные языки должны быть разделены на разные документы. Зачем? Ну,
Короткий ответ: Inline Javascript плох по причинам, из-за которых встроенный CSS плохой.
Использование протокола javascript: влияет на доступность, а также наносит ущерб тому, насколько оптимизирована ваша SEO-страница.
Обратите внимание, что HTML означает, что Hypter Text что-то... Hyper Text обозначает текст со ссылками и ссылками в нем, для чего используется элемент привязки <a>.
Когда вы используете протокол javascript: ', вы неправильно используете элемент привязки. Поскольку вы неправильно используете элемент <a>, такие вещи, как Google Bot и читатель экрана Jaws Screen, будут иметь проблемы с пониманием вашей страницы, поскольку они не очень заботятся о вашем JS, но заботятся о Hyper Text ML, принимая специальное примечание анкера hrefs.
Это также влияет на удобство использования вашей страницы, когда пользователь, который не имеет JavaScript, посещает вашу страницу; вы нарушаете ожидаемую функциональность и поведение ссылок для этих пользователей. Он будет выглядеть как ссылка, но он не будет действовать как ссылка, потому что он использует протокол javascript.
Вы можете подумать: "Но сколько людей сейчас отключено JavaScript?" но мне нравится фраза этой идеи в целом: "Сколько потенциальных клиентов я хочу отворачивать только из-за флажка в настройках браузера?"
Это сводится к тому, что href является атрибутом HTML, и как таковой он относится к вашей информации сайта, а не к его поведению. JavaScript определяет поведение, но вы никогда не хотите, чтобы он мешал данным/информации. Примером этой идеи будет внешний файл JavaScript; не используя onclick как атрибут, а вместо этого как обработчик события в вашем файле JavaScript.
Худшая проблема, вероятно, в том, что она нарушает ожидаемую функциональность.
Например, как указывали другие, откройте в новом окне /tab = dead link = раздраженные/запутанные пользователи.
Я всегда стараюсь использовать onclick вместо этого, и добавить что-то в URL-хэш страницы, чтобы указать желаемую функцию для запуска и добавить чек на pageload, чтобы проверить хэш и вызвать функцию.
Таким образом, вы получаете одинаковое поведение для кликов, новой вкладки/окна и даже закладок/отправленных ссылок, и все не становится неловким, если JS отключен.
Другими словами, что-то вроде этого (очень упрощен):
Для ссылки:
onclick = "doStuff()"
href = "#dostuff"
Для страницы:
onLoad = if(hash="dostuff") doStuff();
Кроме того, если мы говорим об устаревании и семантике, вероятно, стоит отметить, что "</a>" не означает "clickable" - это означает "привязка" и подразумевает ссылку на другую страницу. Поэтому было бы целесообразно использовать этот тег для переключения на другое "представление" в вашем приложении, но не для выполнения вычисления. Тот факт, что у вас нет URL-адреса в вашем атрибуте href, должен быть признаком того, что вы не должны использовать якорный тег.
Можно, поочередно, назначить действие события клика почти любому элементу html - возможно, более подходящим может быть <h1>, <img> или <p>? Во всяком случае, как отмечали другие люди, добавьте еще один атрибут (возможно, "id" ), который javascript может использовать как "hook" (document.getElementById), чтобы добраться до элемента и назначить onclick. Таким образом, вы можете разделить презентацию контента (HTML) и интерактивность (JavaScript). И мир не закончится.
Я думаю, что это связано с тем, что пользователь видит в строке состояния. Обычно приложения должны создаваться для отказоустойчивости, если javascript не включен, однако это не всегда так.
Когда все спам, который происходит, люди становятся умнее, и когда электронное письмо выглядит "phishy", все больше людей смотрят на строку состояния, чтобы увидеть, где именно на самом деле будет их ссылка.
Не забудьте добавить 'return false;' до конца вашей ссылки, чтобы страница не переходила к вершине пользователя (если только это поведение не требуется).
Обычно у меня есть целевая страница под названием "EnableJavascript.htm", на которой есть большое сообщение, в котором говорится: "Javascript должен быть включен для работы этой функции". И затем я устанавливаю свои якорные тэги как это...
<a href="EnableJavascript.htm" onclick="funcName(); return false;">
Таким образом, у якоря есть законное место назначения, которое по возможности будет заменено вашей функциональностью Javascript. Это будет грациозно снижаться. Хотя, в настоящее время, я обычно создаю веб-сайты с полной функциональностью, прежде чем я решаю посыпать некоторые Javascript в микс (что в совокупности устраняет необходимость в якорях, подобных этому).
Использование атрибута onclick непосредственно в разметке - это целая другая тема, но я бы рекомендовал ненавязчивый подход к библиотеке, например, jQuery.