HTML 5 - раннее принятие, где возможный - хороший или плохой?
Я нашел полное решение в блоге под названием CodeRonin. Мне кажется, что это единственный полный пример во всем Интернете. Спасибо, CodeRonin!
http://code-ronin.blogspot.de/2008/09/msmq-transactional-message-processing.html
7 ответов
Необходимо учитывать несколько моментов:
- Во-первых, проверка не так много значит, потому что HTML-страница вполне может быть действительным, но плохо написанным, недоступным и т. д. См. Скажите нет «Valid HTML» значки и Отправка XHTML как text / html считается вредной (в отношении тестов hobo-web, упомянутых в другом ответе)
- Учитывая это, я настоятельно рекомендую использовать новый DOCTYPE: единственная причина, по которой он присутствует в HTML5, заключается в том, что это самая маленькая вещь, которая запускает стандартный режим в браузерах, поэтому, если вам нужен стандартный режим, используйте его; у вас практически нет причин использовать другой, подробный, подверженный ошибкам DOCTYPE
- Что касается улучшений форм, вы можете использовать библиотеку Weston Ruter webforms2 JS, чтобы перенести ее в незнакомые браузеры
- и, наконец, об атрибутах
data - *, это а) работает во всех браузерах (если вы используетеgetAttribute ()), б) все же лучше, чем злоупотреблениеtitleилиclassатрибуты и c) выиграл ' не беспокоит вас проверкой, поскольку мы говорили ранее, что проверка не , которая важна (конечно, это так, но не имеет значения, что ваша страница недействительна, если ошибки достоверности являются преднамеренными; и вы уже можете используйте валидацию HTML5 в валидаторе W3C, так что ...); так что нет никаких реальных причин не использовать их.
Если ваша страница сильно зависит от размещения в поисковых системах, возможно, стоит учесть, что некоторые системы отдают приоритет проверке HTML (Источник: http://www.hobo-web.co .uk / seo-blog / index.php / official-google-prefers-valid-html-css / ).
Кроме того, стоит учитывать, что полагаясь на новые элементы ввода даты (например, в Opera, возможно, другие) обеспечивает большее удобство со стороны разработчика, как правило, исключает включение более сложных элементов управления Javascript, которые лучше подходят для серверов старых браузеров (обычно возвращаются к простому текстовому полю ввода).
Конечно и как всегда , не полагайтесь на проверки на стороне браузера и проверяйте все стороны сервера ввода.
Хороший вопрос!
Короче говоря: это зависит от вашего контекста и толерантности к риску :)
Немного длиннее:
Я думаю это всегда хорошо чтобы раздвинуть границы для скорейшего внедрения технологий. Это дает вам преимущество перед опоздавшими в коммерческом мире, а также дает вам гораздо больше рычагов влияния на технологию по мере ее появления.
Если вы не хотите переписывать код или обновлять исходный код , то раннее усыновление может быть не для вас. Совершенно респектабельно захотеть написать надежный, стабильный код, который никогда не должен изменяться, но это полностью зависит от вас (и вашего бизнес-контекста)
См. Принцип устойчивости :
В RFC 761 (Управление передачей Протокол, 1980) Американский компьютер ученый Джон Постел подвел итоги более ранние сообщения желаемого критерии совместимости для Интернет-протокол (см. IEN 111 1 , RFC 760) следующим образом:
Реализации TCP должны следовать общий принцип устойчивости: быть консервативен в том, что ты делаешь, будь либеральный в том, что вы принимаете от другие .
Итак, имхо, №
Пожалуйста, не используйте новые функции, пока не сможете протестировать их хотя бы в одном браузере. Например, если вы используете функции формы Now, обязательно протестируйте в Opera. В противном случае вы, вероятно, нанесете больше вреда, чем пользы, внося свой вклад в отравленное наследие.
Если функция уже реализована в браузерах, и вы проводите тестирование с этими браузерами, пожалуйста, используйте новые функции.
См. Также более старый ответ .
Я не буду внедрять новые функции из HTML, пока они не получат поддержку хотя бы всеми основными браузерами.
Клиентов не волнует, действительна ли ваша страница, они гораздо больше заботиться, если он работает в кросс-браузере. Даже если мы будем бороться за внедрение новейших стандартов, останутся клиенты и компании, которые никогда не откажутся от IE6, и IE6 еще какое-то время будет в их списке требований к браузерам.
Новые типы форм приветствуются, но формы должны быть проверены на стороне сервера.
Переход на HTML5 существующих документов потребует больших усилий и адаптации и, по моим оценкам, не произойдет в одночасье. Ожидайте как минимум 3 года, пока он не станет популярным.
Я бы использовал HTML 5 только для развлечения и обучения, но определенно я бы не стал трогать какой-либо из моего производственного кода (существующего кода) с этим новым стандартом, по крайней мере, сейчас и пока я не веская причина поддержать этот шаг.