Валидацию W3C иногда сложно использовать, но с ее помощью можно увидеть ошибки, вызванные дизайном макета. Валидатор выдает множество ошибок и предупреждений, указывающих на то, что ваш XHTML еще не завершен и может некорректно работать в разных браузерах. Следующие десять тонких проблем сбоя поставили в тупик большое количество программистов, и мы расскажем вам, как их решить. Прежде чем начать эту статью, я расскажу о некоторых проблемах, на которые следует обратить внимание при использовании валидатора W3C. Не беспокойтесь о предупреждениях верификатора — если верификатор сообщает, что обнаружил 12 ошибок и 83 предупреждения, игнорируйте это и переходите к следующему шагу.
Исправляйте одну ошибку за раз. Работайте последовательно, сверху вниз, исправляя одну ошибку за раз. HTML просматривается в браузере сверху вниз, и эти ошибки отображаются в том же порядке.
Обновляйте код после каждого исправления, чтобы он снова стал действительным — небольшая ошибка часто может вызвать каскад ошибок по всей странице. Поэтому, если все сделано неправильно, «исправление ошибок» также может привести к большему количеству ошибок. Повторная проверка кода после каждого исправления гарантирует полное решение проблемы.
Зная приведенные выше основные исключения, давайте рассмотрим несколько причин, по которым дизайн макета недействителен.
1. Тег div не закрыт. Это одна из самых частых причин неудачного дизайна макета. Всегда удивляешься, когда узнаешь, как много тонких макетов терпят неудачу из-за этого. Опросы показывают, что открытые теги div являются одной из наиболее распространенных ошибок проектирования разделов и одной из самых сложных для диагностики. Валидатор иногда указывает на неправильный открывающий тег div, что можно сравнить с поиском иголки в стоге сена.
2. Неприятный тег embed В начале 1990-х годов браузеры Microsoft и Netscape начали распознавать нестандартные уникальные шрифты. К сожалению, это означает, что валидатор W3C еще не распознает некоторые ключевые теги HTML, такие как «встроить», хотя эти теги широко используются. Если вам действительно нужна строгая проверка DOCTYPE (типа документа), вы можете только отказаться от вложенности.
Если вам нужен одновременно эффективный макет и встроенные медиафайлы, вы можете попробовать метод Flash Satay.
3. Неправильное объявление DOCTYPE. Необъявление DOCTYPE или неправильное объявление DOCTYPE в начале файла также является распространенной ошибкой. Согласно общему опыту, Strict DOCTYPE — это высший уровень проверки, к которому стремятся все. Строгая проверка означает, что ваша веб-страница будет оптимально отображаться во всех браузерах. Строгий код декларации выглядит следующим образом:
4. Конечная косая черта. Если ваш веб-сайт не может быть проверен, вполне вероятно, что конечная косая черта отсутствует где-то в коде. Легко не заметить такие вещи, как косые черты в конце, особенно в таких элементах, как теги изображений. Например:
Это не имеет никакого эффекта в строгом DOCTYPE. Чтобы решить эту проблему, добавьте «/» в конце тега img.
5. Тег Align. Если для DOCTYPE установлено значение Transitional, вы будете использовать тег «align», но если вы более требовательны и хотите строгую проверку, вы увидите множество ошибок. Align — еще один тег, который нельзя использовать для дизайна макета. Вы можете попробовать использовать «float» или «text-align» вместо «align» для преобразования элементов.
6. JavaScript
Если объявлен Strict DOCTYPE, тег CDATA необходимо переопределить в JavaScript. Этот аспект процесса проверки ставит в тупик многих программистов, поскольку веб-сайты, как правило, используют встроенный JavaScript для рекламы и сценариев отслеживания. Если необходимо использовать JavaScript, вы можете добавить следующие теги до и после него:
7. Изображения требуют атрибута «alt». Возможно, вы не заметили, но изображения также являются потенциальным камнем преткновения для расширенной проверки. Помимо косой черты в конце, для расширенной проверки также требуется тег alt для описания изображения, например alt="Страшное изображение вампира".
Поисковые системы также полагаются на теги alt для идентификации изображений на веб-страницах, поэтому всегда полезно добавлять теги alt, несмотря ни на что.
8. Неизвестные данные объекта. Данные объекта — еще одна распространенная ошибка, влияющая на проверку. Мы можем рассмотреть возможность использования соответствующих символов кодировки для замены таких символов, как «&». Полный список данных символьных объектов в соответствующей кодировке, доступных в дизайне раздела XHTML.
9. Плохая вложенность. Вложенность означает, что элемент содержит элемент Sweet!
Легко перепутать порядок вложенных элементов. Например, начните сильный тег перед тегом div, но затем сначала закройте тег div. Это может не изменить макет раздела, но сделает дизайн вашего раздела недействительным.
10. Отсутствует тег «title». Хотя это кажется очевидной ошибкой, многие программисты (включая меня) часто пропускают тег «title» в разделе «head». Когда вы увидите сообщение «отсутствует обязательный подэлемент HEAD» (отсутствует обязательный подэлемент HEAD), вы обнаружите, что забыли добавить тег заголовка.