Работая над идеей простой оболочки HTMLElement, я наткнулся на следующее для Internet Explorer и Chrome :
Для данного HTMLE-элемента с идентификатором в дереве DOM можно извлечь div, используя его идентификатор в качестве имени переменной. Так что для див как
<div id="example">some text</div>
в Internet Explorer 8 и Chrome вы можете сделать:
alert(example.innerHTML); //=> 'some text'
или
alert(window['example'].innerHTML); //=> 'some text'
Итак, означает ли это, что каждый элемент в дереве DOM преобразуется в переменную в глобальном пространстве имен? И это также означает, что можно использовать это в качестве замены для getElementById
метода в этих браузерах?
Ответы:
Предполагается, что «именованные элементы» добавляются как видимые свойства
document
объекта. Это действительно плохая идея, так как она позволяет именам элементов конфликтовать с реальными свойствамиdocument
.IE усугубил ситуацию, добавив именованные элементы в качестве свойств
window
объекта. Это вдвойне плохо, так как теперь вы должны избегать именования ваших элементов после того, как любой из элементовdocument
илиwindow
объекта, который вы (или любой другой код библиотеки в вашем проекте) захотят использовать.Это также означает, что эти элементы видны как глобальные переменные. К счастью, в этом случае любые реальные глобальные
var
илиfunction
объявления в вашем коде затеняют их, поэтому вам не нужно сильно беспокоиться об именовании здесь, но если вы попытаетесь сделать присвоение глобальной переменной с конфликтующим именем, и вы забудете объявить этоvar
, вы получите ошибку в IE, поскольку он пытается присвоить значение самому элементу.Обычно считается плохой практикой опускать
var
, а также полагаться на то, что именованные элементы видныwindow
или являются глобальными. Придерживайтесьdocument.getElementById
, что более широко поддерживается и менее неоднозначно. Вы можете написать тривиальную функцию-обертку с более коротким именем, если вам не нравится печатать. В любом случае, нет смысла использовать кеш поиска идентификатора к элементу, потому что браузеры обычно оптимизируютgetElementById
вызов, чтобы в любом случае использовать быстрый поиск; все, что вы получаете, это проблемы, когда элементы изменяютсяid
или добавляются / удаляются из документа.Opera скопирована IE, а затем WebKit присоединилась, и теперь как ранее Нестандартизованные практики сдачи названных элементов на
document
свойствах, и ранее IE только практика сдачи ихwindow
будут быть стандартизирована по HTML5, чей подход к документу и стандартизировать каждый авторы браузеров навлекли на нас ужасную практику, сделав их навсегда частью сети. Так что Firefox 4 также будет поддерживать это.Что такое «именованные элементы»? Все, что с
id
, и все,name
что используется для «идентификации» целей: то есть формы, изображения, якоря и некоторые другие, но не другие не связанные экземплярыname
атрибута, такие как имена элементов управления в полях ввода формы, имена параметров в<param>
или введите метаданные в<meta>
. «Идентификации»name
следует избегать в пользуid
.источник
name
следует избегать» - это случай<input>
, когдаname
атрибут играет критическую роль в формировании ключа пар ключ-значение для отправки формы.name
одинаковых управляющих имен в полях ввода формы ...»Как упоминалось в предыдущем ответе, это поведение называется именованным доступом к объекту окна . Значение
name
атрибута для некоторых элементов и значениеid
атрибута для всех элементов становятся доступными в качестве свойств глобальногоwindow
объекта. Они известны как именованные элементы. Посколькуwindow
это глобальный объект в браузере, каждый именованный элемент будет доступен как глобальная переменная.Первоначально он был добавлен Internet Explorer и в конечном итоге был реализован всеми другими браузерами просто для совместимости с сайтами, которые зависят от этого поведения. Интересно, что Gecko (движок рендеринга Firefox) решил реализовать это только в режиме причуд , тогда как другие движки рендеринга оставили его включенным в стандартном режиме.
Однако, начиная с Firefox 14, Firefox теперь поддерживает именованный доступ к
window
объекту и в стандартном режиме. Почему они изменили это? Оказывается, есть еще много сайтов, которые используют эту функциональность в стандартном режиме. Microsoft даже выпустила маркетинговую демоверсию, которая не позволяла демоверсии работать в Firefox.Недавно Webkit рассмотрел обратное , предоставив именованный доступ к
window
объекту только в режиме причуд. Они решили против этого по той же причине, что и Геккон.Так что ... сумасшедший, поскольку кажется, что это поведение теперь технически безопасно использовать в последней версии всех основных браузеров в стандартном режиме . Но хотя именованный доступ может показаться несколько удобным, его не следует использовать .
Почему? В этой статье можно подвести итог многим рассуждениям о том, почему глобальные переменные плохие . Проще говоря, наличие множества дополнительных глобальных переменных приводит к большему количеству ошибок. Допустим, вы случайно набрали имя a
var
и случайноid
набрали узел DOM, СЮРПРИЗ!Кроме того, несмотря на стандартизацию, в браузерных реализациях именованного доступа все еще остается довольно много несоответствий.
name
атрибута доступным для элементов формы (input, select и т. Д.).<a>
теги доступными через ихname
атрибут.И я уверен, что это еще не все, если вы попытаетесь использовать именованный доступ в крайних случаях.
Как уже упоминалось в других ответах, используйте
document.getElementById
для получения ссылки на узел DOMid
. Если вам нужно получить ссылку на узел по егоname
атрибуту, используйтеdocument.querySelectorAll
.Пожалуйста, не распространяйте эту проблему, используя именованный доступ на вашем сайте. Так много веб-разработчиков потратили впустую время, пытаясь отследить это волшебное поведение. Нам действительно нужно принять меры и заставить механизмы рендеринга отключить именованный доступ в стандартном режиме. В краткосрочной перспективе это приведет к тому, что некоторые сайты будут совершать плохие поступки, но в долгосрочной перспективе это поможет продвинуть сеть вперед.
Если вам интересно, я расскажу об этом более подробно в моем блоге - https://www.tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/ .
источник
document.querySelectorAll
иdocument.querySelector
при доступе к DOM. +1 за хорошее предложение использовать это. Доступ к элементам с помощью селектора определенно является более эффективным процессом.Вы должны придерживаться
getElementById()
в этих случаях, например:IE любит смешивать элементы
name
иID
атрибуты в глобальном пространстве имен, поэтому лучше четко указывать, что вы пытаетесь получить.источник
Да, они делают.
Протестировано в Chrome 55, Firefox 50, IE 11, IE Edge 14 и Safari 10
на следующем примере:
http://jsbin.com/mahobinopa/edit?html,output
источник
Должен прозвучать вопрос: «Становятся ли HTML-теги с предоставленными идентификаторами глобально доступными элементами DOM?»
Ответ ДА!
Вот как это должно было работать, и именно поэтому W3C начал вводить идентификаторы. Идентификатор тега HTML в проанализированной среде сценариев становится соответствующим дескриптором элемента DOM.
Тем не менее, Netscape Mozilla отказалась отвечать (на их вторгаясь) W и упорно продолжала использовать устаревшую атрибут Имени, чтобы создать хаос и, следовательно, разорвет функциональность сценариев и удобство кодирования, приносимое введением W3C в Уникальных идентификаторах.
После фиаско Netscape Navigator 4.7 все их разработчики пошли и проникли в W3C, в то время как их партнеры вытесняли Интернет неправильными методами и не использовали примеры. Принудительное использование и повторное использование уже устаревшего атрибута Name [!, Который не должен был быть уникальным] наравне с атрибутами ID, чтобы сценарии, использующие идентификаторы для доступа к определенным элементам DOM, просто ломались!
И перерыв они сделали , как они будут также писать и публиковать обширные кодирования уроков и примеры [их браузер не распознает все равно] , такие , как
document.all.ElementID.property
вместо того ,ElementID.property
чтобы по крайней мере , сделать его неэффективным и дать браузер более накладные расходы в случае , если это не просто разбить его на HTML-домен с использованием того же токена для имени (теперь [1996-97] устарело) и стандартного атрибута ID, предоставляющего ему такое же значение токена.Им легко удалось убедить - тогдашнюю - подавляющую армию невежественных любителей написания кода в том, что имена и идентификаторы практически одинаковы, за исключением того, что атрибут идентификатора короче и, следовательно, сохраняет байты и более удобен для кодера, чем свойство древнего имени. Что, конечно, было ложью. Или - в их заменяющих опубликованных статьях HTML, убедительных статьях, что вам нужно будет указать и имя, и идентификатор для своих тегов, чтобы они были доступны для механизма сценариев.
Убийцы Мозаики (под кодовым названием «Мозилла») были настолько взбешены, что подумали: «Если мы пойдем вниз, то и Интернет тоже».
Растущая Microsoft - с другой стороны - была настолько наивна, что подумала, что должна оставить устаревшее и помеченное для удаления свойство Name и обращаться с ним так, как если бы это был идентификатор с уникальным идентификатором, чтобы они не нарушали функциональные возможности сценариев. старые страницы, закодированные стажерами Netscape. Они были смертельно неправы ...
И возвращение коллекции массивов элементов, конфликтующих с ID, также не было решением этой намеренной искусственной проблемы. На самом деле это победило всю цель.
И это единственная причина, по которой W3C стал уродливым и дал нам идиотизм, такой как
document.getElementById
и сопутствующий ему чертов раздражающий синтаксис в стиле рококо ... (...)источник