2010-05-14 1 views
77

Команда, в которой я работаю, привыкла использовать теги <script> в случайных местах в теле наших HTML-страниц. Например:Неправильная ли практика встраивания JavaScript в тело HTML?

<html> 
    <head></head> 
    <body> 
     <div id="some-div"> 
      <script type="text/javascript">//some javascript here</script> 
     </div> 
    </body> 
</html> 

Я раньше этого не видел. Кажется, он работает в нескольких браузерах, которые я тестировал. Но, насколько я знаю, неверно помещать скриптовые теги в таких местах.

Я не прав? Насколько плохо, что мы помещаем теги скрипта в теги div таким образом? Есть ли проблемы совместимости с браузером, о которых я должен знать?

+1

Выполняет ли 'document.writes' там или нет особых причин для его нахождения там, где оно есть? –

+8

Сценарий является законным в любом месте тела. В этом нет ничего плохого. Это имеет свои последствия (время, ремонтопригодность, смешение кода и компоновки, личные предпочтения), но в остальном это нормально. – Tomalak

+0

@earlz - см. Мой ответ о том, почему это плохо. просто пытаясь спасти жизнь здесь. и я прав. – Jason

ответ

77

Это совершенно справедлива.

Вы не хотели бы поставить большие большие блоки кода смешался в разметке там (лучше использовать внешние скрипты), но это может быть полезно:

  • добавить дополнительную информацию для связывания прогрессирующего -оценка (где эти данные трудно укладывать в имя класса или другой подход к сокрытию расширенной информации в атрибутах); или

  • , где необходимо как можно скорее запустить скриптовое усовершенствование (а не ждать загрузки окна/документа). Примером этого может быть автофокус, который может вызвать раздражение, если его слишком поздно.

Вы можете думать о <style> элементов, которые не допускаются в <body> (хотя большинство браузеров позволяют это, тем не менее).

+10

+1 для автофокуса; иногда я нахожусь на медленном соединении, и мне не весело быть уже где-то в другом месте (в худшем случае: вводить пароль) при возврате в первое поле. –

+1

Однако встраивание JS может быть полезно, когда есть только одна страница и для уменьшения запросов к серверу. Такая же история для встроенного CSS. Но обычно лучше разделить код javascript и css в разделенных файлах, чтобы уменьшить время загрузки страницы (с использованием допустимого заголовка кэша) при использовании шаблона с теми же требованиями к JavaScript и CSS. – Codebeat

1

Это, конечно, законно, я видел это на нескольких страницах here on Exforsys, например.

Теперь это учебный сайт, в котором показаны основы HTML и Javascript, поэтому в этом контексте это совершенно понятно. Тем не менее, я бы не хотел видеть это в производственном коде для чего-то большего, чем простое утверждение или два. Не видя, что вы заменили //some javascipt here Я бы не хотел комментировать.

Не должно быть никаких проблем с этим браузером.

12

Собственно, это довольно часто. Например Google's analytics tracking code использует только этот синтаксис:

<script type="text/javascript"> 
    var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); 
    document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E")); 
</script> 

Если это достаточно хорошо для Google ...

+29

-1 - только потому, что Google делает это, это не значит, что это хорошая практика. Общий! = Хороший. – Jason

+2

В любом случае Google Analytics слишком запутана, и использование JavaScript для отслеживания на самом деле является хорошим примером перестройки. – Esko

+0

, они также рекомендуют помещать скрипт в нижней части страницы, а не посередине, где должны быть размещены сценарии, если вам нужно их разместить. НЕ в заголовке, где люди обычно ставят их – Jason

4

Это действительно и в зависимости от структуры на стороне сервера и природы кода, иногда очень трудно избегать.

1

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

Таким образом, вместо того, чтобы «если вы собираетесь использовать этот HTML-код, убедитесь, что вы импортируете xyz.js», вы можете просто включить HTML-код и сделать с ним.

Таким образом, это не обязательно ужасное зло. Возможно, это не впечатляюще потрясающе, но не совсем ужасно. Вид зависит от намерения.

2

см Yahoo пользовательский интерфейс для лучшей практики: http://developer.yahoo.com/performance/rules.html (JavaScript в нижней части страницы)

+0

большой +1! Так много ответов, но никто из них не упоминает, что скрипты в HEAD могут блокировать другие элементы (например, изображения! Которые могут испортить макет при медленном соединении) –

0

Несколько вещей:

  1. Это абсолютно правильный код-накрест.
  2. Это совершенно не рекомендуется.

Выполнение этой функции значительно замедляет загрузку страницы, поскольку Javascript должен выполняться до того, как любая другая часть страницы может отобразить. Если вы выполняете большую работу в этом Javascript, ваш браузер может зависать. Вы должны стараться (по возможности) загружать свой Javascript динамически и в конце вашей страницы (желательно до метки </body>)

Закупка и чтение High Performance Javascript. Это изменит способ написания JS.

+0

* shakes head at neg vote * sigh – Jason

+2

Не мои downvotes, но когда я думаю Yahoo, я думаю 'YAHOO.util.Event.addListener', не эффективный/сжатый javascript. Я не стал бы читать книгу и рассматривать ее как Евангелие, иногда вы ** должны ** иметь javascript на самой странице, например. переменная, динамически отображаемая, что вы не можете сделать во внешнем '.js'. –

+2

Вы прочитали книгу? если бы у вас было, вы бы знали, что он преподает методы оптимизации. такие вещи, как «YAHOO.xx.xx.xx», кэшируются локально. Иногда, да, это нормально, чтобы отображать переменную на странице, но это обычно можно сделать извне, если вы просто установите скрытое значение ввода с сервера. но я сказал, что это * unrecommended * not * wrong *. Кроме того, Николай Закас, автор, знает свое дерьмо, независимо от того, кто его работодатель. – Jason

3

действительный!

вы можете использовать:

<script type="text/javascript"> 
//<![CDATA[ 

// some javascrpt code that perfectly validates in the w3c validator 

//]]> 
</script> 

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

+1

Это плохая практика в целом. – Jason

+0

ok только что прочитал сообщение, хорошо знать. Я никогда не делаю этого, но никогда, хотя это могло бы повесить ваш браузер ... ... как это происходит? – meo

+1

Любой JavaScript может повесить ваш браузер (иногда я до сих пор получаю эти предупреждения в Firefox со сценарием «Abort» и «Continue script»). –

0

Указанная рекомендация о том, что скрипты должны храниться в заголовке, заключается в том, чтобы убедиться, что сценарий загружен до его вызова. Это только проблема для некоторых обработчиков событий. Для других типов скриптов это не имеет значения, и для некоторых типов (например, document.write) это не имеет никакого смысла.

3

Я предпочитаю помещать ссылки на внешние скрипты в голову и скрипты, которые запускают вещи и инициализируют виджеты и еще что-то в теле.

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

<div id="foo"> 
    <script type="text/javascript"> 
    document.getElementById("foo")... // do something to it 
    </script> 
</div> 

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

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

1

Это одна из многих, много лучших практик, которая также способствует повышению производительности, а именно по улучшению вашего подхода к программированию. в конечном счете, в веб-разработке, чтобы получить продукт из самых важных!

4

Как уже упоминалось несколько человек, оно действует, и оно широко используется.

Рекомендации, относящиеся к семантике, рекомендуют (или по крайней мере рекомендуют) размещать теги скриптов внутри заголовка.

Более современные передовые методы, учитывающие эффективность, рекомендуют размещать теги сценариев (внешние и встроенные) в нижней правой части тела перед тегом body, чтобы позволить разметке полностью визуализировать до выполнения любого javascript.

Для упрощения понимания и поддержания кода рекомендуется использовать «ненавязчивый javascript», где код находится во внешнем файле и связывает события с DOM. (Google ненавязчивый javascript)

В одном случае, когда его полезно иметь встроенный javascript, необходимо инициализировать переменные со значениями, которые существуют только на стороне сервера, которые затем будут использоваться внешним кодом javascript.

1

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

Я бы не сказал, что с этим ничего не получится, когда АБСОЛЮТНО НЕОБХОДИМО (пока он находится в блоке CDATA), но вне этого я бы рекомендовал вашей команде, чтобы они использовали библиотеку скриптов, такую ​​как прототип или jQuery и сохранить внешние скрипты на странице. Обычно это чище, и библиотеки иногда приводят к чистоте кода, который, как я бы сказал, не происходит в настоящее время.

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

0

Если у вас есть редактор, который может обрабатывать одновременно синтаксис html и javascript. И если вам нравится сначала читать несколько строк html, а затем javascript .. уверен. Действуй.

+0

Звучит как Visual Studio и виды бритвы, которые могут обрабатывать оба. Это может быть довольно удобно в некоторых случаях (весь код, который нужно редактировать в одном месте). Конечно, слишком много javascript в представлении может затруднить чтение и понимание кода, а также проблема раздувания выходного html. – jahu

1

Допустимо добавить тело, но IE действительно не любит его. , чтобы быть на более безопасной стороне, убедитесь, что у вас есть свои скрипты внутри тега.

, что действительно создает хаос (Especialy для IE) в проекте, который мы работаем над

2

я не видел этого раньше. Кажется, что в нескольких браузерах работает . Я тестировал. Но, насколько я знаю, неверно помещать теги сценариев в таких местах.

Это действительно, но не хорошая (или рекомендуемая) практика.

Я не прав? Насколько плохо, что мы помещаем теги скриптов в теги div ? Есть ли проблемы совместимости с браузерами, которые я должен знать ?

Там не проблема размещения <script> в любых других элементов (но это должно быть внутри <head> или <body>).Там также не проблема, с точки зрения совместимости браузера, однако, встраивание сценариев JS на веб-страницах представляет серьезные недостатки (как/почему они считаются плохо):

  1. Прибавляет страница веса
  2. Трудность (или, вероятно, невозможно) для минификация
  3. не могут быть перенесены или использоваться для других страниц
  4. не может быть кэшированными (должно быть загружено каждый раз, когда страница загружена)
  5. нет разделительного возникновение проблем (сложнее в обслуживании)
Смежные вопросы