IE7 и IE8 случайно не могут загрузить внешний скрипт - PullRequest
7 голосов
/ 28 декабря 2011

Я динамически добавляю <link> элементов в голову, когда DOM готов.Тем не менее, я получаю противоречивые результаты в IE8 и IE7 (все остальные браузеры в порядке).

Каждые несколько раз страница загружается (кэшируется или не кэшируется), IE 7/8 отбрасывает несколько правил CSSв таблицах стилей. 1 или 2 из моих динамических таблиц стилей не будут загружаться.Это всегда те же 1 или 2 таблицы стилей, которые IE склонен игнорировать - , хотя панель инструментов разработчика показывает их как добавленные к голове! .

Сами таблицы стилей отображаются как <link> элементов в окончательном DOM, но некоторые из их правил не применяются (хотя каждые несколько перезагрузок они применяются, без каких-либо проблем).

В моем положении у меня нетроскошь написания кода из <head> (ограничение CMS) - я могу только динамически вставлять из тела, что может быть проблемой.

ОБНОВЛЕНО: Это код, который яиспользование (расположенное внутри <body>) для вставки таблиц стилей:

document.observe('dom:loaded', function() { // Using Prototype.js

// Add stylesheets
// addStylesheet('cite.css', 'head'); // Contains no webfont/@font-face rules
// addStylesheet('type.css', 'head'); // Contains webfont family name references*
// addStylesheet('flex.css', 'head'); // Responsive rules with @media queries
// addStylesheet('anm8.css', 'head'); // Some minor positional CSS for home page
// addStylesheet('gothic-cite.css', 'head'); // *Contains @font-face config
// addStylesheet('stag-cite.css', 'head'); // *Contains @font-face config

addStylesheet('all.css', 'head'); // Contains ALL content from above in 1 file

function addStylesheet(cssname, pos2)
{
    var th2 = document.getElementsByTagName(pos2)[0];
    var s2 = document.createElement('link');
    s2.setAttribute('type', 'text/css');
    s2.setAttribute('href', cssname);
    s2.setAttribute('media', 'screen');
    s2.setAttribute('rel', 'stylesheet');
    th2.appendChild(s2);
}

});

Как и предполагалось, даже когда я объединил все правила в одну таблицу стилей (что я ненавижу делать), IE 7/8 продолжает работать вхолостуюкак описано с некоторыми правилами, и страница выглядит по-другому.

В качестве дополнительной проверки я также удалил все @font-face и ссылки font-family: "webfont-name" правил из таблиц стилей, и то же поведение продолжилось.Следовательно, мы можем исключить проблему с веб-шрифтами .

Вы можете увидеть аномалии, посетив следующую страницу с IE8 и обновив / нажав навигационную кнопку несколько раз.Кажется, совершенно случайно, когда IE8 отбрасывает эти стили.Однако на встроенной странице управления все стили загружаются правильно, каждый раз.

Live Page (с проблемами)

https://www.eiseverywhere.com/ehome/index.php?eventid=31648&tabid=50283

  1. PHP-на основе CMS печатает XHTML при загрузке страницы (содержимое шаблона смешано с пользовательским содержимым)
  2. Prototype.js загружается и инициализируется по умолчанию при загрузке страницы
  3. Собственная CMS scripts.js файл анализируется назагрузка страницы
  4. Мои скрипты запускаются при загрузке DOM, по существу заменяя body.innerHTML CMS fluff-HTML только на нужный мне HTML, затем добавляет таблицы стилей в <head>.
  5. Для lte IE 8 плагины расширения CSS (selectivizr.js, html5.js и ie-media-query.js) загружаются в <body> с помощью условных комментариев.Не уверен, что они ждут DOM:loaded ...
  6. Редактор CMS WYSIWYG преобразует все возвраты каретки в пустые <p> теги , что приводит к таким элементам, как <section>содержится внутри неработающих тегов <p> и дополнительных тегов <p></p>, создаваемых там, где ожидается пробел.Однако только lt IE 8, кажется, душит это, поэтому я добавил следующие правила CSS, чтобы исправить это:

    :not(.ie7) p { display: none; }
    .ie7 p { display: inline; }
    article p { display: block !important; }
    
  7. Я должен заметить, что внешние таблицы стилей здесь извлекаются изодин и тот же домен, но каждый раз, когда они перезагружаются, для файла создается новый URL-адрес на основе MD5.Я не уверен, что предыдущие версии файла (или предыдущие файлы) по-прежнему доступны по их предыдущим URL-адресам.Это, вероятно, не является проблемой, поскольку вновь созданная таблица стилей all.css все еще отбрасывает правила, которые были в файле с самого начала.

Страница управления (работает без нареканий))

http://client.clevelanddesign.com/CD/IDG/CITE/home.html

  1. Чистый документ XHTML - без PHP.
  2. jQuery используется, а не Prototype, для IE8 и ниже.
  3. Все ресурсы (таблицы стилей) присутствуют в <head> при загрузке страницы - без динамической вставки
  4. Для lte IE 8, плагинов расширения CSS (selectivizr.js, html5.js и ie-media-query.js)) изначально инициализируются.

Перефразированный вопрос:

Как вы думаете, какое из этих различий может привести к триггеру IE 7/8 в стилях при загрузке на страницу Live?Лично я подозреваю, что проблема связана с состоянием гонки, или что Prototype.js и другие скрипты CMS все портят (к сожалению, нет способа удалить их со страницы).

PS: я уже пытался использовать функцию IE createStylsheet(), но безрезультатно.

ОБНОВЛЕНИЕ - Скриншоты работы / не работы в IE8

IE8: код DOM при правильной загрузке: IE8: DOM code when loaded correctly

IE8: код DOM, когда НЕ загружен правильно: IE8: DOM code when NOT loaded correctly

Ответы [ 2 ]

1 голос
/ 29 декабря 2011

Я точно прибил , что происходит , но до сих пор не знаю причину триггера:

selectivizr.js загружается неправильно каждые несколько страниц.

Все правила, использующие селекторы CSS3, требуют применения этого скрипта в IE 7/8. Поэтому, когда IE 7/8 не загружает selectivizr.js правильно, эти правила игнорируются. Эти правила, безусловно, включают ссылки на веб-шрифты, а также ошибочные <p> свойства отображения.

Чтобы напомнить вам всем, эти вспомогательные JS-скрипты загружаются нормально (из <body>) с начальной загрузкой страницы, прежде чем мой скрипт заменит содержимое <body> (, включая ссылку на этот скрипт ). Поэтому есть вероятность, что он инициализируется дважды (кто-нибудь может это подтвердить?)

Проблема в том, что на веб-сайте управления selectivizr.js всегда загружается правильно в IE 7/8. Также нет известных несовместимостей между js-помощником CSS3 и js-файлами справки Media Query (при правильной инициализации).

Я удалил selectivizr.js со страницы, и страница была загружена точно так же после 20+ обновлений. Хорошо, чтобы вернуть последовательность, плохо, что я потерял свои правила CSS3 в IE 7/8.

Видимо, так работает рассматриваемый плагин js:

В соответствии со спецификациями W3C, веб-браузер должен отказаться от стиля правила, которые он не понимает. Это представляет проблему - нам нужен доступ к селекторам CSS3 в таблице стилей, но IE выбрасывает их. к чтобы избежать этой проблемы, каждая таблица стилей загружается с помощью XMLHttpRequest. Это позволяет скрипту обходить внутренние браузеры Анализатор CSS и получение доступа к необработанному файлу CSS.

Источник: http://www.css3.info/css3-pseudo-selectors-emulation-in-internet-explorer/

Я могу попробовать любые предложенные плагины CSS3-селектора, которые у вас могут быть; может быть, кто-то загрузит более надежно или у него будет меньше накладных расходов и, следовательно, меньше места для проблем, связанных с задержкой. Есть альтернативы?

Или, возможно, я должен добавить его после , когда DOM готов во второй раз (после того, как мой скрипт заменит содержимое тела) к <head> или в другом месте <body>. Ни один из этих вариантов не работал - у них был одинаковый, если не худший результат .

0 голосов
/ 29 декабря 2011

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

После многих месяцев усилий над 3 разными проектами (и разными подходами, используемыми в каждом), мы наконец-то столкнулись с тем фактом, что IE7 и IE8 не способны правильно или последовательно динамически загружать и обрабатывать внешние скрипты или CSS.

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

Как дополнительное примечание, IE не полностью виноват. Существуют огромные сложности, связанные с загрузкой, обработкой и рендерингом сценариев / CSS в правильных порядках и программированием этого процесса таким образом, чтобы он хорошо работал в любой среде (webkit + mozilla + IE9 +), требует знаний почти на уровне экспертов и очень тщательного тестирования.

В вашем случае, одним из примеров плохого «потока» является тот факт, что, когда я специально просматривал вашу страницу, он кратко показывает страницу, не примененную к CSS (чёрт возьми!), Перед тем как экран «обновляется» и CSS вытягивается. и применяется. Плохо, плохо, плохо.

Другие проблемы, которые я заметил, это большое количество httprequests в целом. Каждый требует поиска DNS, проверки кэша / истечения срока действия (и других вещей, продиктованных заголовками) и последующей загрузки ответа. На настольных компьютерах это не так уж заметно, но на мобильных устройствах, планшетах и ​​даже на некоторых медленных / перегруженных ПК это особенно заметно.

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

  1. Обслуживание CSS как отдельного кэшируемого файла из CDN и страниц в предварительно проанализированных, предварительно итеративных, предварительно визуализированных фрагментах HTML, минимизирующих обработку JS на стороне клиента (только элементы привязки после загрузки), или
  2. Используйте уже существующие клиентские фреймворки, такие как Sencha, SproutCore, YUI и т. Д. - они создали для вас фреймворк и уже исправили все ошибки.

Перед тем, как я изменю свое мнение, должны произойти две вещи: IE8 должен исчезнуть из общего использования (падает ниже 10%), а «среднее» мобильное устройство должно иметь 2 ядра физических процессоров. В настоящее время только в дорогих / высококачественных моделях установлены двухъядерные процессоры.

Также следует отметить, что самые быстрые мобильные процессоры, даже с JIT JS-компиляторами, по-прежнему в 10 раз медленнее, чем типичные десктопы по производительности в JS, которые по сравнению с настольными компьютерами конкурируют лицом к лицу с Pentium 4 или старым AMD. Athlon 64.

...