Ошибка в css как найти

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

Что такое валидность кода

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

Для этого есть специальные стандарты: если им следовать, страницу будут корректно распознавать все браузеры и гаджеты. Такой стандарт разработал Консорциумом всемирной паутины — W3C (The World Wide Web Consortium). HTML-код, который ему соответствует, называют валидным.

Валидность также касается файлов стилей — CSS. Если в CSS есть ошибки, визуальное отображение элементов может нарушиться.

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

Чем ошибки в HTML грозят сайту

Типичные ошибки кода — незакрытые или дублированные элементы, неправильные атрибуты или их отсутствие, отсутствие кодировки UTF-8 или указания типа документа.

Какие проблемы могут возникнуть из-за ошибок в HTML-коде

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

Как валидность кода влияет на SEO

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

Почитать по теме:
Главное о микроразметке: подборка знаний для веб-мастеров

Представитель Google Джон Мюллер говорил о валидности кода:

«Мы упомянули использование правильного HTML. Является ли фактором ранжирования валидность HTML стандарту W3C?

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

— Если у сайта действительно битый HTML, тогда нам будет очень сложно его отсканировать и проиндексировать.
— Иногда действительно трудно подобрать структурированную разметку, если HTML полностью нарушен, поэтому используйте валидатор разметки.
— Другой аспект касается мобильных устройств и поддержки кроссбраузерности: если вы сломали HTML, то сайт иногда очень трудно рендерить на новых устройствах».

Итак, критические ошибки в HTML мешают

• сканированию сайта поисковыми ботами;
• определению структурированной разметки на странице;
• рендерингу на мобильных устройствах и кроссбраузерности.

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

Как проверить код на валидность

Не нужно вычитывать код и считать символы — для этого есть сервисы и инструменты проверки валидности HTML онлайн.

Что они проверяют:

• Синтаксис
  Синтаксические ошибки: пропущенные символы, ошибки в написании тегов.
• Вложенность тэгов
  Незакрытые и неправильно закрытые теги. По правилам теги закрываются также, как их открыли, но в обратном порядке. Частая ошибка — нарушенная вложенность

  .

• DTD (Document Type Definition)
  Соответствие кода указанному DTD, правильность названий тегов, вложенности, атрибутов. Наличие пользовательских тегов и атрибутов — то, чего нет в DTD, но есть в коде.

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

Валидаторы не всегда правы — некоторые ошибки не мешают браузерам воспринимать код корректно, зато, к примеру, минификация сокращает длину кода, удаляя лишние пробелы, которые не влияют на его отображение.

Почитать по теме:
Уменьшить вес сайта с помощью gzip, brotli, минификации и других способов

Поэтому анализируйте предложения сервисов по исправлениям и ориентируйтесь на здравый смысл.

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

HTML и CSS валидаторы — онлайн-сервисы для проверки кода

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

Валидатор от W3C

Англоязычный сервис, онлайн проверяет соответствие HTML стандартам: можно проверить код по URL, залить файл или вставить код в окошко.

Инструмент покажет список ошибок и предупреждений с пояснениями — описанием ошибки и ее типом, а также укажет номер строки, в которой нужно что-то исправить. Цветом отмечены типы предупреждений и строчки с кодом.

Валидатор CSS от W3C

Инструмент от W3C для проверки CSS, есть русский язык. Работает по такому же принципу, анализирует стили на предмет ошибок и предупреждений. Первым идет блок ошибок, предупреждения собраны ниже отдельно.

---

Исправления ошибок и валидации HTML и CSS может быть недостаточно: всегда есть другие возможности испортить отображение сайта. Если что-то не работает, как надо, проведите полноценный аудит, чтобы найти ошибки.

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

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

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

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

Базовый пример

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

Предположим, у нас есть сетка из карточек, которая является распространенным шаблоном в сети. У вас есть изображение, которое должно иметь такую же ширину, что и его родительский элемент (карточка). Для этого вы добавили к изображению следующее правило CSS:

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

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

Мы действительно хотим получить это? Это похоже на макет Mansory, но цель этого макета — ограничить компоненты карточек определенным размером. Карточки не должны быть выше друг друга. Вот быстрое решение этой проблемы:

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

Как видите, добавление height частично решило проблему и привело к тому, что высота компонентов была одинаковой. Однако это вызвало еще более серьезную проблему — сжатие вертикального изображения. Как фронт-энд разработчик, вы обязаны задавать множество вопросов, которые позволят вам понять, как именно должен работать и вести себя компонент.

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

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

А теперь давайте посмотрим, как исправить проблему. Применяя object-fit: cover к изображению, мы можем гарантировать, что изображение не будет сжато.

Я знаю, что размеры изображений должны быть одинаковыми, но добавление object-fit может предотвратить нежелательные проблемы в будущем. И, наконец, вопрос, над которым я должен подумать: можно ли скрыть некоторые части изображения? Использование object-fit не сделает изображение сжатым, но, с другой стороны, оно изменит размер изображения, чтобы оно соответствовало указанной ширине и высоте, и это может скрыть некоторые его части.

Вот как будет выглядеть высокое изображение с object-fit: cover.

Обратите внимание, что некоторые части второго изображения скрыты. Это ожидается, и это можно решить, изменив свойство object-position следующим образом:

Хотя это решает проблему, это непрактично. Мы не можем добавить определенное object-position для каждой миниатюры в проекте.

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

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

Размещение раскрывающегося меню

Сколько раз вам нужно было добавить настраиваемое раскрывающееся меню в компонент заголовка? Я думаю, вы делали это раньше.

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

Раскрывающийся список располагается в 40px от верхнего края родительского элемента навигации. Хотя с этим нет проблем, в будущем это может вызвать побочные эффекты. Предположим, вы получили запрос на уменьшение высоты заголовка. В зависимости от того, как вы реализовали навигацию, вам необходимо либо уменьшить вертикальный отступ элемента навигации, либо уменьшить высоту заголовка.

Вы сделали именно это, но забыли проверить, работает ли раскрывающееся меню должным образом или нет. К сожалению, это не так.

Это потому, что свойство top имеет фиксированное значение. Лучший способ сделать это — использовать процентное значение. Таким образом, раскрывающийся список останется на своем месте независимо от высоты навигации.

Очень хорошее понимание основ CSS может помочь избежать такой ситуации. Использование фиксированного значения для свойства top является ошибкой и не является чем-то, на что можно положиться.

Заменяемые в HTML элементы

Согласно MDN: Заменяемые элементы — это элементы, на содержимое которых не влияют стили текущего документа. С помощью CSS можно изменить положение заменяемого элемента, но не содержимое самого заменяемого элемента.

Абсолютно позиционированное изображение

Примером заменяемого элемента является HTML img. Я хочу рассмотреть менее известные факты, касающиеся его. Предположим, что у нас есть изображение, которое абсолютно позиционировано относительно своего контейнера, но без установки width и height.

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

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

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

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

Изображение, как флекс-элемент

Если вы хотите получить оболочку, содержащую несколько изображений, то с этим также может быть сложно справиться с помощью Flexbox. Предположим у нас есть следующие HTML и CSS:

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

По умолчанию флекс-элементы не сжимаются меньше минимального размера содержимого (длины самого длинного слова или элемента фиксированного размера). Чтобы изменить это, установите свойство min-width или min-height.

Это означает, что нам нужно заставить флекс-элемент сжиматься меньше минимального размера содержимого, используя min-width (потому что flex-direction в нашем случае равно row).

Вот и все. Мы узнали основную причину проблемы, просто прочитав спецификацию CSS и узнав, как все работает под капотом.

Переполнение и Inline-Block элементы

Я объяснил эту концепцию в своей статье Переполнение в CSS.

У нас есть три элемента inline-block, и один из них имеет overflow: hidden. Вы заметите, что кнопка с overflow: hidden не выровнена по базовой линии других элементов.

Согласно спецификации CSS: Базовая линия ‘inline-block’ — это базовая линия его последнего встроенного блока в нормальном потоке, если только он не имеет встроенных блоков в потоке или если его свойство ‘overflow’ имеет вычисленное значение, отличное от ‘visible’, в этом случае базовая линия — это край нижнего поля.

Мне повезло, что Гаэль Пупар упомянул меня в этой проблеме на github в репозитории Bootstrap. Я должен был увидеть вышеупомянутую проблему в реальной жизни!

На странице результатов поиска строка запроса может варьироваться от одного слова до предложения. По какой-то причине в приведенном ниже дизайне строка должна быть ограничена определенной шириной. Для этого автор добавил следующий CSS:

С этим у нас проблема. Строка запроса не выровнена со смежными элементами. См. рисунок ниже:

Без хорошего понимания CSS и тщательного исследования вы можете подумать, что это проблема, связанная с браузером или что-то в этом роде. На самом деле, это естественно. Вот краткое сравнение трех основных браузеров:

Как вы заметили, Chrome и Firefox дают одинаковый результат. С другой стороны, Safari показывает другой результат. Вы можете подумать вслух так: «О, это работает в Safari. Тогда проблема в Chrome и Firefox», и затем вы тратите часы на исследование, чтобы наконец обнаружить, что Safari реализует поведение неправильно.

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

Теперь, когда мы знаем первопричину, вот подходящее решение:

Я только добавил vertical-align: top, и проблема решилась мгновенно.

Расстояние между смежными элементами

Вы работали над созданием веб-сайта и получили отзывы от ведущего дизайнера о том, что расстояние между кнопками непоследовательно. Это 22px вместо 16px. При проверке CSS получается следующее:

Вы определили, что интервал равен 16px, но если вы измеряете его в браузере, он больше. Если вы торопитесь, вы можете просто уменьшить поде и сделать его 10px в CSS, а в браузере оно станет 16px. Если вам повезет, дизайнер может не заметить, что вы здесь сделали, но это плохое решение.

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

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

Заключение

Для вас как для фронт-энд разработчика важно найти первопричину ошибки в CSS. Вот что вы получите, решив проблему с нуля:

Автор: Ahmad Shadeed

Источник: ishadeed.com

Редакция: Команда webformyself.

Ошибки в HTML-коде способны повлечь за собой некорректное отображение ресурса в выдаче, стать причиной сбоев в поисковом продвижении и работе сайта. Избежать таких неприятностей можно, соблюдая валидность кода. HTML-код, выполненный в соответствии со стандартом W3C (TheWorldWideWebConsortium), называют валидным. Главная задача верстальщика –обеспечить кроссплатформенную (кроссбраузерную) верстку согласно этому стандарту. Валидность касается и файлов стилей – CSS. Ошибка в CSS приводит к визуальному искажению элементов.

Чем страшны для сайта ошибки в HTML

Наиболее частыми ошибками в HTML-коде являются дублированные или незакрытые элементы, некорректные атрибуты или их отсутствие, а также отсутствие указания типа документа или кодировки UTF-8. Следствием таких ошибок может стать:

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

Влияние валидности кода на SEO

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

Эти варианты имеют косвенное влияние на трафик и позиции ресурса в выдаче.

По мнению представителя Google, Джона Мюллера, сайты с битым HTML-кодом сложнее сканировать и индексировать. Если код нарушен и сложно подобрать структурированную разметку, рекомендуется использовать валидатор разметки. Что касается поддержки кроссбраузерности и мобильных гаджетов, при сломанном коде сайт сложно рендерить на новых устройствах.

Итак, проблемы, вызванные критическими ошибками в HTML, касаются:

• сканирования сайта ботами,
• структуры разметки веб-страниц;
• рендеринга на мобильных гаджетах;
• кроссбраузерности.

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

Как проверить HTML-код на валидность?

Вам не нужно самостоятельно вычитывать код и подсчитывать символы – для этого существуют инструменты и сервисы проверки HTML-кода онлайн.

В их задачи входят:

• Проверка синтаксиса. Поиск синтаксических ошибок – пропущенных символов, ошибок в тегах;
• Анализ вложенности тегов. Поиск неправильно закрытых или незакрытых тегов. Теги должны закрываться в обратном порядке тому, как открывались. Нарушенная вложенность – одна из самых частых ошибок;
• Проверка DTD (DocumentTypeDefinition). Анализируется соответствие кода указанному DTD, вложенности, атрибутов тегов. Присутствие пользовательских атрибутов и тегов – то, что отсутствует в DTD, но имеется в коде.

Результаты проверки сервисов выводятся в виде:

• Ошибок. Лишние, пропущенные символы, опечатки в коде, способные стать причиной проблем в работе ресурса;
• Предупреждений. Ненужные символы, лишняя разметка и другие ошибки, не имеющие потенциальной опасности для сайта, но не отвечающие принятому стандарту.

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

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

ТОП-5 валидаторов кода HTML и CSS

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

Мы действительно хотим получить это? Это похоже на макет Mansory, но цель этого макета — ограничить компоненты карточек определенным размером. Карточки не должны быть выше друг друга. Вот быстрое решение этой проблемы:

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

Как видите, добавление height частично решило проблему и привело к тому, что высота компонентов была одинаковой. Однако это вызвало еще более серьезную проблему — сжатие вертикального изображения. Как фронт-энд разработчик, вы обязаны задавать множество вопросов, которые позволят вам понять, как именно должен работать и вести себя компонент.

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

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

А теперь давайте посмотрим, как исправить проблему. Применяя object-fit: cover к изображению, мы можем гарантировать, что изображение не будет сжато.

Я знаю, что размеры изображений должны быть одинаковыми, но добавление object-fit может предотвратить нежелательные проблемы в будущем. И, наконец, вопрос, над которым я должен подумать: можно ли скрыть некоторые части изображения? Использование object-fit не сделает изображение сжатым, но, с другой стороны, оно изменит размер изображения, чтобы оно соответствовало указанной ширине и высоте, и это может скрыть некоторые его части.

Вот как будет выглядеть высокое изображение с object-fit: cover.

Обратите внимание, что некоторые части второго изображения скрыты. Это ожидается, и это можно решить, изменив свойство object-position следующим образом:

Хотя это решает проблему, это непрактично. Мы не можем добавить определенное object-position для каждой миниатюры в проекте.

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

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

Размещение раскрывающегося меню

Сколько раз вам нужно было добавить настраиваемое раскрывающееся меню в компонент заголовка? Я думаю, вы делали это раньше.

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

Раскрывающийся список располагается в 40px от верхнего края родительского элемента навигации. Хотя с этим нет проблем, в будущем это может вызвать побочные эффекты. Предположим, вы получили запрос на уменьшение высоты заголовка. В зависимости от того, как вы реализовали навигацию, вам необходимо либо уменьшить вертикальный отступ элемента навигации, либо уменьшить высоту заголовка.

Вы сделали именно это, но забыли проверить, работает ли раскрывающееся меню должным образом или нет. К сожалению, это не так.

Это потому, что свойство top имеет фиксированное значение. Лучший способ сделать это — использовать процентное значение. Таким образом, раскрывающийся список останется на своем месте независимо от высоты навигации.

Очень хорошее понимание основ CSS может помочь избежать такой ситуации. Использование фиксированного значения для свойства top является ошибкой и не является чем-то, на что можно положиться.

Заменяемые в HTML элементы

Согласно MDN: Заменяемые элементы — это элементы, на содержимое которых не влияют стили текущего документа. С помощью CSS можно изменить положение заменяемого элемента, но не содержимое самого заменяемого элемента.

Абсолютно позиционированное изображение

Примером заменяемого элемента является HTML img. Я хочу рассмотреть менее известные факты, касающиеся его. Предположим, что у нас есть изображение, которое абсолютно позиционировано относительно своего контейнера, но без установки width и height.

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

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

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

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

Изображение, как флекс-элемент

Если вы хотите получить оболочку, содержащую несколько изображений, то с этим также может быть сложно справиться с помощью Flexbox. Предположим у нас есть следующие HTML и CSS:

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

По умолчанию флекс-элементы не сжимаются меньше минимального размера содержимого (длины самого длинного слова или элемента фиксированного размера). Чтобы изменить это, установите свойство min-width или min-height.

Это означает, что нам нужно заставить флекс-элемент сжиматься меньше минимального размера содержимого, используя min-width (потому что flex-direction в нашем случае равно row).

Вот и все. Мы узнали основную причину проблемы, просто прочитав спецификацию CSS и узнав, как все работает под капотом.

Переполнение и Inline-Block элементы

Я объяснил эту концепцию в своей статье Переполнение в CSS.

У нас есть три элемента inline-block, и один из них имеет overflow: hidden. Вы заметите, что кнопка с overflow: hidden не выровнена по базовой линии других элементов.

Согласно спецификации CSS: Базовая линия ‘inline-block’ — это базовая линия его последнего встроенного блока в нормальном потоке, если только он не имеет встроенных блоков в потоке или если его свойство ‘overflow’ имеет вычисленное значение, отличное от ‘visible’, в этом случае базовая линия — это край нижнего поля.

Мне повезло, что Гаэль Пупар упомянул меня в этой проблеме на github в репозитории Bootstrap. Я должен был увидеть вышеупомянутую проблему в реальной жизни!

На странице результатов поиска строка запроса может варьироваться от одного слова до предложения. По какой-то причине в приведенном ниже дизайне строка должна быть ограничена определенной шириной. Для этого автор добавил следующий CSS:

С этим у нас проблема. Строка запроса не выровнена со смежными элементами. См. рисунок ниже:

Без хорошего понимания CSS и тщательного исследования вы можете подумать, что это проблема, связанная с браузером или что-то в этом роде. На самом деле, это естественно. Вот краткое сравнение трех основных браузеров:

Как вы заметили, Chrome и Firefox дают одинаковый результат. С другой стороны, Safari показывает другой результат. Вы можете подумать вслух так: «О, это работает в Safari. Тогда проблема в Chrome и Firefox», и затем вы тратите часы на исследование, чтобы наконец обнаружить, что Safari реализует поведение неправильно.

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

Теперь, когда мы знаем первопричину, вот подходящее решение:

Я только добавил vertical-align: top, и проблема решилась мгновенно.

Расстояние между смежными элементами

Вы работали над созданием веб-сайта и получили отзывы от ведущего дизайнера о том, что расстояние между кнопками непоследовательно. Это 22px вместо 16px. При проверке CSS получается следующее:

Вы определили, что интервал равен 16px, но если вы измеряете его в браузере, он больше. Если вы торопитесь, вы можете просто уменьшить поде и сделать его 10px в CSS, а в браузере оно станет 16px. Если вам повезет, дизайнер может не заметить, что вы здесь сделали, но это плохое решение.

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

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

Заключение

Для вас как для фронт-энд разработчика важно найти первопричину ошибки в CSS. Вот что вы получите, решив проблему с нуля:

Автор: Ahmad Shadeed

Источник: ishadeed.com

Редакция: Команда webformyself.

Ошибки в HTML-коде способны повлечь за собой некорректное отображение ресурса в выдаче, стать причиной сбоев в поисковом продвижении и работе сайта. Избежать таких неприятностей можно, соблюдая валидность кода. HTML-код, выполненный в соответствии со стандартом W3C (TheWorldWideWebConsortium), называют валидным. Главная задача верстальщика –обеспечить кроссплатформенную (кроссбраузерную) верстку согласно этому стандарту. Валидность касается и файлов стилей – CSS. Ошибка в CSS приводит к визуальному искажению элементов.

Чем страшны для сайта ошибки в HTML

Наиболее частыми ошибками в HTML-коде являются дублированные или незакрытые элементы, некорректные атрибуты или их отсутствие, а также отсутствие указания типа документа или кодировки UTF-8. Следствием таких ошибок может стать:

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

Влияние валидности кода на SEO

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

Эти варианты имеют косвенное влияние на трафик и позиции ресурса в выдаче.

По мнению представителя Google, Джона Мюллера, сайты с битым HTML-кодом сложнее сканировать и индексировать. Если код нарушен и сложно подобрать структурированную разметку, рекомендуется использовать валидатор разметки. Что касается поддержки кроссбраузерности и мобильных гаджетов, при сломанном коде сайт сложно рендерить на новых устройствах.

Итак, проблемы, вызванные критическими ошибками в HTML, касаются:

• сканирования сайта ботами,
• структуры разметки веб-страниц;
• рендеринга на мобильных гаджетах;
• кроссбраузерности.

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

Как проверить HTML-код на валидность?

Вам не нужно самостоятельно вычитывать код и подсчитывать символы – для этого существуют инструменты и сервисы проверки HTML-кода онлайн.

В их задачи входят:

• Проверка синтаксиса. Поиск синтаксических ошибок – пропущенных символов, ошибок в тегах;
• Анализ вложенности тегов. Поиск неправильно закрытых или незакрытых тегов. Теги должны закрываться в обратном порядке тому, как открывались. Нарушенная вложенность – одна из самых частых ошибок;
• Проверка DTD (DocumentTypeDefinition). Анализируется соответствие кода указанному DTD, вложенности, атрибутов тегов. Присутствие пользовательских атрибутов и тегов – то, что отсутствует в DTD, но имеется в коде.

Результаты проверки сервисов выводятся в виде:

• Ошибок. Лишние, пропущенные символы, опечатки в коде, способные стать причиной проблем в работе ресурса;
• Предупреждений. Ненужные символы, лишняя разметка и другие ошибки, не имеющие потенциальной опасности для сайта, но не отвечающие принятому стандарту.

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

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

ТОП-5 валидаторов кода HTML и CSS

Существует множество онлайн-сервисов для проверки кода. Представляем вашему вниманию подборку валидаторов от создателей стандартов.

1. Валидатор от W3C. Англоязычный онлайн-сервис, проверяющий соответствие HTML-кода стандартам W3C. Можно проверить код по URL, загрузить файл или вставить HTML-код в поле. Все ошибки и предупреждения будут подробно описаны и выделены цветом.
2. Валидатор CSS от WSC. Онлайн-инструмент для проверки CSS от разработчиков стандартов W3C. Сервис анализирует стили и выдает ошибки и предупреждения. Имеется русский язык.
3. WDG HTML Validator. Англоязычный сервис для проверки валидации кода. Анализирует по URL, позволяет загружать файл с кодом или вставлять код в поле проверки. Сервис может проверить сразу весь сайт или пакет ссылок. Ошибки выдаются списком, символы и строки выделяются, что упрощает поиск мест для исправлений.
4. FIND-XSS.NET. Онлайн-сервис для тех, кому сложно разобраться в W3C валидаторах. Имеет базовый набор инструментов для анализа веб-страниц. Простой и понятный в использовании ресурс.
5. Dr.Watson Validator. Еще один неплохой валидатор, который кроме проверки синтаксиса HTML, обеспечивает анализ ссылок, проверку количества слов в тексте, код ответа страниц, анализирует совместимость с поисковыми системами и так далее.

Можно проверять HTML-код с помощью браузерных плагинов таких, как, к примеру, HTML ValidationBookmarklet, HTML TidyBrowserExtension или WebDeveloper для Chrome, HTML Validator для Chrome и Firefox, W3C MarkupValidationService или Validator для Opera, для Safari-Zappatic.

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

Время на прочтение
6 мин

Количество просмотров 7.7K

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

Существуют некоторые инструменты, облегчающие выполнение указанных задач. Но давайте начнем с того, что понимается под «аудитом» CSS.

Аудит CSS — задача не из легких

Как правило, оценка качества кода включает в себя его анализ в поиске багов и других проблем, например, проблем с производительностью. Для большинства языков программирования концепция аудита кода проста: она работает или не работает. Но CSS — это особенный язык, большая часть ошибок которого игнорируется браузером. Один и тот же стиль можно применять совершенно по-разному. Это обуславливает сложность аудита CSS. И «сложность» — это еще мягко сказано.

Для обнаружения проблем с CSS мы можем использовать расширения в нашем любимом редакторе кода или какой-нибудь линтер. Однако, подчас этого бывает недостаточно. Мы по-прежнему будем иметь возможность использовать слишком большое количество цветов, определений шрифтов или z-index, что сделает CSS плохо поддерживаемым и нестабильным.

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

Инструменты разработчика в браузере

Давайте взглянем на инструменты разработчика для аудита CSS, предоставляемые барузером Google Chrome.

Для ручной проверки CSS существует инструмент Inspect (стрелка в квадрате в верхнем левом углу). С его помощью мы можем увидеть CSS, примененный к определенному элементу. А с помощью стрелки можно получить детальную информацию о цветах, шрифтах, размере и доступности.

Инспектор Grid и Flex

Интерфейс DevTools предоставляет много интересных возможностей, но моей любимой является инспектор Grid и Flex. Для того, чтобы его включить, необходимо перейти в настройки (шестеренка в верхнем правом углу), выбрать «Experiments» и «Enable new CSS Flexbox debugging features».

Данный инструмент можно использовать как для отладки проблем с макетом, так и просто для определения того, используется ли CSS Grid или Flexbox на странице.

CSS Overview

Инспектирование CSS позволяет получить базовую информацию об используемом на странице CSS. Рассмотрим более продвинутые инструменты разработчика.

Одним из таких инструментов является «CSS Overview». Для его включения необходимо перейти в настройки, выбрать «Experiments» и «CSS Overview». Для открытия панели CSS Overview можно нажать Ctrl/Cmd+Shift+P, ввести «css overview», выбрать «Show CSS Overview» и нажать «Capture overview». Данный инструмент суммирует CSS-свойства, такие как цвета, шрифты, проблемы с контрастностью, неиспользуемые объявления и медиа-запросы. Я, обычно, использую этот инструмент для получения общего представления о качестве CSS. Например, если на странице используется «50 оттенков серого» или слишком много определений шрифтов, это может свидетельствовать об отсутствии какого бы то ни было руководства по стилю.

Coverage panel

Инструмент «Coverage» (покрытие) показывает общее количество и процент кода, используемого на странице. Для его запуска следует нажать Ctrl/Cmd+Shift+P, ввести «coverage», выбрать «Show Coverage» и нажать на иконку обновления.

Для фильтрации CSS-файлов нужно ввести «.css» в «URL filter input». Обычно, я использую этот инструмент для понимания техники CSS, используемой на сайте. Например, если я вижу высокую степень покрытия, я могу предположить, что CSS-файл генерируется для каждой страницы в отдельности. Иногда это также помогает определить применяемую на сайте стратегию кэширования.

Rendering panel

Панель «Rendering» (рендеринг) — другой полезный инструмент. Для его использования снова нажимаем Ctrl/Cmd+Shift+P, вводим «rendering», выбираем «Show Rendering». У этого инструмента много настроек, но моими любимыми являются следующие:

• Paint flashing — показывает зеленые прямоугольники во время перерисовки. Может использоваться для определения областей, повторная отрисовка которых занимает слишком много времени
• Layout Shift Regions — показывает синие прямоугольники при смещении (сдвиге) макета. Для того, чтобы получить максимальную пользу от этой настройки, я устанавливаю «Slow 3G» во вкладке «Network». Иногда я записываю экран и смотрю видео в замедленном режиме для обнаружения сдвигов макета
• Frame Rendering Stats — показывает использование GPU и фреймов в режиме реального времени. Эта настройка помогает обнаружить проблемы с анимацией и прокруткой

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

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

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

Онлайн-инструменты

Specificity Visualizer

Specificity Visualizer показывает специфичность CSS-селекторов. Для его использования достаточно зайти на сайт, вставить CSS и нажать «Visualize it!».

Основной график показывает специфичность в зависимости от нахождения таблицы со стилями. Два других графика показывают правильное использование специфичности. Я часто использую этот инструмент для обнаружения «плохих» селекторов. Например, если я вижу много красных точек, значит, мой код не так хорош, как я думал. Проанализируем основной файл со стилями Хабра:

CSS Specificity Graph Generator

CSS Specificity Graph Generator — это похожий инструмент для визуализации специфичности. Он показывает немного другой график, позволяющий определить, как наши селекторы организованы с точки зрения специфичности. Общее правило гласит, что селекторы с большей специфичностью в таблице стилей должны указываться позже, чем селекторы с меньшей специфичностью.

CSS Stats

CSS Stats — еще один инструмент для анализа и визуализации таблиц стилей.

Все, что нужно сделать, это ввести адрес сайта и нажать Enter. Информация разделяется на логические секции, такие как количество цветов, шрифты, z-index, специфичность и т.д. Можно сделать скриншот для последующего сравнения.

Project Wallace

Одной из главных особенностей Project Wallace является то, что данный инструмент позволяет сравнивать и визуализировать изменения на основе импортов. Это означает, что мы можем видеть разницу между предыдущим и текущим состояниями нашего CSS. Это может быть очень полезным для демонстрации улучшения кодовой базы.

Инструменты CLI

Wallace

Одним из моих любимых инструментов (интерфейсов) командной строки является Wallace. После установки, введите wallace и название сайта. В терминал будет выведено все необходимое, что нужно знать о CSS, используемом на указанном сайте. Например, можно посмотреть, сколько раз используется !important или сколько id встречается в коде. «Плохой» код отмечается красным цветом.

Что мне нравится в этом инструменты, так это то, что он извлекает весь CSS, используемый на сайте, т.е. не только из внешних файлов, но также встроенный. Вот почему отчеты CSS Stats и Wallace не совпадают. Для работы Wallace требуется Python.

csscss

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

Другие полезные инструменты

• Color Sorter — сортирует цвета по сначала по оттенку, затем по насыщенности
• CSS Analyzer — анализирует строку CSS
• constyble — линтер для определения сложности CSS, основанный на CSS Analyzer
• Extract CSS — получение всего CSS, используемого на странице
• Get CSS — альтернатива Extract CSS
• uCSS — определение неиспользуемого CSS

Заключение

Ни один веб-проект не обходится без CSS. Поэтому его качеству следует уделять самое пристальное внимание. Не столь важно, что другие люди думают о вашем CSS, сколько то, что вы сами о нем думаете. Если ваш CSS хорошо написан и правильно организован, вы будете тратить меньше времени на его отладку и больше на разработку новых «фич».

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

А какие инструменты для аудита CSS вы используете в своей работе? Дайте знать в комментариях.

---

Облачные серверы от Маклауд идеально подходят для разработки и хостинга сайтов.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

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

Существует несколько уровней валидации кода, если это можно так назвать. Для старых сайтов это CSS Level 2.1  и для современных сайтов это стандарт CSS Level 3. Прогресс не стоит на месте и скоро появятся новые стандарты верстки, но мы пока будем опираться на последний, что есть на данный момент.

Для проверки сайта на валидность, надо воспользоваться сервисом проверки валидации. На данном сайте есть три варианта проверки. Можно указать ссылку сайта, загрузить файл css или вставить код непосредственно в форму.

Выбирайте подходящий для Вас вариант, а я расскажу как делал я.

Для начала я сделал проверку всего сайта и увидел следующий результат:

Я ожидал, что будут ошибки, но может чуть меньше по количеству ?

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

Вторая часть веб-мастеров твердит, что нужно строго придерживаться правил, потому что поисковые системы будут к такому сайту относиться более лояльно, чем к сайту с ошибками. Если в одном браузере отображается не так как в другом, то это уже проблема браузеров. С этим мнением, я тоже соглашусь. Теперь давайте объединим эти два мнения и сделаем один итог.

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

Теперь к делу: каждый сайт содержит кучу css файлов, для начала делаем тест всего сайта, записываем в каких файлах нашлись ошибки. После чего делаем отдельный тест для каждого из выписанных файлов, загружая их на сайт. Если заметили, то над проверкой сайта пишется строка с количеством ошибок, предупреждений и есть проверенный CSS. Вот именно проверенный CSS нам и нужен. В нем содержится уже чистый исправленный код. Копируем его и вставляем в Ваш файл.

Вставили, сохранили, смотрим как работает сайт, что в нем поменялось внешне может какие-то исчезли тени, объемные места или округления. Желательно это все проверять и просматривать в разных браузерах. Если что-то пошло не так, то валидный код после теста, можно вставлять частями и проверять работу сайта. Тем самым найдете, то слабое место и его тогда не меняйте.

Важно! Перед изменением файла, сделайте его копию.

Тут важно понимать, что ошибки будут как и у файлов темы, так и у файлов от плагинов. Мы можем исправить все, но как только произойдет обновление плагина, то все наши труды будут напрасны. Хочу заметить в моем случае из плагинов был задет только WP-Recall, остальные прошли без ошибок.

Мы создали дополнительно еще один стилевой файл, чтобы не изменять основной в случае обновления темы. После теста на валидность, я решил отказаться от обновлений данного шаблона и изменить его уже на свое усмотрение и исправить все ошибки валидности в нем. Чтобы больше не получать обновлений от данного шаблона нужно: в папке вашей темы найти файл style.css и заменить там имя темы на другое. Данные из созданного дополнительного стилевого файла, можно перенести в основой.

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

Смогли ли вы добиться такого же результата ? Хватило, ли у Вас терпения и усердия? Что вы думаете стоит ли вообще проходить тест на валидность CSS? Жду Ваших комментариев в данной статье.

С уважением, Виктор