Начальная и окончательная проверка

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

«ОК» будет соответствовать передовой практике или, возможно, стандарту, если он отвечает на этот вопрос.

Например, документ, полученный в результате синтаксического анализа этой сериализованной HTML-разметки, сначала проверяется с использованием валидатора W3:

<!DOCTYPE html>
<title>foo</title>
bar

В то время как это не:

<!DOCTYPE html>
<script>document.title = 'foo'</script>
bar

И это несмотря на то, что результат одинаков для любого браузера, поддерживающего Javascript. Предполагая, что это веб-приложение и требуется JS, это нормально?

Меня особенно удивляет эта ситуация, когда у нас нет правильного (с точки зрения приложения) способа изначально удовлетворить стандарту. Например, что, если мы изначально не знаем название документа и должны вычислить/получить его с помощью скрипта?

В этом конкретном случае использование заполнителя кажется неправильным:

<!DOCTYPE html>
<title>placeholder</title>
<script>document.title = 'foo'</script>
bar

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

Итак, не вдаваясь в подробности об элементе title, скажем, в целом принято распространять HTML-ресурсы, которые действительны только в конечном итоге?

Подвопрос: я понимаю, что проверка документа (представленного DOM) и проверка его сериализованной разметки — это две разные вещи; есть ли инструменты для первого? (Либо из моментального снимка модели DOM, либо "непрерывно".) Пример:

<!DOCTYPE html>
<title>foo</title>
<script>document.title = ''</script>
bar

Первоначально это проверяется, но технически приводит к недействительному документу без какого-либо очевидного способа его обнаружить.

Обновление: очевидно, что такой инструмент будет иметь ограниченную ценность в контексте статического анализа (проблема остановки и т. д.). Однако инструмент времени выполнения должен быть полезен.

Обновление: спецификация W3C для проверки DOM (уровень 3) .

Обновление: спецификация W3C для Service Workers, которая выглядит как его можно использовать, чтобы убедиться, что DOM действителен перед визуализацией, даже если шаблон не является таковым (избегая использования элементов-заполнителей и т. д.). На момент написания этой статьи еще рано (26 июня 2014 года, так что не цитируйте меня по этому поводу).


person tne    schedule 10.09.2013    source источник
comment
Поскольку это сильно зависит от того, как определяется валидность, какова практическая причина спрашивать? Это должно помочь решить, какое определение действительности следует применять.   -  person Jukka K. Korpela    schedule 10.09.2013
comment
Ты прав; Я определяю его здесь как документ (представленный DOM), действительный в соответствии со стандартом HTML, а не представление разметки. Первоначально я хотел избежать эквивалента FOUC для контента, сгенерированного JS, и решил, что это более простой вопрос, на который я должен был ответить первым. По общему признанию, большинство проблем часто возникает из-за не совсем разумных фреймворков шаблонов, и title может оказаться совершенно уникальным. Оказывается, я действительно хочу запустить код перед рендерингом, что в настоящее время невозможно, насколько я знаю.   -  person tne    schedule 10.09.2013


Ответы (2)


Недопустимый HTML-документ не подходит, даже если вы по разным причинам делаете его допустимым с помощью скриптов.

HTML-документы проверяются и анализируются по мере загрузки до запуска скриптов. Таким образом, даже если вы «исправляете» свой документ с помощью скриптов, высока вероятность того, что ваш документ будет причудливым. Даже если вы сгенерируете весь контент в скрипте, многие браузеры его не примут.

Кроме того, если вы заботитесь о поисковых системах, помните, что:

  • Поисковые системы считают недействительный HTML плохой вещью и повлияют на ваш рейтинг.
  • Скрипты не оцениваются и не анализируются, ваш HTML-документ останется недействительным.

И последнее, но не менее важное: не забывайте о небольшом количестве клиентов, у которых отключены сценарии.

person Tim S.    schedule 10.09.2013
comment
Googlebot действительно обрабатывает JavaScript. Я уверен, что некоторые другие тоже так делают из-за большого количества сайтов, использующих AJAX. - person Niet the Dark Absol; 15.11.2013
comment
@NiettheDarkAbsol Это было в 2010 году? Я знаю, что они делают сейчас, но до сих пор неясно, в какой степени. Но писать недопустимый HTML-код по-прежнему является плохой практикой, потому что он все еще анализируется при загрузке страницы :) - person Tim S.; 15.11.2013
comment
Ах, точно, извините! Увидел это в недавней активности из-за редактирования и не обратил внимания XD - person Niet the Dark Absol; 15.11.2013
comment
@NiettheDarkAbsol, Тим С.: Вопрос был задан и на него был дан ответ 10 сентября 2013 г., а не 10 сентября, поэтому я думаю, что в этом комментарии нет ничего плохого. Между прочим, немного жаль, что я не подчеркнул следствие: мы все равно должны заботиться о возможной проверке во время разработки, потому что изначально действительные документы могут стать недействительными из-за сценариев. DOM-Level-3-Val (см. обновление) отвечает на этот вопрос, хотя мне еще предстоит найти хорошие инструменты, которые его реализуют. Я пытался убедить себя в первоначальной валидации, но пример с заголовком меня все еще беспокоит: например, что, если заголовок локализован? - person tne; 02.04.2014

я не понимаю, как вы хотите решить, станет ли документ «в конечном счете технически действительным». код сценария может ссылаться на произвольное контекстуальное состояние (существующий дом, информация о клиенте пользователя, локальное хранилище, пользовательский ввод, URL-адрес ответа на веб-запрос). большая часть этой информации заранее недоступна валидатору.

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

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

person collapsar    schedule 10.09.2013
comment
Вы правы для любого статического анализатора, я, вероятно, больше искал инструмент времени выполнения, который можно было бы использовать при запуске тестов (например). Я, вероятно, должен был сделать это различие. - person tne; 10.09.2013