HTML 5 - Раннее усыновление, где это возможно - хорошо или плохо?

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

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

Некоторые примеры:

// new, simple HTML5 doctype (puts browsers in standards mode)
<!doctype HTML>

// new input types,  for easy, generic client side validation
<input type="email" name="emailAddress"/>
<input type="number" name="userid"/>
<input type="date" name="dateOfBirth"/>

// new "required" attribute indicates that a field is required
<input type="text" name="userName" required="true"/>

// new 'data-' prefixed attributes
// for easy insertion of js-accessible metadata in dynamic pages
<div data-price="33.23"> 
    <!-- -->
</div>
<button data-item-id="93024">Add Item</button>

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

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

Однако, несмотря на то, что все они действительны в HTML 5, они НЕ подходят для HTML 4, а HTML 5 по-прежнему является черновиком на этом этапе.

Хорошо ли продвигаться вперед и использовать эти функции раньше?

Есть ли проблемы с реализацией браузера, которые я не понял?

Должны ли мы разрабатывать веб-страницы сейчас, используя черновые возможности HTML 5?

Ответы

Ответ 1

Можно рассмотреть несколько вещей:

  • Во-первых, проверка не так много значит, потому что HTML-страница вполне может быть действительной, но плохо автором, недоступной и т.д. См. Скажите "нет" Значки "Valid HTML" и Отправка XHTML в виде текста /html считается вредоносным (ссылка на тесты hobo-web, упомянутые в другом ответ)
  • Учитывая это, я настоятельно рекомендую использовать новый DOCTYPE: единственная причина для его использования в HTML5 заключается в том, что это самая маленькая вещь, которая запускает режим стандартов в браузерах, поэтому, если вы хотите стандартного режима, пойдите с ним; у вас мало причин использовать другой, многословный, подверженный ошибкам DOCTYPE
  • Что касается улучшений форм, вы можете использовать библиотеку Weston Ruter webforms2, чтобы довести ее до неосознавающихся браузеров
  • и, наконец, о атрибутах data-*, он a) работает во всех браузерах (пока вы используете getAttribute()), b) все же лучше, чем злоупотреблять атрибутами title или class и c) не будет утруждать вас проверкой, как мы уже говорили ранее, что валидация не так важна (конечно, но это не имеет значения, если ваша страница недействительна, если ошибки достоверности являются умышленными, и вы уже можете использовать проверку HTML5 в валидатор W3C, поэтому...); поэтому нет реальной причины не использовать их.

Ответ 2

Хороший вопрос!

Вкратце: это зависит от вашего контекста и степени риска:)

Немного длиннее:

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

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

Ответ 3

Если ваша страница в значительной степени зависит от размещения поисковой системы, может быть стоит подумать, что некоторые движки уделяют приоритетное внимание проверке HTML (Источник: http://www.hobo-web.co.uk/seo-blog/index.php/official-google-prefers-valid-html-css/).

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

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

Ответ 4

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

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

См. также более старый ответ.

Ответ 5

См. Принцип надежности:

В RFC 761 (управление передачей Протокол, 1980) Американский компьютер ученый Джон Постель подвел итоги более ранние сообщения желаемых критерии совместимости для Интернет-протокол (см. IEN 111 1, RFC 760) следующим образом:

Реализации TCP должны следовать общий принцип надежности: консервативный в том, что вы делаете, либерал в том, что вы принимаете от другие.

Итак, imho, нет.

Ответ 6

Я не буду внедрять новые функции из HTML, пока, по крайней мере, они не будут поддерживаться всеми основными браузерами.

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

Приветствуются новые типы форм, тем не менее, формы должны быть проверены на стороне сервера.

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

Ответ 7

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