У меня есть маленькая любимая мозоль, которой я собираюсь поделиться с вами. По вечерам, когда я заканчиваю новый учебник по CSS3 для Nettuts + — обычно во время прослушивания моих любимых песен Бибстера — я нажимаю «Опубликовать», а затем жду, чтобы увидеть, сколько времени займет, прежде чем читатель оставит комментарий, содержащий фразу, «Но это не подтверждает».
Спасибо за вклад!
Вот что нужно для проверки: это инструмент. Ничего больше; не меньше; просто инструмент.
Итак, вот что насчет валидации: это инструмент. Ничего больше; не меньше; просто инструмент. Однако, на первый взгляд, это имеет смысл, не так ли? Мы приравниваем валидацию к лучшим практикам, во многом как JavaScript и JSLint. Вдоль этой линии мышления, почему бы нам не получить идеальный 100% балл? Ну, в том-то и дело: мы делаем; Однако возникают проблемы, когда оценка имеет приоритет над нашей собственной логикой.
Подтверждение вашего дизайна
Чтобы проверить свою разметку и таблицы стилей, вы можете посетить:
Кроме того, вы можете установить полезную надстройку Firefox для веб-разработчиков , которая, помимо прочего, предлагает удобные ссылки «Проверка HTML» и «Проверка CSS», а также возможность проверки даже ваших локальных файлов.
На этом этапе будет создан отчет, в котором перечислены все ошибки, с которыми сталкивается валидатор. Но в этом и заключается загвоздка.
Проверка не имеет значения?
Точно нет. Я полагаю, что, особенно для тех, кто только врывается в эту отрасль, фраза «веб-сайтам не нужно проходить проверку» сбивает их с толку.
«Валидация — это ваша система раннего предупреждения о появлении ошибок на ваших страницах, которые могут проявляться интересными и трудно определяемыми способами. Когда браузер обнаруживает недопустимый HTML, он должен сделать обоснованное предположение относительно того, что вы хотели сделать, — и разные браузеры могут предлагать разные ответы «.
— Сообщество разработчиков Opera
Тем не менее, окончательный счет, на самом деле, не имеет значения .
Помните дни, когда мы (или, по крайней мере, некоторые из нас) вставляли эти кнопки проверки в footer наших сайтов? Как смешно; для кого они были? Посетители сайта? ха-ха; Надеюсь нет! Но вот в чем дело: тогда валидация на самом деле не была стандартом . 
Нет; на самом деле, если вы даже не удосужились проверить свои HTML и CSS, вы были передовым стандартом , чувак! Иногда легко забыть, что веб-стандарты — это относительно новая концепция.
Подтвердите, прежде чем спросить
Несколько лет назад, когда я принимал участие в форумах CSS, это никогда не заканчивалось неудачей: каждый раз, когда новый участник запрашивал помощь по странной проблеме с макетом, наш первый ответ обычно звучал примерно так: «Y, наш сайт не проверяется. Исправить ошибки, а затем вернуться к нам, если все еще есть проблемы. «Много раз, странные проблемы макета являются результатом незакрытых элементов, таких как div . В этих случаях проверка может оказать огромную помощь.
Так что изменилось? Проверка больше не нужна? Позволяет ли HTML5 писать ужасную разметку без раздумий? Является ли новый HTML5 doctype волшебным? Не за что. Валидация — это полезный инструмент, который позволяет нам определять пропущенные закрытые теги, лишние точки с запятой и т. Д. При этом окончательный результат на самом деле не имеет значения. Это не волшебное число — оно на 100% связывается с Архитектором за кулисами и дает ему указание использовать бонусные очки на вашем сайте. Эта оценка служит не более высокой цели, чем предоставление вам обратной связи. Это не способствует доступности и не указывает на лучшие практики. На самом деле, валидатор может вводить в заблуждение, так как он сигнализирует об ошибках , которые не являются ошибками, на любой стадии воображения. Валидатор HTML4 быстро устарел, но, к счастью, в W3C появился новый валидатор HTML5 (все еще экспериментальный), который значительно улучшен.
Теперь имейте в виду, что правильно сформированная разметка может повысить SEO; Тем не менее, нет никакой конкретной корреляции между SEO и оценкой.
HTML5 стандартизирует многие функции, которые некоторые браузеры поддерживают годами, такие как настраиваемые атрибуты (через префикс data- ) и атрибуты ARIA, которые не работают с валидатором HTML4 W3C.
При тестировании новых проектов обязательно проверяйте экспериментальную опцию валидатора HTML5 . С этой опцией вы можете использовать поддерживаемые свойства CSS3, пользовательские атрибуты data- и многое другое.
Как насчет 75% или выше?
Никогда, никогда не ставьте под угрозу использование новейших методов и селекторов CSS3 для проверки.
Что если мы стремимся набрать хотя бы 75% баллов? Я понимаю мышление, как я тоже так думал в одной точке; хотя, опять же, это не имеет значения. При проверке вашей основной целью должно быть определение того, где вы допустили ошибки. Валидация — это не игра, и, хотя может быть интересно проверить свои навыки, чтобы определить, насколько высоко вы можете получить свой счет, всегда имейте в виду: это не имеет значения. И никогда, никогда, никогда не ставьте под угрозу использование новейших методов, селекторов CSS3 и селекторов для проверки.
Грязный секрет браузеров заключается в том, что они никогда не выполняют проверку HTML в отношении DTD. Тип документа, который вы указали в верхней части документа, переключает синтаксический анализатор на определенный режим работы, но никакие операции не включают загрузку типа документа и проверку соответствия кода. Что это значит? Это означает, что базовый синтаксический синтаксический анализатор обрабатывает HTML, с исключениями, указанными для самозакрывающихся тегов и блочных и встроенных элементов (и я уверен, что и в других ситуациях).
— Николай Закас
Что не проверяет
В зависимости от параметров, которые вы указали перед проверкой вашего дизайна (HTML4 против HTML5), валидатор будет кричать, как ребенок, когда сталкивается:
- Взлом браузера
- Продавец-префиксы
- Пользовательские атрибуты
- Подлинные ошибки, такие как незамкнутые элементы
- Ария роли
Ааа, браузерные хаки … вы должны их использовать? Ответ на этот вопрос обсуждался до смерти, и он, безусловно, выходит за рамки этого урока; однако имейте в виду, что, например, использование взлома IE6 не подтвердит правильность.
По этой причине многие дизайнеры предпочитают использовать неразрывные методы.
Так:
|
1
2
3
4
|
/* Fails validation */
#myElement {
_position: relative;
}
|
становится:
|
1
2
3
4
|
/* Passes validation */
* html #myElement {
position: relative;
}
|
Причина такого подхода заключается в том, что если в будущем, скажем, Internet Explorer 10 также отобразит свойства с префиксом подчеркивания? В таких случаях ваш стиль только для IE6 (как вы думали) будет также применяться к IE10 и последующим версиям, предположительно. Теперь, правда в том, что этого никогда не произойдет, так как это сломает большое количество веб-сайтов. Тем не менее, этот метод ориентации на браузер действительно взломать. За исключением небольших или редких случаев, лучше использовать условную таблицу стилей или форму обнаружения функций для конкретных браузеров.
Поставщик префиксов
Хотя мы все можем согласиться с тем, что применение префиксов нескольких поставщиков к свойствам, все ради достижения, скажем, закругленных углов, невероятно утомительно, вы должны поблагодарить своих счастливчиков, что производители браузеров экспериментировали с этими технологиями, прежде чем их официально рекомендовали.
Если бы
webkitне экспериментировал с CSS-градиентами и если бы Mozilla не улучшил предложенный им синтаксис, градиенты не были бы столь широко поддержаны в современном поколении современных браузеров, как сегодня. Видите ли, браузеры играют огромную роль в формировании будущего Интернета.
|
1
2
3
4
5
6
|
.box {
background: #666;
background: -moz-linear-gradient(top, black, white);
background: — webkit-gradient(linear, left top, left bottom, from(black), to(white));
background: linear-gradient(top, black, white);
}
|
С учетом всего сказанного, использование этих префиксов поставщиков приведет к тому, что ваши таблицы стилей не пройдут валидацию. Но это нормально; не позволяйте этому беспокоиться
Изучите правила, чтобы вы знали, как правильно их нарушать.
К сожалению, даже сейчас многие дизайнеры предпочитают использовать в нашем примере выше изображения для создания градиентов — хотя бы для того, чтобы вернуть свой показатель валидации обратно к 100%. Если вы попали в этот лагерь: вы делаете это неправильно.
Использовать проверку …
- Для проверки на незамкнутые элементы HTML
- Чтобы проверить на опечатки
- Чтобы убедиться, что вы не пропустили точку с запятой
- Для душевного спокойствия
- Игра. Не тратьте время на 100%, когда вы точно знаете, что делаете. Тем не менее, используйте его, чтобы указать на свои ошибки.
- Всеобъемлющая проверка. Хотя он проверяет наличие ошибок, он не указывает на плохие практики, проблемы доступности и т. Д.
- Быть использованным в качестве оправдания, чтобы не использовать новейшие методы CSS3. Чем дольше вы говорите себе: «Я буду использовать это через несколько лет …», тем дальше вы будете отставать.
Проверка не является …
Вывод
Если вы берете только одну вещь из этой статьи, помните, что проверка — это просто инструмент. Как только вы компрометируете свою собственную логику и методы ради умиротворения и достижения бессмысленного результата, он перестает быть инструментом. Тем не менее, используйте его, и используйте его часто!