Комментарии:
- WebFarer — 19.04.2012 16:29
У меня нашлось 10 ошибок. И все ошибки в теме вордпресса, которую я установил. Буду исправлять. Кстати, я выбрал все-таки WordPress, благодаря твоему блогу.
- myblaze — 19.04.2012 18:13
Очень рад, что мой блог тебе помог, заходи еще! Буду писать много интересного. Удачи в развитии сайта!
- Femil — 20.04.2012 00:52
А вложенные страницы разве проверять не нужно?
- myblaze — 20.04.2012 08:44
Хм, я даже об этом и не задумывался, если честно. Вообще, т.к. я пользуюсь CMS WordPress, то страницы у меня имеют одинаковый код, т.к. все прописано в шаблоне. За исключением части с контентом (single.php). Ну вот, сейчас проверил для примера эту страницу и нашел 2 ошибки, но они в блоке addthis, поэтому мне до них не добраться к сожалению.
- Mayskiykot — 20.04.2012 10:27
У меня там вообще 145 Errors, 47 warning(s)…На что это влияет? У меня статьи в блоге индексируются через час после публикации, может лучше ничего не трогать, а? 🙂
- myblaze — 20.04.2012 11:25
Да можете и не делать. Я сделал просто потому что скучно было 🙂 Хотя все советуют чтоб код валидный был, но я тоже минусов особых не заметил.
- Femil — 20.04.2012 13:41
Я об этом и говорю.
У меня валидна лишь главная страница. До вложенных руки не доходят ((( — вроде и ничего особенного — легко поправить (кроме гуглплюс — тут я не в курсе, как трабл можно полечить), но все равно что-то никак…
Кстати, странно, что вы не упомянули в статье html validator как плагин для ФФ — очень удобная штуковина (впрочем, как и файрбаг)…
- myblaze — 20.04.2012 14:43
А я не пользуюсь Файрфоксом, пользуюсь Хромом и Оперой. Но спасибо за наводку, гляну аналоги этих плагинов для хрома 🙂
А по поводу валидности, у меня проблемы только с addthis, но я планирую от него отказаться и поставить кнопку твиттера, гуглоплюса и, может-быть вконтакта самостоятельно. Это очень легко, просто когда все работает, то менять все так лень)) Но сегодня себя пересилил и сделал поиск по блогу от Яндекса, а то стандартный вордпрессовский вообще ужасен был по крайней мере у меня. - Femil — 20.04.2012 15:05
У меня кнопки и так «вручную» вкинуты. Просто для гуглоплюса используется такой тег:
и валидатор считает его невалидным. И вот как это поправить я не знаю. Может, вы подскажете? - Femil — 20.04.2012 15:07
Забыла: для хрома аналоги этих плагинов есть.
А поиск стандартный неплох, так что менять есть смысл лишь если посетители им действительно часто пользуются… - myblaze — 20.04.2012 15:13
Femil, код не отобразился, его вордпресс порезал) А поиск у вас действительно нормальный, а у меня он вообще ужасный был, пришлось заменить)
- Femil — 20.04.2012 15:39
Дублирую код:
(использовать без пробелов).
В хедер ставится джаваскрипт — он валидный, а вот непосредственно кнопочка +1 (код выше — ставлю в сингл.пхп) вызывает у валидатора сомнения. Почему-то… - Femil — 20.04.2012 15:41
Код пропал даже в таком виде (((
напишу русскими, может поймете:
(г:плюсоне)(/г:плюсоне)
вместо круглых скобок — знаки больше-меньше (обрамление тегов) - myblaze — 20.04.2012 16:07
Мне сейчас нужно отлучиться, а как приду — соберусь с силами и уберу у себя addthis и сделаю все ручками, тогда и посмотрим что там с валидностью, хорошо? 🙂
- Femil — 20.04.2012 16:52
Мне не к спеху. Просто думала что вы знаете. Ну, если узнаете как решить проблему — поделить, пожалуйста =)
- Наталья — 25.10.2012 07:17
Дык и где ваши кнопки «поделиться» в соц.сетях? Статья очень интересная, но вы очен ькруты, если всего 12 ошибок… У меня более 121 и 94 варнинг! А как их править вообще ума не приложу. какие то строки показывает и где их искать, а саоме главное что делать? И куда, ы какое место вставлять код функшион? что такое пофиксить? Если можно чайнику на е-мейл ответьте пожалуйста или просигнальте, что ответили — я и сюда могу снова забежать. прост опотеряться боюсь 🙂
- Ксения Юрьевна — 10.02.2013 09:09
Для меня ваша статья очень полезна, сейчас проверю. Я уже пострадала от этого рел.из-за древовидных комментариев, убрала древовидные и исчез рел и дубли вместе с ним. Сейчас с картинками мучаюсь , пройду по вашей ссылке.
- Юлия — 29.05.2013 11:27
И у меня проблема! Пишет 64 Errors, 7 warning(s), а как его исправлять, не знаю. Я в основном вижу, что не нравится ему «шема», то есть тот шаблон для кулинарных рецептов, который я делала по гуглу. Подскажите, пожалуйста что делать? Я пыталась переводить в переводчике, но даже на русском не могу понять что и где убрать… Очень жду вашего ответа!
- myblaze — 29.05.2013 21:09
Юлия, покажите пациента, лучше на почту, она есть на странице контактов)
myblaze.ru
Инструменты для валидации веб-сайта
1. W3C markup validation service
Этот сервис поможет проверить валидность разметки веб-документов в форматах HTML, XHTML, SMIL, MathML и т. д. И позволит исключить необходимость использования дополнительных инструментов.
Какие проверки осуществляются:
- Анализ синтаксиса и стилей;
- Проверка сайта на ошибки онлайн.
2. CSS validator
Позволяет проверить код CSS и (X)HTML-документы с таблицами. Если нужно валидировать CSS, встроенный в (X)HTML-код, то сначала нужно будет проверить разметку.
3. Checklink
Проверяет ссылки и анкоры на отдельных веб-страницах или на целом сайте. Этот инструмент позволяет выявить проблемы, связанные со ссылками, анкорами и объектами в веб-странице, CSS-таблицами и т. д. Сначала убедитесь, что в проверяемых документах используется валидная (X)HTML-разметка и CSS-код.
4. Feed
Бесплатный сервис для W3C-валидации ленты рассылок (Feed), который позволяет проверить синтаксис Atom или RSS. Вы можете проверить сайт на ошибки по URL или с помощью прямого ввода кода.
5. Mobile checker
Инструмент позволяет проводить различные тесты веб-страниц для определения того, насколько они адаптированы под мобильные устройства. Тесты описаны в спецификации mobileOK Basic Tests 1.0. Веб-страница считается адаптированной, если проходит сразу все тесты.
6. HTML Validator
HTML Validator от WDG по функционалу напоминает сервис валидации от W3C. Основные отличия были исключены с выходом обновленной версии W3C-валидатора.
7. Watson’s site validation check
Dr. Watson – бесплатный сервис, который позволяет проверить сайт на ошибки онлайн. Укажите URL-адрес страницы, которую необходимо проверить, и Watson сразу же сделает ее копию. Он также умеет исследовать множество других аспектов сайта: валидность ссылок, скорость скачивания, оптимизация под поисковые системы и т. д. Многие функции совмещены в одну. Если требуется решение «все в одном», то этот инструмент вам точно пригодится.
Какие проводятся проверки:
- Скорость загрузки страницы;
- Анализ синтаксиса и стилей;
- Подсчет количества слов;
- Проверка орфографии;
- Проверка ссылок;
- Уровень оптимизации под поисковые системы;
- Проверка входящих ссылок;
- Проверка исходного кода.
8. XML well checker and validator
Эту форму можно использовать для проверки XML-документов на валидность. Инструмент проверяет и все подкрепленные внешние файлы на наличие синтаксических ошибок и находит лишние пробелы.
9. Robots checker
Инструмент позволяет проверить сайт на ошибки кода файла Robots.txt. Несмотря на то, что он может распознать как ошибки и некоторые ваши исключения, их тоже не мешало бы проверить. Простой, но мощный и многофункциональный инструмент.
10. URL checker
InternetSupervision™ — это сервис, который отслеживает доступность HTML, FTP, почтовых серверов (SMTP и POP3), наблюдает за производительностью сайта и транзакциями в интернет-магазине (включая активность некоторых форм на странице).
Инструменты для оценки и проверки универсального доступа
11. Webaccessibility checker
Этот инструмент умеет проверять отдельные HTML-страницы на соответствие стандартам универсального доступа.
12. Color contrast
Этот инструмент позволяет проверить контрастность и яркость цветов на переднем и заднем фоне всех DOM-элементов. Правильное сочетание цветов гарантирует, что текст будет виден даже людям с плохим зрением. AccessColor также помогает найти оптимальное сочетание цветов для HTML и CSS-документов.
13. Web accessibily evaluation tool-WAVE
WAVE – бесплатный инструмент для проверки доступности сайта. Вместо сложного технического отчета WAVE показывает исходный вариант страницы и использует специальные иконки и индикаторы, которые позволяют определить проблемные места.
14. Accessibility with style
HERA – инструмент для проверки доступности веб-страниц и их соответствия спецификации Web Content Accessibility Guidelines. HERA выполняет необходимый набор тестов на каждой странице, и автоматически определяет проблемные места.
15. Adobe PDF conversion
Этот сервис позволяет конвертировать любые веб-страницы на английском языке в PDF-документы. «Прогоняя» контент через этот инструмент, вы столкнетесь с тем, что Adobe временами будет испытывать сложности с доступом к тому или иному фрагменту.
Оценка производительности сайта
16. Pingdom tools
Инструмент для проверки сайта на наличие ошибок. Full Page Test загружает сразу HTML-страницу, включая все объекты (изображения, CSS, Javascript, RSS, Flash и фреймы). Затем он имитирует процесс загрузки страницы в веб-браузере, и подсчитывает, сколько времени уходит на загрузку того или иного объекта.
17. Webpage analyzer
Бесплатный инструмент для тестирования скорости работы сайта. Он подсчитывает размер отдельных элементов и компонентов веб-страницы каждого типа. В зависимости от характеристик страницы, скрипт предлагает варианты оптимизации скорости работы сайта.
Проверка кросс-браузерности
18. Browser shots
Позволяет проверить сайт на наличие ошибок. Browsershots делает скриншоты вашего дизайна в различных операционных системах и браузерах. Это веб-приложение с открытым исходным кодом, которое предлагает разработчикам удобный способ тестирования сайтов на совместимость с браузерами. Адрес будет добавлен в очередь сразу после того, как вы введете его. После этого сервис сделает все необходимые скриншоты и загрузит результаты.
19. IE net renderer
IE NetRenderer позволяет проверить, как отображается сайт в Internet Explorer 7, 6 или 5.5.
20. Viewlike
Этот инструмент позволяет проверить, как выглядит сайт при различных разрешениях. Инструмент работает на основе Ajax и PHP, а это значит, что вам не придется ничего скачивать. Введите нужный URL-адрес и получите результат.
А какими инструментами для тестирования сайтов пользуетесь вы? Пожалуйста, поделитесь в комментариях!
Перевод статьи “Website Validation and Testing: 20 Online Tools” был подготовлен дружной командой проекта Сайтостроение от А до Я.
www.internet-technologies.ru
Как проверить валидность кода сайта?
Для того, чтобы проверить код на предмет его структурированности и чистоты (валидности), следует воспользоваться одним из множества онлайн чекеров (валидаторов). На официальном сайте Консорциума Всемирной Паутины также можно проверить валидность кода сайта:
validator.w3.org на валидность HTML и jigsaw.w3.org/css-validator на валидность CSS.
Сервис validator.w3.org дает возможность проверить валидность языка разметки гипертекста сайта одним из трех предложенных способов:
- Validate by URI — проверка валидности HTML по адресу веб-страницы;
- Validate by File Upload — проверка валидности HTML загруженного документа;
- Validate by Direct Input — проверка валидности фрагмента HTML-кода.
Для того, чтобы выбрать нужный способ проверки валидности кода, нужно всего лишь переключиться на соответствующую вкладку:
Ниже на наглядном примере я продемонстрирую результаты проверки на валидность такого популярнейшего в среде разработчиков и сеошников ресурса, как Хабрахабр. Для этого в соответствующее поле валидатора вставляем URL сайта и жмём на кнопочку CHECK. Вуаля! Всего лишь несколько секунд и валидатор выдает нам результат:
Результат очень даже приличный, поскольку при проверке на валидность подавляющего большинства сайтов будут сотни, а иногда и тысячи ошибок.
Как исправить ошибки кода?
Если при проверке валидности кода своего ресурса было найдено большое количество ошибок, то ни в коем случае не стоит расстраиваться. Хотя бы потомучто сайтов, полностью соответствующих правилам и стандартам W3C, не так уж много. И все ошибки можно довольно быстро исправить. И зачастую это можно сделать даже без посторонней помощи.
По окончанию проверки кода веб-страницы валидатор выдает список всех ошибок и угроз с детальными разъяснениями и инструкциями по их устранению. Все это сопровождается примерами, благодаря чему исправление ошибок кода не составит большого труда даже для новичка.
Влияет ли валидность кода на поисковое продвижение?
Валидность кода является одним из показателей качества сайта не только потому, что гарантирует ресурсу кроссбраузерность, увеличенную скорость загрузки и так далее. Дело в том, что чистый и структурированный HTML код является одной из важнейших составляющих грамотной внутренней оптимизации сайта. И причины этого вполне очевидны:
- поисковые системы в алгоритмах ранжирования при прочих равных условиях отдают предпочтение более качественным сайтам;
- валидный код легко и быстро обрабатывается, и вероятность его неверного прочтения поисковыми ботами минимальна.
Несомненно, работать над ошибками в коде нужно, но и ошибки могут быть разные, не все могут привести к плохому ранжированию сайта, если у вас не +100500 и более ошибок, то это не повод для беспокойства! Исправьте те, которые вы (как хозяин своего сайта) считаете наиболее опасными. Это лично моё мнение и оно может не разделять мнение кого либо из читателей.
А вот что Google думает о валидности кода сайтов. Официальная позиция поисковика относительно влияния валидности кода на поисковую оптимизацию представлена в этом коротеньком видео.
babosik.ru
Что такое валидатор?
Данные правила устанавливает консорциум W3С в который входят крупнейшие компании, такие как: Google, Microsoft, Opera, Mozilla, Apple, IBM и многие другие.
Зачем нужна валидация?
Необходимость валидации кода возникла тогда, когда веб-технологии начали развиваться очень быстрыми темпами. В CSS и HTML стало появляться множество возможностей и веб-разработчики, конечно же, их использовали для своих проектов, причем делали это кто как хотел.
Так же, стало появляться множество различных браузеров, которые могли по-разному отображать одни и те же элементы веб-страницы.
Консорциум W3C был создан для того, что бы как-то стандартизировать и прописать определенный свод правил и требований, прежде всего, к HTML и CSS коду.
То есть основная идея всех этих правил заключается в том, что если на вашем сайте нет никаких ошибок валидации, то он должен одинаково отображаться во всех браузерах, то есть быть кроссбраузерным. Но на самом деле это далеко не всегда так!
Так же, есть множество примеров, когда кроссбраузерные сайты, которые одинаково отображаются в разных браузерах, содержат в себе множество ошибок и предупреждений при проверке сайта на валидность.
В любом случае проверять сайт на валидность нужно, потому что это позволяет вам выявить некоторые очень грубые ошибки, которые, впоследствии, могут негативным образом сказаться на работе вашего сайта, на отображении его в различных браузерах и на разных устройствах.
Как проверить сайт на валидность?
Давайте посмотрим как выглядит проверка валидности HTML на практике.
Для проверки сайта на валидность кода нам понадобится сервис W3C Markup Validator.
Выглядит он следующим образом:
Здесь есть три вкладки:
На первой вкладке «Validate by URI» вы можете сразу же вставить адрес вашего сайта или какой-то его страницы.
На вкладке «Validate by file Upload» вы можете загрузить сюда файл HTML-страницы, который находится на вашем компьютере.
На вкладке Validate by Direct Input вы можете вставить готовый фрагмент кода который вы хотите проверить на ошибки.
Так как мы валидность сайта, то нам нужна будет вкладка «Validate by URI». В поле «Address» вставляем адрес проверяемого сайта и далее мы можем сразу же нажать на кнопку «Check», либо можем нажать на ссылку «More Options» и посмотреть, какие есть еще настройки у W3C валидатора.
Если у вас, в теле документа, не задана кодировка, что бывает очень редко, и, в принципе, этого быть не должно, то вы можете, в поле Character Encoding, выбрать кодировку вашего сайта вручную.
Так же если в теле вашего html-документа не задан атрибут DOCTYPE, то вы можете выбрать его из раскрывающегося списка Document Type. Здесь есть множество различных стандартов и вам нужно выбрать по правилам какого стандарта вы хотите проверять сайт на валидность.
Если вы ничего не понимаете в кодировках и доктайпах лучше здесь вообще ничего не трогать и оставить все по умолчанию.
В следующей строке вы можете настроить вывод результатов проверки валидатора W3C:
List Messages Sequentially – выводит все ошибки и предупреждения, возникающие при валидации последовательно.
Group Error Messages by Type – позволяет сгруппировать все ошибки валидации по типу.
Show Source – отображает исходный код страницы
Show Outline – отображение строки в которой валидатор нашёл ошибку.
Clean up Markup with HTML-Tidy – позволяет вывести строку с уже исправленной ошибкой, то есть правильным html-кодом. Это осуществляется при помощи программы HTML-Tidy, и консорциум W3C не дает никаких гарантий, что данный код будет на 100% правильный.
Validate error pages – позволяет проверить на валидность страницу 404, которая выдается в случае если человек вводит не правильный адрес страницы на сайте.
Verbose Output – позволяет вывести подробную информацию.
Я обычно здесь ничего не ставлю. Просто ввожу адрес сайта и нажимаю на кнопку «Check», а дальше смотрю на список ошибок и предупреждений, который возникают на проверяемом сайте.
После нажатия на кнопку «Check», отображается список ошибок и предупреждений, возникших в процессе проверки валидности HTML.
На данном сайте есть два предупреждения — они выделяются желтым цветом, и две ошибки – они выделяются красным цветом.
Как исправить ошибки валидации HTML?
Давайте посмотрим на саму структуру вывода предупреждений и ошибок.
В первой строке выводится текст самой ошибки, где указывается название определенных атрибутов, которые не понравились валидатору W3C и названия тегов, в которых они встречаются.
В данном предупреждении написано, что атрибут role со значением banner не является обязательным для элемента header.
Во второй строке указывается, с какой строки, и с какого столбца по какую строку, и какой столбец был найден фрагмент кода с ошибкой.
То есть, наш код начинается со строки 52 столбец 2, и заканчивается в строке 52 столбец 57.
В третей строке отображается, текст самого кода. Он выделенный желтым цветом.
В данном случае, для того чтобы исправить это предупреждение, нам нужно убрать атрибут role у тега header, потому что он здесь, в принципе, не нужен и вызывает предупреждение при проверке валидности.
Для этого мы можем открыть нашу страницу и найти строку 52 столбец 2. Но это далеко не всегда эффективно, потому что если ваш сайт на каком-то движке, то вся файловая часть сайта разбита на множество различных файлов шаблона и там все выводится при помощи php и найти там данную строку будет очень сложно.
Поэтому, мы берем и копируем строчку с данным кодом и затем находим ее в файлах шаблона темы и уже там исправляем.
Тоже самое касается всех остальных ошибок и предупреждений, найденных валидатором W3C.
Конечно же универсального рецепта по исправлению всех ошибок нет. Здесь нужно смотреть на то, какой у вас сайт, какие у вас используются элементы, в каких фрагментах кода выдаются те или иные ошибки.
Очень часто бывает так, что для организации, к примеру, галереи приходится для изображений этой галереи присваивать атрибуты rel, и потом, когда страница проверяется валидатором, он начинает на них ругаться. Но если эти атрибуты удалить, то галерея перестанет работать. При этом, данная ошибка вообще ни как не повлияет на отображение сайта в браузерах, но тем не менее она у вас будет, и здесь вам нужно будет просто выбирать, чего вы хотите больше: чистого валидного кода, либо красивую галерею на вашем сайте.
Нужно ли проверять сайт на валидность вообще?
Я для себя сделала следующий вывод:
Если же ошибки не значительные и их устранение повлечет за собой какие-то негативные последствия, то их можно спокойно оставить и ничего страшного здесь не произойдет, на кроссбраузерность сайта это не повлияет и на поисковой выдаче, с вероятностью 99%, это тоже не отобразится.
Видеоинструкция
Если у вас мало опыта в верстке и разработке сайтов, то, скорее всего, самостоятельно вы не сможете определить, какая ошибка валидации является грубой, а какая нет. Здесь лучше всего будет обратиться к специалисту либо за консультацией, либо с просьбой проверить ваш сайт на валидность с последующим исправлением ошибок.
Надеюсь, что у вас не возникнет проблем с валидатором и проверкой вашего сайта. Если у вас будут возникать какие-то вопросы – вы всегда их можете задать через форму комментариев.
На этом у меня все. Подписывайтесь на мою рассылку и на мой канал на YouTube и до встречи в следующих статьях.
С уважением Юлия Гусарь
impuls-web.ru
Проверка на валидность
Проверка на валидность — проверка на соответствие написанного кода определенному стандарту. Как товары или продукты проверяются на соответствие ГОСТ или ТУ, так и сайт проверяется на соответствие установленным стандартам.
Для чего нужна проверка на валидность
SEO-оптимизация: от корректности кода зависит понимание вашего сайта поисковыми роботами.
Проверка на синтаксис. Ошибки, сделанные в коде, зачастую мешают вашему сайту стать кроссбраузерным. Находя и исправляя их, вы защититесь от некорректного отображения в разных браузерах. Вы легко найдёте глупые ошибки: ошибка в теге, пропущенный символ и т.п
Проверка на вложенность и закрытость тегов: часто встречаются незакрытые или неправильно закрытые теги (например, вложенность <div>)
Валидатор — штука довольно строгая, и отлавливает даже те ошибки и недочёты, с которыми ваш сайт работает во всех браузерах. Однако валидация для HTML5 более мягкая, чем для HTML4, т.к. позволяет использовать пользовательские элементы, начинающиеся с data.
Проверять или нет
Важно помнить, что проверка на валидацию HTML еще не гарантирует полную работоспособность сайта, полную корректность его отображения, т.к. помимо html-кода в отображении большой вес имеет и правильно написанный CSS и программный код.
На html-валидность производить проверку однозначно стоит, особенно начинающим разработчикам, которые в силу отсутствия опыта делают множество ошибок.
Иногда проверка на валидность помогает отловить скрытую рекламу и вредоносный код.
Хотите научиться писать валидный код? Тогда приглашаем на бесплатный интенсив по основам программирования!
Чем проверять
HTML-валидатор W3C здесь. С помощью сервиса можно проверить код как по URL, так и загрузив кусок кода или полностью файл.
Если же по каким-то причинам постоянно заходить на сервис не удобно, можно воспользоваться плагином для браузера.
Css-валидатор проверяет таблицу стилей вашего сайта. Валидатор от W3C здесь. Логика работы идентична html-валидатору.
Ещё на валидность принято проверять ленты RSS и Atom. Сервис проверки.
geekbrains.ru
Проверка HTML кода на валидность
Вышеупомянутый онлайн-сервис проводит проверку HTML кода онлайн на всем сайте целиком. Вам нужно просто указать домен своего сайта и нажать кнопку «Check», так Вы запустите проверку HTML-кода сайта.
Также валидатор предоставляет одну очень интересную возможность — проверка файлов сайта с локального компьютера. На мой взгляд, этот инструмент пригодится тем, кто делает сайты на заказ. Перед сдачей заказа нужно все перепроверить, ведь хочется, чтобы твоей работой были всегда были довольны. Проверить файлы можно перейдя на вкладку «Validate by File Upload»:
Как исправить ошибки в HTML-коде?
Сервис Validator W3c указал мне на две ошибки и сделал 8 предупреждений. Попробую их исправить и за одно покажу Вам как это делается.
Исправляем ошибку «Element style not allowed as child of element div in this context. (Suppressing further errors from this subtree.)». Эта ошибка говорит мне о том, что в HTML-коде, а именно в теге <div> прописывать стили не нужно. Следовательно, стили, которые прописаны в данном блоке <div> нужно перенести в файл style.css и все.
Валидатор также указывает, где именно находиться ошибка:
Далее я проделываю следующее:
- Копирую выделенную желтым цветом кусочек кода в валидаторе W3c;
- Открываю исходный код страницы в браузере. Сделать это можно щелкнув правой кнопкой мыши на странице сайта и выбрав пункт «Посмотреть исходный текст» (для браузера Opera):
Исходный код откроется в новой вкладке. - Выполняю поиск по странице (CTRL+F) и вставляю в поисковую строку, скопированный в валидаторе, кусочек кода:Вот и показались те самые стили в блоке <div>. Теперь мы знаем, где примерно находится ошибка и к какому элементу относиться (в моем случае, это форма подписки), значит можно переходить в Notepad++;
- В текстовом редакторе Notepad++ я открываю файл с ошибкой и с помощью все того же поиска нахожу ошибку:
- Далее просто копирую эти стили и вставляю в файл style.css:
- Из файла index.html стили я удаляю и оставляю только самый необходимый HTML-код.
- Конечно же, отправляю файлы index.html и style.css на сервер, чтобы изменения вступили в силу.
Таким образом можно найти и исправить ошибки HTML кода. Но сайты состоят не только из кода разметки, но еще и CSS, поэтому проводим еще и проверку каскадных таблиц стилей веб-ресурса.
Проверка CSS кода на валидность
В валидаторе W3c также можно проверить CSS-код на валидность. Сделать это можно по этой ссылке. Принцип работы все тот же: указываете URL-сайта, либо выбираете файл на компьютере и нажимаете на кнопку «Проверить».
В отличии от того же валидатора HTML, валидатор CSS на русском.
Ошибки и предупреждения CSS
При проверке CSS кода на валидность, сервис выдает большое количество ошибок и предупреждений. У меня набралось 23 ошибки и аж 281 предупреждение. На первый взгляд может показаться, что это очень много и может даже напугать, однако большинство из указанных ошибок и предупреждений показываются только из-за того, что сервис не знает определенных свойств, которые применяются для разных браузеров.
В моем случае, большинство предупреждений из 281 — это CSS-свойства для нормального отображения в различных браузерах:
Сервис позиционирует подобные теги, как «неизвестное расширение поставщика». Поэтому если при проверке своих CSS-файлов, Вы видите большое количество таких ошибок, то не пугайтесь. Все нормально.
Перечислять наиболее распространенные ошибки и способы их устранения я не буду, так как решения у всех могут быть разными и нужно смотреть сам HTML-код, чтобы понять в чем дело.
Если Вы не можете устранить какую-то ошибку, то делитесь проблемой в комментариях к уроку, быть может найдем решение вместе.
Надеюсь, что уроки, которые выходили на протяжении этой недели были для Вас полезными и помогли в решении определенных проблем.
Ну а сейчас, до свидания!
context-up.ru
В этой статье я познакомлю с понятием «валидность» кода сайта ( html & css ). Надеюсь все помнят, html — это структура сайта. Css — правила и стили для тегов, которые описаны в html.
Будем разбираться с самых низов: теория, а далее перейдем к практике. Так же вы найдете ответы на следующие вопросы: что такое валидность html и css кода, зачем она нужна, почему поисковые системы любят чистый / валидный код. А самое то главное покажу на примерах как проводить проверку валидности кода сайта.
Зачем нужна проверка валидности html и css кода
Валидность — по-другому чистый код ( без ошибок )
Константа № 1. Валидность кода сайта позволяет правильно отображать сайт в разных браузерах т.е. вся визуальная и функциональная составляющая сайта отображается и работает правильно. Чаще всего получается, что браузер обрабатывает и отображает корректно все элементы сайта, но это не говорит о том, что код чист и гладок как попка младенца.
Константа № 2. Чистый код ( html и css ) поощряют поисковые машины ( Yandex, Google ). Говоря по-русски, когда робот поисковой машины приходит на ваш ресурс и видит что валидность соблюдена, то соответственно поисковой робот будет знать, что этот ресурс без ошибок, а значит к отношение к сайту в лучшую сторону.
Из личного опыта: В моей практике была ситуация, когда новые статьи на блоге ни в какую не хотели залетать в поисковую выдачу. Вроде делаешь то все правильно, ускоряешь индексацию а в выдаче Яндекса нет и все! Вот что делать, куда копать? Кто-то подумает фильтры — фильтры, но ничего такого нет.
Проверил сайт на валидность html кода, и как я был удивлен и понял где была собака зарыта. Оказалось что в коде отсутствовал закрывающий тег </noindex> , а это тег специальный который закрывает участки кода или ссылки от поисковой машины Яндекса. И что же получается у меня было? Вся статья закрыта от индексации. Вот и ответ на вопрос: «Почему в поисковой выдаче нет». Потом естественно я эту ошибку устранил.
Перейдем от голого текста с теорией к практике, и научимся проводить проверку валидации онлайн
Проверка html кода
Идем на ресурс validator.w3.org и вводим адрес вашего сайта вида: http://vashsait.ru и нажимаем кнопку «Check»
Если нужно например загрузить с компьютера файл на проверку, то используйте вкладку «Validate by File Upload». Если, вы хотите проверить отдельный участок кода, то кликаем на «Validate by Direct Input». Ниже привожу подсказки, и как выглядит само окно для работы ( можно увеличить )
В качестве примера, чтобы показать сам процесс выдачи ошибок возьму любой сторонний сайт, адрес которого останется за кадром =) на данном блоге ошибки убраны, а так бы показал на нем, смотрим что получаем при проверке html кода, заметьте что валидатор поддерживает и расширенные языки html такие как ( XHTML, HTML5 ).
На скрине ниже результат работы, Вам же теперь нужно будет вручную проверить каждый участок кода, где обнаружена ошибка. В качестве быстрого отлова и навигации по ошибкам используйте Линии, на которые указывает Валидотор.
Для правки кода, работайте ручками, если не разбираетесь html языке, то тогда задействуйте сторонних людей и силы для разрешения этих вопросов. Здесь я показываю как находить и исправлять ошибки, опытные люди, знающие код разберутся в два счета.
Проверка CSS кода
Сперва Вам понадобится определить абсолютное нахождение основного файла стилей css, который отвечает за внешний вид и расположение блоков вашей темы для блога или отдельной html страницы. Быстрый и простой способ: на главной странице своего сайта нажимаете комбинацию ( Ctrl + U ) — откроется исходный код страницы, либо правая кнопка мыши ( Посмотреть исходный код страницы )
Опишу частые случаи, чтобы вам было легче найти основной файл стилей css. Для быстрого поиска в исходном поиске нажмите комбинацию клавиш ( Ctrl + F ) а в поисковом поле введите ( style.css или index.css) — это частые случаи, но для каждого сайта индивидуально и этот способ может не подойди, остается через инспективание какого-либо элемента на сайте, чтобы определить основной файл css
Либо используйте загрузку файла с компьютера или вставкой кода в соответствующее окно.
Для блогов WordPress:
На эту часть ?ver=3.9.2 можете не обращать внимание
Для одностраничных сайтов:
Далее идем в Валидатор CSS и видим следующее окно, почти такое же как и выше, только здесь мы проверяем css файл. Объяснять что куда тыкать не вижу смысла, все на русском и все понятно. Помимо проверки с сервера, можете так же воспользоваться загрузкой файла с компьютера или вставить код
После проверки, видим какие ошибки присутствуют в файле css
В моем примере ошибки не встретились, а есть только предупреждения, вот так все это выглядит на деле
Вот так проверка валидности html и css работает, теперь вы знаете как убрать те или иные ошибки на своем сайте.
Возникнут вопросы, оставляйте комментарии или воспользуйтесь обратной связью рад буду помочь, удачи Вам.
Подведем некоторые итоги и выводы:
— После всех операций редактирования исходных файлов движка или отдельных страниц html, не ленитесь проверять валидатором код своего сайта.
— Проверка валидности html и css позволит убрать все критические ошибки на сайте, тем самым сэкономите время и нервы свои
С уважением, Александр Лукьянов
vpluce.ru
Итак, допустим, вы руководитель проектов, у вас есть команда (программист, верстальщик, дизайнер, кто то еще) и вы создаете сайты. Проблема в том, что руководителю проектов необходимо знать совершенно все аспекты создания сайта, начиная от дизайна, и кончая безопасностью, чаще всего – так не бывает. Если руководитель проектов бывший дизайнер, он справиться с такими аспектами как дизайн и юзабилити, но вот в техническом плане у него (у вас) будут проблемы. Бывает и так, что руководителем становиться менеджер, конечно, он великолепно управляет людьми, у него ярко выраженные лидерские способности… но в техническом аспекте ему приходиться полагаться на свою команду, это хорошо, если команда – настоящие профессионалы, а если нет, то спрос будет не с команды, а с ее руководителя. В этой статье, я постараюсь описать несколько моментов, которые помогут вам оценить качество создаваемых вами (вашей командой) сайтов.
Что мы будем тестить?
Тестить мы будем следующие моменты:
- Верстку
- Программировине
- Безопастность
Верстка
1. Верное отображение сайта в разных браузерах
Так уж получилось, что разные браузеры, отображают один и тот же html код, по-разному. Это печально, и это головная боль всех верстальщиков. Тем не менее, эта головная боль оплачивается, и оплачивается вами. Так что стоит проверить, как именно ваш сайт отображается в разных браузерах, причем проверить – это не значит открыть главную страничку сайта, лучше проверить все странички. Тут я бы выделил пять браузеров:
- Internet explorer 6 (где то на http://www.microsoft.com/)
- Internet explorer 7 (где то на http://www.microsoft.com/)
- Opera (http://ru.opera.com/)
- FireFox (http://www.mozilla-europe.org/ru/firefox/)
- Chrome (http://www.google.com/chrome/)
Ну и еще можно проверить в:
- Safari (http://www.apple.com/safari/download/)
Если лень грузить браузеры и тыкать по ссылкам, то можно сие действо и автоматизировать, для этого есть специальные сервисы:
- http://browsershots.org/ — бесплатный сервис, куча браузеров. Вводите адрес сайта, и его ставят в очередь на проверку, ваша очередь придет примерно через час, но проверяется только одна страницы, и одно разрешение экрана, так что если хотите проверить все страницы при разных разрешениях – запаситесь терпением… нечеловеческим терпением… После проверки получите ссылки на ваши скриншоты.
- http://ipinfo.info/netrenderer/ — Проверяются только разные версии Internet explorer’a. Никакого ожидания, скрин выдается сразу. Сервис бесплатный.
- http://www.browsercam.com/ — Сервис довольно крутой. Можно проверять сразу 10 url’ов, можно указать до какого уровня вложенности страниц проверять, а можно проверить сайт целиком. Можно даже переход на поддомены указать. В общем у этого сервиса есть все, наверное потому он и не бесплатный (около 100 баксов в месяц).
Вообще, таких сервисов в сети куча, стоит только спросить у гугла…
2. Валидность верстки.
Сейчас много говорят, о том, нужна ли валидность верстки. В основном приводят в пример google, типа «Если уж гугл свой сайт сверстали забив на валидность, то что нам простым смертным остается…». Если присмотреться к коду google.com, то… знаете, я бы такого верстальщика на работу не взял… оформление и разметка – вперемешку, тип документа неуказан, таблица стилей не вынесена в отдельный файл…. На FrontPage’е они верстают что ли… В общем, это все со знаком минус, а на минусы ровняться не стоит. Про важность валидации можно говорить много, и можно привести кучу доводов показывающих важность валидации, и все эти доводы можно оспорить, кроме одного:
Профессиональный верстальщик никогда не позволит себе не валидный код, а хорошая студия не возьмет верстальшика, верстающего «как попало».
Проверить валидность верстки сайта можно тут:
http://validator.w3.org/
Программирование
Оценить работу программиста, программистом не являясь, мягко говоря, сложно, и все же я дам несколько советов, что бы вы могли иметь некое представление об уровне программера, работающего с вашим проектом.
1. ЧПУ
Или Человеку Понятный УРЛ. Посмотрите внимательно в адресную строку браузера, там не должно быть никаких «?», «=», “&” и прочей фигни, только буквы! То есть, например если у вас на сайте есть новости, то адрес на страничке новости должен быть не таким
ваш_сайт.ru/news.php?cat=last&id=451,
а что то вроде:
ваш_сайт.ru/news/last/451
Согласитесь, второй вариант, как минимум, приятнее для глаз, и я думаю любой хороший программист, если ему будет не лень (а раз мы ему платим, значит лень ему быть не должно), может и должен реализовать в вашем проекте ЧПУ. Кроме того, что это все приятно для наших с вами глаз, это приятно и для глаз поисковиков.
2. AJAX
Аякс, это красиво, удобно, популярно и современно. Но помните, перебарщивать AJAX’ом нельзя, его нужно использовать только там, где он действительно полезен. Впрочем, где использовать AJAX, а где нет, к программированию не относиться, зато к программированию относиться сама реализация… Я, как программист, скажу, что самый большой наш порок – это лень вкупе с пренебрежением к пользователям. Если в вашем проекте используется AJAX, убедитесь что при динамической подгрузке данных, пользователь информируется о том, что на сайте что то происходит. Может быть у вас в офисе и стоит десятимегабитная выделенка, но у многих пользователей интернет горзадо медленней, и при щелчке на ссылку, пользователь может и не понять, что что-то грузиться, надо бы ему об этом рассказать.
3. CMS
Если на сайте используеться система управления контентом, а так чаще всего и бывает, и если эту систему писал ваш программист, убедитесь, что вы понимаете, как работает система, и при необходимости, сможете работать с ней сами. Видел я одну cms, где странички создавались путем вбивания нужных значений в таблицу mysql через phpmyadmin. Управление вашими сайтами, должно быть для вас совершенно понятным, ибо программисты приходят и уходят, а сайт остнется.
Безопасность
Говорят, что только самые лучшие программисты, могут стать хакерами (ну или как принято говорить «Консультантами по IT безопасности»), так что не рассчитывайте, что сможете сами проверить сайт на уязвимости, прочитав эту статью, однако пару рекомендаций я вам дам.
1. SQL уязвимости
Пожалуй, самая распространенная ошибка программистов. Вечно мы забываем проверить переменную, перед тем, как использовать ее в sql запросе. Суть уязвимости в том, что бы изменить передаваемую скрипту переменную так, что бы sql запрос выдал не то что должен, а то что нужно хакеру. Проверить переменную на на безопасность довольно просто, достаточно вставить в нее символ «’».Допустим у вас url
ваш_сайт.ru/news/last/451
Попробуйте изменить его на:
ваш_сайт.ru/news/last/4’51/
И если вылетит ошибка типа
Warning: Supplied argument is not a valid MySQL result resource…
Или что нить в этом роде – урежте зарплату программисту, если вместо новости с идентификатором 451 вылезет новость с идентификатором 4, тоже ничего хорошего. Апострофы стоит повставлять не только в url’ы но так же и во все input и textarea поля на сайте, короче говоря, везде, куда пользователю разрешено вводить текст.
2. Загрузка файлов
Если пользователь может загружать на сайт файлы (фотографии, документы), нужно проверить, какие именно файлы разрешены к загрузки, и если тип загружаемого файла не проверяется, считайте что ваш сайт взломан.
3. Остальные
Хотел сейчас написать про xss уязвимости, и понял, что не могу выразить свои мысли словами, доступными людям, не разбирающимся в IT безопасности. Поэтому все же посоветую использовать для проверки сайта на уязвимости специального человека, или специальный софт. Я бы посоветовал XSpider (http://www.ptsecurity.ru), правда это обойдется вам от 9000р в год. Есть и бесплатные утилиты, менее надежные, но все-таки бесплатные.
Еще
Ну и так в бонус, есть неплохой сервис
http://webo.in/
Который скажет вам насколько ваш сайт быстро грузиться, и что можно предпринять для ускорения его загрузки… это так, если захочется наказать программиста…
habr.com