Почему использование ссылок с протоколом javascript: - плохая практика?

Контекст выполнения отличается, чтобы убедиться в этом, попробуйте вместо этого использовать следующие ссылки:

<a href="javascript:alert(this.tagName)">Press me!</a> <!-- result: undefined -->
<a href="#" onclick="alert(this.tagName)">Press me!</a> <!-- result: A -->

javascript: выполняется в глобальном контексте, а не как метод элемента, который обычно вам нужен. В большинстве случаев вы делаете что-то с элементом, над которым вы действовали, или по отношению к нему, лучше выполнить это в этом контексте.

Кроме того, он намного чище, хотя я бы вообще не стал использовать встроенный скрипт. Ознакомьтесь с любыми фреймворками для более четкого управления этими вещами. Пример в jQuery:

$('a').click(function() { alert(this.tagName); });

Собственно, оба метода считаются устаревшими. Вместо этого разработчикам рекомендуется разделять весь JavaScript во внешнем файле JS, чтобы отделить логику и код от подлинной разметки.

• http://www.alistapart.com/articles/behavioralseparation
• http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

Причина этого в том, что он создает код, который легче поддерживать и отлаживать, а также способствует продвижению веб-стандартов и доступности. Подумайте об этом так: глядя на свой пример, что, если бы у вас были сотни таких ссылок на странице и вам нужно было изменить поведение alert для какой-либо другой функции с использованием внешних ссылок JS, вам нужно было бы изменить только одно событие связывание в одном файле JS, а не копирование и вставка кучи кода снова и снова или выполнение поиска и замены.

Пара причин:

1. Практика плохого кода:
   Тег HREF указывает на то, что существует гиперссылка на другое место. Использование одного и того же тега для функции javascript, которая на самом деле никуда не ведет пользователя, является плохой практикой программирования.

2. Проблемы с поисковой оптимизацией:
   Я думаю, что поисковые роботы используют тег HREF для сканирования всего веб-сайта и связывания всех связанных частей. Добавляя javascript, мы нарушаем эту функциональность.

3. Нарушает доступность:
   Я думаю, что некоторые программы чтения с экрана не смогут выполнить javascript и могут не знать, как работать с javascript, ожидая гиперссылки. Пользователь будет ожидать увидеть ссылку в строке состояния браузера при наведении курсора на ссылку, в то время как он увидит строку вроде: «javascript:», которая может их сбить с толку и т. Д.

4. Вы все еще находитесь в 1990-х:
   Основной совет - иметь свой javascript в отдельном файле, а не смешивать с HTML страницы, как это было в 1990-х.

HTH.

Я открываю множество ссылок в новых вкладках - только для того, чтобы увидеть javascript: void (). Значит, вы меня раздражаете, как и себя (потому что Google увидит то же самое).

Другая причина (также упомянутая другими) заключается в том, что разные языки должны быть разделены в разных документах. Почему? Хорошо,

• Смешанные языки плохо поддерживаются большинством IDE и валидаторов. Встраивание CSS и JS в HTML-страницы (или что-то еще в этом отношении) в значительной степени уничтожает возможности статической проверки правильности встроенного языка. Иногда также используется язык встраивания. (Документ PHP или ASP не является допустимым HTML.) Вы не хотите, чтобы синтаксические ошибки или несоответствия отображались только во время выполнения.
• Другая причина состоит в том, чтобы иметь более четкое разделение между типами вещей, которые вам нужно указать: HTML для контента, CSS для макета, JS обычно для большего макета и внешнего вида. Они не сопоставляются один в один: обычно вы хотите применить макет ко всем категориям элементов содержимого (отсюда и CSS), а также к внешнему виду (отсюда jQuery). Они могут изменяться в разное время, когда меняются элементы контента (на самом деле контент часто создается на лету) и разными людьми. Так что есть смысл хранить их и в отдельных документах.

Краткий ответ: Встроенный Javascript плох по той же причине, что и встроенный CSS.

Использование протокола javascript: влияет на доступность, а также вредит SEO-дружественности вашей страницы.

Обратите внимание, что HTML означает Hypter Text something something ... Hyper Text обозначает текст со ссылками и ссылками в нем, для чего используется элемент привязки <a>.

Когда вы используете javascript: 'протокол', вы неправильно используете элемент привязки. Поскольку вы неправильно используете элемент <a>, такие вещи, как Google Bot и программа чтения с экрана Jaws, будут иметь проблемы с «пониманием» вашей страницы, поскольку они не очень заботятся о вашем JS, но очень заботятся о Hyper Text ML, обращая особое внимание якоря hrefs.

Это также влияет на удобство использования вашей страницы, когда пользователь, у которого не включен JavaScript, посещает вашу страницу; вы нарушаете ожидаемую функциональность и поведение ссылок для этих пользователей. Он будет выглядеть как ссылка, но не будет действовать как ссылка, поскольку использует протокол javascript.

Вы можете подумать: «Но у скольких людей сейчас отключен JavaScript?» но мне нравится формулировать эту идею в большей степени: «Скольким потенциальным клиентам я готов отвергнуть только из-за флажка в настройках их браузеров?»

Все сводится к тому, что href является атрибутом HTML и как таковой принадлежит информации вашего сайта, а не его поведению. JavaScript определяет поведение, но вы никогда не хотите, чтобы он мешал данным / информации. Воплощением этой идеи мог бы быть внешний файл JavaScript; не использовать onclick как атрибут, а вместо этого как обработчик событий в вашем файле JavaScript.

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

Я всегда стараюсь использовать вместо этого onclick, и добавляю что-то в URL-хэш страницы, чтобы указать желаемую функцию для запуска и добавляю проверку при загрузке страницы, чтобы проверить хеш и активируйте функцию.

Таким образом, вы получаете такое же поведение для кликов, новой вкладки / окна и даже закладок / отправленных ссылок, и все не становится дурацким, если JS отключен.

Другими словами, примерно так (очень упрощенно):

Для ссылки:

onclick = "doStuff()"

href = "#dostuff"

Для страницы:

onLoad = if(hash="dostuff") doStuff();

Кроме того, поскольку мы говорим об устаревании и семантике, вероятно, стоит отметить, что «</a>» не означает «кликабельно» - это означает «привязка» и подразумевает ссылку на другую страницу. Таким образом, имеет смысл использовать этот тег для переключения на другое «представление» в вашем приложении, но не для выполнения вычислений. Тот факт, что у вас нет URL-адреса в вашем атрибуте href, должен быть признаком того, что вы не должны использовать тег привязки.

Вы также можете назначить действие события щелчка практически любому элементу html - может быть, <h1>, <img> или <p> было бы более подходящим? В любом случае, как уже упоминали другие люди, добавьте еще один атрибут (возможно, «id»), который javascript может использовать в качестве «крючка» (document.getElementById), чтобы добраться до элемента и назначить onclick. Таким образом, вы можете разделить представление контента (HTML) (CSS) и интерактивность (JavaScript). И миру не конец.

Обычно у меня есть целевая страница с названием «EnableJavascript.htm», на которой написано большое сообщение: «Чтобы эта функция работала, необходимо включить Javascript». А затем я настраиваю свои якорные теги вот так ...

<a href="EnableJavascript.htm" onclick="funcName(); return false;">

Таким образом, якорь имеет законное место назначения, которое по возможности будет перезаписано вашей функциональностью Javascript. Это будет изящно ухудшаться. Хотя сейчас я обычно создаю веб-сайты с полной функциональностью, прежде чем решу добавить в смесь немного Javascript (что в совокупности устраняет необходимость в подобных привязках).

Использование атрибута onclick непосредственно в разметке - это совсем другая тема, но я бы порекомендовал ненавязчивый подход с такой библиотекой, как jQuery.

Я думаю, это связано с тем, что пользователь видит в строке состояния. Обычно приложения должны быть созданы для аварийного переключения на случай, если javascript не включен, однако это не всегда так.

Со всем распространением спама люди становятся умнее, и когда электронное письмо выглядит «фишинговым», все больше и больше людей смотрят на строку состояния, чтобы увидеть, куда их на самом деле приведет ссылка.

Не забудьте добавить return false; до конца вашей ссылки, чтобы страница не перескакивала вверх для пользователя (если только это не то поведение, которое вы ищете).