Я провожу большую часть своего времени в эти дни, работая над готовящимся Справочником по Ultimate JavaScript SitePoint, и я могу честно сказать, что это мой мозг .
В отличие от авторов предстоящего Ultimate CSS Reference , у меня не было особого желания быть милым с Internet Explorer. И я знал, что столкнусь с ошибками и причудами, ни одна из которых не будет отличаться в IE7 , потому что DOM просто не был на радаре разработки для этой версии.
Тем не менее, я был просто поражен тем хаотическим разломом, который проявляется в реализации даже самых простых вещей.
Возможно, вы помните, не так давно, что я писал о поведении атрибутов href
в Internet Explorer и о том, что для ссылок они возвращаются как квалифицированные URI, а не как буквальные значения атрибутов. Но, о боже … это верхушка айсберга, когда дело доходит до getAttribute() …
Вы бы не подумали, что это так сложно
В дополнение к определению значения атрибутов href
в ссылках, IE делает то же самое для атрибута src
изображений.
При получении атрибута стиля
IE возвращает объект style , а не значение атрибута. Получая атрибут обработки события, такой как onclick
, он возвращает содержимое обработчика события, заключенного в анонимную функцию. Получив значение атрибута, которое оценивается как логическое значение true (например, отключено
или отмечено
, когда оно определено), он возвращает логическое значение, а извлекает
значение, которое оценивается как число (например, tabindex
), он возвращает число. Все эти значения должны быть возвращены в виде строк.
Но эти атрибуты рассматриваются IE как нестроковые значения; и поэтому, если они вообще не определены, они возвращают null , а не пустую строку. IE также возвращает null для неопределенных атрибутов, которые он не распознает ( т . Е. Имена пользовательских атрибутов).
В свою защиту другие неопределенные, но известные атрибуты правильно возвращают пустую строку, которая соответствует спецификации; и IE фактически единственный браузер, который делает это (Firefox, Opera и Safari все возвращают null ). Но это не очень хорошая защита, потому что он делает это только для атрибутов, которые он распознает — так что он на самом деле не реализуется в спецификации, он просто оказывается правильным!
Чистый класс
Чтобы получить атрибут класса
в Internet Explorer, вы должны обратиться к нему как className
; чтобы получить атрибут for,
вы должны обратиться к нему как htmlFor
:
//these work in IE, null in others element.getAttribute('className'); element.getAttribute('htmlFor');
Теперь это побочный эффект сопоставления атрибутов со свойствами HTML DOM — например, как свойство DOM вы всегда должны ссылаться на element.className,
а не element.class
, потому что class
является зарезервированным словом в JavaScript. Но в то время как другие браузеры согласовывают это, позволяя строковым значениям getAttribute() использовать исходное имя атрибута, Internet Explorer этого не делает:
//these work in others, null in IE element.getAttribute('class'); element.getAttribute('for');
И есть другие атрибуты, на которые можно ссылаться только по названию, оканчивающемуся на верблюдах, которое они используют для эквивалента своего свойства DOM , даже если эти имена не являются зарезервированными словами; Я не нашел конкретного шаблона, но примерами этого являются tabIndex
и accessKey
.
И это еще не все …
Internet Explorer реализует второй собственный аргумент для getAttribute() , который должен управлять его поведением. Второй аргумент — это числовой флаг, который может принимать значения 0 , 1 или 2 . По данным MSDN :
-
0(по умолчанию): выполняет поиск свойства без учета регистра и возвращает интерполированное значение, если свойство найдено. -
1: выполняет поиск свойства с учетом регистра. -
2: Возвращает значение точно так, как оно было установлено в скрипте или в исходном документе.
Когда он говорит интерполированное значение,
это означает, что он не обязательно вернет строку, как уже отмечалось. Обратите также внимание на то, как он говорит, что если свойство найдено
[мой акцент] — это может означать, что IE вообще не использует getAttribute() как getAttribute() получения значений узлов, он использует его как метод получения свойств DOM ! Если это правда, это в значительной степени объясняет его неправильное поведение — если он извлекает значения свойств, поэтому ему требуются имена свойств и почему он возвращает значение применимого типа; и когда MSDN сообщает, что getAttribute() извлекает значение указанного атрибута
, он просто лежит.
Разница между 0 и 1 , по-видимому, реализована как документированная — имена атрибутов обрабатываются с учетом регистра, поэтому поиск onClick
не будет совпадать с onclick
.
Однако значение 2 не ведет себя так, как задокументировано. Когда используется это значение, атрибуты обработки событий по-прежнему возвращаются в виде функций, атрибут style
представляет собой пустую строку, а значения, которые оцениваются как логическое значение true возвращают 65535 (то есть 2 16 , наибольшее возможное значение 16-разрядного числа. Что с этим случилось?) Но, эй — на более позитивной ноте — атрибуты href
и src
возвращают их буквальное значение, а не квалифицированный URI . Я полагаю, мы должны быть благодарны за небольшие милости!
Вы можете понять, почему я сказал, что это съедает мой мозг … Я имею в виду, что столь полный отказ от реализации стандартов — это одно, и это достаточно плохо, но Internet Explorer даже не реализует свои собственные проприетарные вещи правильно!