Вопросы Теги

Javascript: не удается просмотреть файл html с ссылкой на javascript [duplicate]

Это предупреждение появляется, когда вы печатаете опцию. Компилятор предлагает три варианта отключения предупреждения. Используйте наиболее подходящий. Предупреждение безвредно.

1160
задан Darshan Rivka Whittle 6 April 2013 в 23:00
поделиться

11 ответов

Спецификация XHTML 1 говорит:

С.3. Элемент Minimization и Empty Element Content

Учитывая пустой экземпляр элемента, модель содержимого которого не является EMPTY (например, пустой заголовок или абзац), не использует минимизированный (например, использовать <p> </p>, а не <p />).

XHTML DTD указывает теги сценария как: 

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
421
ответ дан Nathan Tuggy 21 August 2018 в 19:53
поделиться
  • 1
    – Konrad Rudolph 16 September 2008 в 14:11
  • 2
    На самом деле, я не могу найти никакого смысла для этого ограничения :) Это кажется совершенно искусственным. – squadette 16 September 2008 в 14:17
  • 3
    Правильный ответ дал олавк. Приложение C XHTML 1.0 не является причиной того, что все так, как есть, - это то, как все вокруг работает. – hsivonen 9 October 2008 в 15:36
  • 4
    Это не нормативная часть спецификации. Это только приложение о том, как обращаться с браузерами, которые не поддерживают XHTML – Kornel 15 October 2008 в 21:43
  • 5
    Проблема с <script /> заключается не в том, что спецификатор запрещает ее, а в том, что браузеры не интерпретируют ее как «non-tag-soup». если тип содержимого не является приложением / xhtml + xml. Смотрите: stackoverflow.com/questions/348736/… @shabunc: браузеры могут появляться , чтобы понять это, но то, что на самом деле происходит, это размещение содержимого после & lt; p / & GT; внутри абзаца, из-за интерпретации цитаты squadette, чтобы означать, что, поскольку & lt; p & gt; не является пустым, он не может быть самозакрывающимся. В XHTML 1.1 он может быть самозакрывающимся. – Joe 28 July 2011 в 22:07

Это потому, что SCRIPT TAG не является ЭЛЕМЕНТОМ VOID.

В HTML-документе - ЭЛЕМЕНТЫ VOID вообще не нужны «закрывающий тег»!

В xhtml все является общим, поэтому все они нуждаются в прекращении, например «закрывающий тег»; Включение br, простой разрыв строки, как <br></br> или его стенография <br />.

Однако элемент Script никогда не является ничтожным или параметрическим элементом, поскольку script tag перед чем-либо еще, является инструкцией браузера, а не декларацией описания данных.

В принципе, инструкция Semantic Termination, например, «закрывающий тег», необходима только для обработки инструкций, которые семантика не может быть прервана последующим тегом. Например:

<H1> семантика не может быть прервана следующим <P>, потому что она не переносит достаточно своей собственной семантики для переопределения и, следовательно, завершает предыдущий набор команд H1. Хотя он сможет разбить поток на новую строку абзаца, он не «достаточно силен», чтобы переопределить текущий размер шрифта & amp; style line-height , заливающий поток , то есть утечку из H1 (потому что P не имеет его).

Вот как и почему была выработана сигнализация «/» (прекращения).

Окончательное окончание no-description Тег, подобный < />, хватило бы для любого одиночного падения с обнаруженного каскада, например: <H1>Title< />, но это не всегда так, потому что мы также хотим иметь возможность «вложенности», множественную промежуточную маркировку потока: разбивать на торренты перед обтеканием / падением на другой каскад. Как следствие, общий терминатор, такой как < />, не смог бы определить цель объекта для завершения. Например: <b> полужирный <i> полужирный < /> курсив </> нормальный. Несомненно, не получило бы нашего намерения правильно и, скорее всего, интерпретировало бы его как смелый bold-itallic полужирный нормальный.

Так родилось понятие обертки, т. Е. Контейнера , (Эти понятия настолько похожи, что невозможно различить, и иногда один и тот же элемент может иметь оба. <H1> одновременно является оберткой и контейнером. В то время как <B> - только семантическая оболочка). Нам нужен простой, без семантического контейнера. И, конечно же, пришло изобретение элемента DIV.

Элемент DIV на самом деле является 2BR-контейнером. Конечно, приход CSS сделал всю ситуацию более странной, чем в противном случае, и вызвал большую путаницу со многими великими последствиями - косвенно!

. Поскольку с помощью CSS вы можете легко переопределить нативный pre & amp; после поведения BR недавно изобретенного DIV, он часто упоминается как «ничего не делать». Что, естественно, неправильно! DIV являются блочными элементами и будут изначально ломать линию потока как до, так и после концевой сигнализации. Вскоре WEB начал страдать от страницы DIV-itis. Большинство из них все еще есть.

Приход CSS с возможностью полного переопределения и полного переопределения собственного поведения любого HTML-тега каким-то образом позволил запутать и размыть весь смысл существования HTML ...

Внезапно все HTML-теги выглядели как устаревшие, они были разрушены, лишены всего их первоначального значения, личности и цели. Каким-то образом у вас создалось впечатление, что они больше не нужны. Высказывание: для всего представления данных достаточно одного тега контейнера-обертки. Просто добавьте необходимые атрибуты. Почему бы не использовать значащие теги; Создайте теги тегов, когда вы идете, и пусть CSS беспокоит остальных.

Вот как родился xhtml и, конечно же, большой тупой, так дорого заплаченный новыми посетителями и искаженное видение того, что есть, и какова чертовская цель всего этого. W3C перешел от World Wide Web к тому, что пошло не так, товарищи? !!

Цель HTML - передать значимые данные человеческому получателю.

Чтобы доставить информацию.

Формальная часть предназначена только для ясности доставки информации. xhtml не дает ни малейшего внимания информации. - Для него информация абсолютно неуместна.

Самое главное в этом вопросе - знать и уметь понимать, что xhtml - это не просто версия некоторого расширенного HTML, xhtml - совершенно другой зверь ; основания; и поэтому разумно держать их отдельно.

2
ответ дан Bekim Bacaj 21 August 2018 в 19:53
поделиться

Другие ответили «как» и цитировали спецификацию. Вот реальная история «почему нет <script/>», после многих часов врывается в отчеты об ошибках и списки рассылки.

HTML 4

HTML 4 основан на SGML .

SGML имеет некоторые shorttags , такие как <BR//, <B>text</>, <B/text/ или <OL<LI>item</LI</OL>. XML принимает первый вид, переопределяет окончание как «>» (SGML является гибким), так что он становится <BR/>.

Однако HTML не изменился, поэтому <SCRIPT/> должен означать <SCRIPT>>. (Да, «>» должен быть частью содержимого, а тег все еще не закрыт.)

Очевидно, что это несовместимо с XHTML, а будет ломают многие сайты (к тому времени, когда браузеры были достаточно зрелыми , чтобы ухаживать об этом ), поэтому никто не реализовал shorttags и спецификацию

.

Эффективно все «рабочие» самозаверяющие теги - это теги с необязательным концевым тегом на технически несоответствующих синтаксических анализаторах и фактически недействительны. Это был W3C, который придумал этот хак , чтобы помочь перейти на XHTML, сделав его совместимым с HTML .

И конечный тег <script> не является необязательным .

Тег «Self-End» является взломом в HTML 4 и не имеет смысла.

HTML 5

HTML5 имеет пять типов тегов , а только теги «void» и «foreign» - разрешены для самозакрывания .

Поскольку <script> не является void (он может содержать ) и не является чужой (например, MathML или SVG), <script> не может быть самозакрытым независимо от того, как вы его используете.

Но почему? Не могут ли они считать чужие, делать особый случай или что-то в этом роде?

HTML 5 имеет целью обратную совместимость с реализацией HTML 4 и XHTML 1. Он не основан на SGML или XML; его синтаксис в основном связан с документированием и объединением реализаций. (Вот почему <br/> <hr/> и т. Д. Являются действительными HTML 5 , несмотря на то, что они недействительны HTML4.)

Self-clos <script> является одним из тегов, в которых используются реализации отличаться. Он использовался для работы в Chrome, Safari , и Opera ; Насколько мне известно, он никогда не работал в Internet Explorer или Firefox.

Это обсуждалось , когда HTML 5 составлялся и отклонялся, потому что он прерывает браузер совместимость . Веб-страницы, которые автоматически закрывают тег скрипта, могут отображаться неправильно (если вообще) в старых браузерах. Были и другие предложения , но они также не могут решить проблему совместимости.

После того, как проект был выпущен, WebKit обновил парсер, чтобы быть в согласии.

Самозакрывающееся <script> не происходит в HTML 5 из-за обратной совместимости с HTML 4 и XHTML 1.

XHTML 1 / XHTML 5

Когда действительно служил XHTML, <script/> действительно закрыт, поскольку утверждают другие ответы .

За исключением того, что spec говорит , это должен работать , когда он служил HTML:

Документы XHTML ... могут быть помечены типом интернет-медиа «text / html» [RFC2854], поскольку они совместим с большинством браузеров HTML.

Итак, что случилось?

Люди попросили Mozilla на позволить Firefox разобрать соответствующих документам XHTML , независимо от указанного заголовка содержимого (известный как контентное обнюхивание ). Это позволило бы самозакрывающиеся скрипты, а контентное обнюхивание было необходимо в любом случае, потому что веб-хостеры недостаточно зрелы, чтобы обслуживать правильный заголовок; IE был хорош в этом .

Если первая война в браузере не закончилась IE 6, возможно, XHTML тоже был в списке. Но все закончилось. И IE 6 имеет проблему с XHTML. На самом деле IE не поддерживал правильный MIME-тип вообще , заставляя всех использовать text/html для XHTML, потому что IE доля рынка в течение целого десятилетия.

А также контентное обнюхивание может быть очень плохо , и люди говорят , это должно быть остановлено .

Наконец, оказывается, что W3C не означает, что XHTML является sniffable : документ как , так и HTML и XHTML, и Content-Type. Можно сказать, что они стояли твердо на «просто следуйте нашим спекуляциям» и игнорируя то, что было практично . Ошибка в том, что продолжил в более поздние версии XHTML.

В любом случае, это решение разрешило вопрос для Firefox. Это было за 7 лет до появления Chrome ; не было другого значительного браузера. Таким образом, было решено.

Указание только одного doctype не приводит к синтаксическому анализу XML из-за следующих спецификаций.

124
ответ дан Community 21 August 2018 в 19:53
поделиться
  • 1
    @AndyE Когда вы пишете самозакрывающиеся & lt; script & gt;, основные браузеры в то время не думают, что они закрыты и будут анализировать подпоследовательность html как javascript, в результате чего допустимый HTML5 будет разбиваться на эти старые браузеры. Таким образом, предложение отклоняется. Это объясняется в связанном списке рассылки HTML5. – Sheepy 16 March 2015 в 04:36
  • 2
    неясно, в чем основная причина, по которой предложение было отклонено, поскольку обсуждение заканчивается довольно внезапно, хотя одним из поднятых вопросов было нарушение существующих браузеров с новым кодом. Я просто указываю, что <script> будет уникальным как элемент HTML5, которому разрешено самозакрываться. В моем первом комментарии я имел в виду, что обратная совместимость не наносит вреда, поскольку обратная совместимость относится к старому коду, запущенному в более новых браузерах, - что в этом и хорошо. – Andy E 16 March 2015 в 12:51
  • 3
    @AndyE: То, что вы описываете, - это передовая совместимость - способность старого кода работать с новым компилятором / интерпретатором / парсером. Обратная совместимость - это способность нового кода работать со старым компилятором / интерпретатором / парсером. Так что да, обратная совместимость была проблемой, поскольку в противном случае страницы, написанные с учетом новой спецификации, не будут работать в старых браузерах (и да, это традиция веб-программирования, чтобы попытаться сделать работу с новым кодом в старых браузерах как можно больше). – slebetman 9 December 2015 в 10:25
  • 4
    @Dmitry Реальность заключается в том, что отказ от самозакрытого сценария - это односторонняя улица. Поскольку связан , самозакрытый & lt; script & gt; будут разбиты на все браузеры, пользователи просто увидят пустые страницы - игровые консоли, интернет-телевидение, IE 11 на корпоративном ПК Win7 new , миллионы Java runtime , или миллиарды смартфонов. Можете ли вы обновить большинство WebView большинства языков на большинстве устройств? Если HTML5 попробовал, чтобы они потерпели неудачу, как XHTML2. – Sheepy 27 April 2016 в 03:12
  • 5
    очень недооцененный ответ – Kamil Tomšík 21 August 2016 в 09:28

Internet Explorer 8 и более ранние версии не поддерживают синтаксический анализ XHTML. Даже если вы используете объявление XML и / или XTYTML-тип, старый IE все еще анализирует документ как обычный HTML. И в простом HTML самозакрывающийся синтаксис не поддерживается.

Даже браузеры с поддержкой синтаксического анализа XHTML, такие как IE 9 и более поздние , все равно будут разбирать документ как HTML, если вы не обслуживаете документ с типом содержимого XML. Но в этом случае старый IE вообще не отобразит документ!

43
ответ дан Damian Yerrick 21 August 2018 в 19:53
поделиться
  • 1
    «IE не поддерживает синтаксический анализ XHTML». была верна для версий IE в то время, когда это было написано, но это уже не так. – EricLaw 12 August 2013 в 20:57
  • 2
    @EricLaw вы можете уточнить, какая версия IE исправила это? (и любые конкретные условия - например, действительный тип документа) – scunliffe 5 May 2014 в 23:57
  • 3
    @scunliffe IE9 была первой версией с полной поддержкой XHTML. [Д0] blogs.msdn.com/b/ie/archive/2010/11/01/… – EricLaw 6 May 2014 в 14:42

В случае, если кому-то интересно, конечной причиной является то, что HTML изначально был диалектом SGML, который является странным старшим братом XML. В SGML-зоне теги могут быть указаны в DTD как самозакрывающиеся (например, BR, HR, INPUT), неявно закрывающиеся (например, P, LI, TD) или явно закрывающиеся (например, TABLE, DIV, SCRIPT). XML, конечно, не имеет понятия об этом.

Парсеры тегов-супов, используемые современными браузерами, эволюционировали из этого наследия, хотя их модель синтаксического анализа больше не является чистым SGML. И, конечно же, ваш тщательно обработанный XHTML рассматривается как плохо написанный SGML-вдохновленный тег-суп, если вы не отправляете его с типом XML mime. Вот почему ... 

<p><div>hello</div></p>

... интерпретируется браузером как: 

<p></p><div>hello</div><p></p>

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

141
ответ дан greim 21 August 2018 в 19:53
поделиться
  • 1
    Мне любопытно. почему браузер решил интерпретировать его таким образом? – Ahmed Aeon Axan 30 October 2013 в 17:11
  • 2
    @AhmedAeonAxan: Элемент P не может содержать элементы DIV (это недопустимый HTML), поэтому браузер неявно закрывает элемент P (определенный как «неявно закрываемый») перед открытием DIV. Однако браузеры, как правило, ведут себя по-другому в этом отношении (поскольку они могут делать с любым недопустимым HTML). – MrWhite 4 November 2013 в 14:52
  • 3
    @ w3d Является ли этот суп вроде того, что мы можем поблагодарить Netscape или IE? – Cole Johnson 5 September 2015 в 17:25
  • 4
    @ColeJohnson Нет, это не суп для тегов; greim смешивает границу между допустимым и недействительным HTML. Tag soup - это то, что вы получаете, когда авторы не заботятся о правилах, потому что браузеры используют исправление ошибок. Отсутствующий тег end </p>, с другой стороны, фактически является частью определения HTML! – Mr Lister 17 December 2015 в 12:36
  • 5
    @MrLister - Сортировка. "Tag soup & quot; описывает, как HTML анализируется, а не как он создан. Это был термин, используемый для описания разрозненных стратегий браузеров, используемых для понимания HTML, и в отличие от строгого анализа XML. Разбор XML разрешен только для типов mime XML, но поскольку они никогда не достигали широко распространенного использования, браузеры возвращались к различным «суп-тегам». схем, даже для других документов, которые могут быть действительными. – greim 19 December 2015 в 23:17

Чтобы добавить к тому, что сказал Брэд и squadette, самозакрывающийся синтаксис XML <script /> на самом деле является правильным XML, но для его работы на практике ваш веб-сервер также должен отправлять ваши документы как правильно сформированные XML с помощью XML-тип mimetype, такой как application/xhtml+xml в заголовке Content-Type HTTP (и not как text/html).

Однако отправка XML-типа mimetype приведет к тому, что ваши страницы не будут проанализированы IE7, которому нравится только text/html.

Из w3 :

Таким образом, «application / xhtml + xml» ДОЛЖНО использоваться для семейных документов XHTML, а использование «text / html» ДОЛЖНО быть ограничено HTML-совместимыми документами XHTML 1.0. «application / xml» и «text / xml» МОГУТ также использоваться, но в любом случае «application / xhtml + xml» ДОЛЖНО использоваться, а не эти общие типы носителей XML.

I озадаченный этим несколько месяцев назад, и единственное работоспособное (совместимое с FF3 + и IE7) решение заключалось в использовании старого синтаксиса <script></script> с text/html (синтаксис HTML + mimetype HTML).

Если ваш сервер отправляет тип text/html в своих HTTP-заголовках, даже если в противном случае правильно сформированные документы XHTML, FF3 + будет использовать свой режим рендеринга HTML, что означает, что <script /> не будет работать (это изменение, Firefox ранее было менее строгим).

Это произойдет независимо от каких-либо действий с метатегами http-equiv, прологами XML или doctype внутри вашего документа - ветви Firefox, когда он получит заголовок text/html, который определяет, выглядит ли HTML или XML-парсер внутри документа, а парсер HTML не понимает <script />.

212
ответ дан joelhardi 21 August 2018 в 19:53
поделиться
  • 1
    Правильно ли тогда сделать вывод, что если вы откажетесь от поддержки IE7, отправка текста / xml даст вам широкую поддержку браузера для & lt; script / & gt; ? – Chris Moschini 10 April 2013 в 09:15
  • 2
    Итак, короче говоря, & lt; script & gt; будет работать, только если ваш тип MIME на странице xhtml / xml. Для обычных страниц text / html это не сработает. И если мы попытаемся использовать «xhtml / xml», MIME, он нарушит совместимость с IE. Подводя итог: Keep Calm and Use & lt; script & gt; ... & lt; / script & gt; Спасибо, Джо ;-) – Navin Israni 9 December 2013 в 13:54
  • 3
    Отличное объяснение. Еще один момент, заслуживающий внимания, заключается в том, что Firefox также будет иметь локальные файлы .html, представленные как суп-теги, независимо от мета-тегов, по тем же причинам. Для файлов XHTML Firefox будет отображать их только соответственно, если они названы .xhtml. – alecov 8 January 2015 в 15:19
  • 4
    @ChrisMoschini. Возможно, но используйте application/xhtml+xml, а не text/xml. – TRiG 4 July 2017 в 15:31

Internet Explorer 8 и старше не поддерживают правильный тип MIME для XHTML, application/xhtml+xml. Если вы используете XHTML в качестве text/html, который вам нужен для этих более старых версий Internet Explorer, чтобы сделать что-либо, он будет интерпретироваться как HTML 4.01. Вы можете использовать только короткий синтаксис с любым элементом, который позволяет исключить закрывающий тег. См. Спецификацию HTML 4.01 .

«Краткая форма» XML интерпретируется как атрибут с именем /, который (поскольку нет знака равенства) интерпретируется как имеющий неявное значение "/". Это неверно в HTML 4.01 - непринятые атрибуты не разрешены, но браузеры игнорируют его.

IE9 и более поздние версии поддерживают XHTML 5 , обслуживаемые с помощью application/xhtml+xml.

18
ответ дан Mike Dimmick 21 August 2018 в 19:53
поделиться

Различие между «истинным XHTML», «faux XHTML» и HTML, а также важность типа MIME, отправленного сервером, были уже хорошо описаны здесь . Если вы хотите попробовать прямо сейчас, вот простой отредактированный фрагмент с предварительным просмотром в реальном времени, включая самозакрытый тег сценария для браузеров: 

div { display: flex; }
div + div {flex-direction: column; }
<div>Mime type: <label><input type="radio" onchange="t.onkeyup()" id="x" checked  name="mime"> application/xhtml+xml</label>
<label><input type="radio" onchange="t.onkeyup()" name="mime"> text/html</label></div>
<div><textarea id="t" rows="4" 
onkeyup="i.src='data:'+(x.checked?'application/xhtml+xml':'text/html')+','+encodeURIComponent(t.value)"
><?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[<!ENTITY x "true XHTML">]>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
  <p>
    <span id="greet" swapto="Hello">Hell, NO :(</span> &x;.
    <script src="data:text/javascript,(g=document.getElementById('greet')).innerText=g.getAttribute('swapto')" />
    Nice to meet you!
    <!-- 
      Previous text node and all further content falls into SCRIPT element content in text/html mode, so is not rendered. Because no end script tag is found, no script runs in text/html
    -->
  </p>
</body>
</html></textarea>

<iframe id="i" height="80"></iframe>

<script>t.onkeyup()</script>
</div>

Вы можете увидеть Hello, true XHTML. Nice to meet you! ниже textarea.

Для неспособных браузеров вы можете копировать содержимое текстового поля и сохранять его как файл с расширением .xhtml (или .xht) ( благодарит Alek за этот намек ).

3
ответ дан myf 21 August 2018 в 19:53
поделиться

В отличие от XML и XHTML, HTML не знает о самозакрывающемся синтаксисе. Браузеры, которые интерпретируют XHTML как HTML, не знают, что символ / указывает, что тег должен быть самозакрывающимся; вместо этого они интерпретируют его как пустой атрибут, и парсер все еще считает, что тег «открыт».

Так же, как <script defer> рассматривается как <script defer="defer">, <script /> рассматривается как <script /="/">.

19
ответ дан Sebastian Zartner 21 August 2018 в 19:53
поделиться
  • 1
    Элегантно, как это объяснение, на самом деле это неправильно. Если бы это было так, то было бы & quot; / & quot; атрибут для элемента сценария в DOM. Я проверил IE, Firefox и Opera, и ни один из них на самом деле не содержит такой атрибут. – Alohci 22 February 2009 в 14:04
  • 2
    / не является допустимым символом имени атрибута, поэтому он отбрасывается. В противном случае это объяснение довольно ясное. – hallvors 17 August 2012 в 12:37
  • 3
    На самом деле, некоторые синтаксические анализаторы HTML (и особенно валидаторы) могут интерпретировать / как часть конструкции NET (Null End Tag). – IllidanS4 7 November 2016 в 23:13

Люди, о которых говорилось выше, уже в значительной степени объяснили эту проблему, но одна вещь, которая может прояснить ситуацию, заключается в том, что, хотя люди используют '&lt;br/>' и все это время в HTML документах, любой '/' в таком положении в основном игнорируется и используется только при попытке сделать что-то как синтаксическое, так и XML и HTML. Например, попробуйте '&lt;p/>foo&lt;/p>', и вы получите обычный параграф.

25
ответ дан sg7 21 August 2018 в 19:53
поделиться

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

С другой стороны, HTML имеет отличный тег для включения ссылок на внешние ресурсы: тег <link> и может быть самозакрывающимся. Он уже используется, чтобы включать таблицы стилей, каналы RSS и Atom, канонические URI и всевозможные другие лакомства. Почему бы не JavaScript?

Если вы хотите, чтобы тег сценария был включен, вы не можете сделать это, как я уже сказал, но есть альтернатива, хотя и не умная. Вы можете использовать тег самозакрывающейся ссылки и ссылку на свой JavaScript, предоставив ему тип текста / javascript и rel как скрипт, что-то вроде ниже: 

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />
23
ответ дан user2428118 21 August 2018 в 19:53
поделиться
  • 1
    Мне нравится, почему это не так «умный», хотя? – Josh M. 18 September 2013 в 03:05
  • 2
    Потому что есть предопределенный тег скрипта, который выполняет точно задачу загрузки скрипта. Почему вы путаете вопросы, используя что-то еще? Молот молоток в гвоздях .. Было бы разумно использовать обувь? – Dave Lawrence 27 March 2014 в 17:56
  • 3
    @daveL - И у нас есть теги <style>, но мы используем теги ссылок для внешних файлов CSS. Определение тега ссылки: & quot; & lt; link & gt; тег определяет связь между документом и внешним ресурсом. & quot; Кажется вполне логичным, что тег ссылки будет использоваться для внешнего CSS или JS ... это то, что он предназначен для ... связывания во внешних файлах. note Я не говорю spec / cross-browserness / etc, я просто комментирую логическую природу использования тегов ссылок для привлечения как CSS, так и JS ... на самом деле это очень многое сделало бы если бы это было так. Не уверен, что обувь [аналогия] подходит. – Jimbo Jonny 26 January 2016 в 04:14
Другие вопросы по тегам:

Похожие вопросы: