Валидатор css html

Что такое валидация html и CSS сайта.

=== Скачать файл ===

Валидаторы HTML и CSS

Валидация CSS

Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. HTML-валидатор производит несколько проверок Вашего кода. Валидация синтаксиса — проверка на наличие синтаксических ошибок. Проверка вложенности тэгов — тэги должны быть закрыты в обратном порядке относительно их открытия. Валидация DTD — проверка соответствия Вашего кода указанному Document Type Definition. Например, пользовательские тэги и атрибуты. Имейте ввиду, что это логические проверки, и не важно как реализован валидатор. Если хотя бы одна из проверок не проходит успешно, то HTML считается невалидным. И в этом заключается проблема. Аргументы Основным аргументом за валидацию HTML является обеспечение кроссбраузерности. Поскольку каждый браузер имеет свой механизм коррекции ошибок HTML Вы не можете полагаться на невалидный код. Основным аргументом против валидации является то, что она слишком строгая и не соответствует тому, как на самом деле работают браузеры. Да, HTML может быть невалидным, но все браузеры могут обрабатывать некоторый невалидный код одинаково. Если я готов взять на себя ответственность за неправильный код, который я пишу, то я не должен беспокоиться о проверке. Единственное, о чем я должен заботиться — это чтобы оно работало. Моя позиция Это один из немногих случаев, когда я публично говорю о своей позиции по отношению к чему-нибудь. Я всегда был среди противников валидации, основываясь на том, что валидатор слишком строг, чтобы быть практичным в реальных приложениях. Вообще, моей наибольшей проблемой валидации является проверка 4 на посторонние элементы. Я сторонник использования пользовательских атрибутов в HTML тэгах для хранения дополнительных мета-данных, относящихся к определенному элементу. В моем понимании, это, например, добавить атрибут foo, когда у меня есть данные bar , которые мне надо ассоциировать с определенным элементом. Иногда люди перегружают существующие атрибуты для этих целей только для того, чтобы пройти валидацию, несмотря на то, что атрибут будет использовать не по назначению. Для меня это бессмысленно. Секрет браузеров заключается в том, что они никогда не проверяют соответствие HTML-кода указанному DTD. Doctype, который Вы указали в документе, переключает парсер браузера в определенный режим, но это не приводит к загрузке doctype и проверке кода на соответствие ему. То есть, парсер браузеров обрабатывает HTML с некоторыми допущениями невалидности, вроде самозакрывающихся тэгов и блочных элементов внутри строковых я уверен, что есть и другие. В случае пользовательских атрибутов, все браузеры парсят и распознают синтаксически корректные атрибуты как допустимые. Это делает возможным получить доступ к таким атрибутам через DOM с помощью Javascript. Так почему я должен беспокоиться о валидности? Я буду продолжать использовать свои атрибуты и я очень рад, что HTML5 формализует их. Лучший пример технологии, которая приводит к невалидному HTML, но имеет огромное значение, — это ARIA. ARIA работает с помощью добавления новых атрибутов в HTML 4. Эти атрибуты предоставляют дополнительное семантическое значение HTML-элементам и браузер способен передать эту семантику вспомогательным устройствам для помощи людям с ограниченными физическими возможностями. Все основные браузеры сейчас поддерживают разметку ARIA. Однако, если Вы будете использовать эти атрибуты, у Вас будет невалидный HTML. Насчет пользовательских тэгов — я думаю, что в добавлении на страницу синтаксически корректных новых тэгов нет ничего плохого, но я не вижу особого практического смысла в этом. Чтобы прояснить мою позицию: Проверку 3 я тоже считаю важной, но не столь, как первые две. Проверка 4 очень сомнительна для меня, так как она задевает пользовательские атрибуты. Я считаю, что, как максимум, пользовательские атрибуты должны быть помечены как предупреждения а не ошибки в результатах проверки, чтобы была возможность проверить, не ошибся ли я при вводе названия атрибута. Отметка пользовательских тэгов как ошибок, возможно, хорошая идея, но тоже имеет некоторые проблемы, например, при встраивании содержимого в другой разметке — SVG или MathML. Я считаю, что валидация ради валидации — это крайне глупо. Валидный HTML означает только лишь то, что все 4 проверки прошли без ошибок. Есть несколько важных вещей, которых не гарантирует валидный HTML: Валидный HTML может служить поводом гордиться самим собой, но само по себе это не является показателем мастерства. Ваш валидный код не всегда лучше выполняет свои функции чем мой невалидный. Валидация HTML5 Валидация HTML5 исправит некоторые проблемы, которые были с валидацией HTML 4. Она явно позволяет употребление пользовательских атрибутов они должны начинаться с data-. Это позволит моему коду пройти проверку на валидность для HTML5. Конечно, есть некоторые моменты в валидаторе HTML5, с которыми я не согласен, но я считаю, что он намного больше соответствует практическим потребностям чем валидатор HTML 4. Заключение Я считаю, что некоторые составляющие HTML-валидации крайне важны и полезны, но я не хочу быть ее заложником, потому что я использую свои атрибуты. Я горжусь тем, что я использую ARIA в моей работе и мне безразлично то, что это считается невалидным кодом. Опять же, из четырех проверок валидатора у меня есть проблемы только с одной. И HTML5 валидатор избавит меня от большинства этих проблем. Я знаю, что для многих это спорная тема, поэтому, пожалуйста, воздержитесь от чисто эмоциональных высказываний в комментариях. Об авторе — Nicholas C. Zakas, сотрудник Yahoo, специалист в области UI и JS, автор книг Professional JavaScript for Web Developers и High Performance JavaScript. Программирование 3k авторов , 6,6k публикаций. Информационная безопасность 2,4k авторов , 6,5k публикаций. Python автора , 1,8k публикаций. Машинное обучение авторов , публикаций. Разработка мобильных приложений 1k авторов , 2,8k публикаций. Разработка веб-сайтов 4,1k авторов , 9,7k публикаций. Математика авторов , 1,2k публикаций. Алгоритмы 1,3k авторов , 2,4k публикаций. Data Mining авторов , публикации. JavaScript 1,9k авторов , 4,1k публикаций. Узники системы 6,1k Добавить в закладки Сутки Неделя Месяц Почему я до сих пор использую Vim? Я уже высказывал своё скромное мнение однажды. С тех пор прошло несколько лет и ничего не поменялось, от безвалидности никто не умер и никто не разорился. Вы бы знали сколько мобильных сайтов страдали из-за невалидной разметки и недоступности для пользователей. Но сейчас дела там схожи с веб. Мобильный веб это отдельная история — там в основном пока и не нужны кастомные атрибуты и иже с ними. Понятно, что создание кода по стандартам уменьшает вероятность некорректного отображения в различных браузерах, и создавая валидный код будет меньше проблем с кроссбраузерностью. Но если везде выглядит одинаково но не валидно, то к чёрту валидность — это хороший код. А если полностью валидный код выглядит в каждом браузере немного по разному, то это не браузеры плохие, а код ужасен. На валидной верстку, проще обнаруживаются ошибки, появляющиеся при всяких доработках, переверстках и прочем. На мелких сайтах-визитках не так заметно, но на больших и долгоживущих проектах, над которыми работает много программистов, верстальщиков, контент-менеджеров это критично. Это упрощает жизнь создателям различных грабберов:. В вашем примере достаточно только well-formed 1 и 2 из статьи. Автор утверждает что сомнительна польза от валидности. Я валидный XHTML имел ввиду, опять же извиняюсь за неточность. Я за стандартизацию, потому что 1. Если где-то мне показывает валидатор, что сделано не по стандарту, я должен четко знать почему именно я сделал не по стандарту. В других случаях пусть будет по стандарту. Если все по стандарту, это один из способов увеличить шансы что в следующих версиях браузеров сайт не сломается. Об этом и пишет автор, но только кастомные атрибуты должны быть не ошибками валидатора, а предупреждениями. Валидность кода — это способ проверять его качество в два клика. Ок, ничего не поломалось. А если у вас куча мусора и стомильёнов кастомных атрибутов, то и не будет зелёненького, а значит в коде могут быть и другие ошибки. В общем, валидность — это инструмент, а не самоцель. Иногда замыленным взглядом не заметишь ошибки в коде, а валидатор сразу же на нее укажет. Ну одно дело — это когда что-то действительно серьезное отмечается как ошибка в результатах валидации. И чтобы получить passed от валидатора приходится навешивать это через js, но, фактически, это же хак, потому как валидатор не понимает JS и не может парсить динамический контент. Тем не менее, я могу увидеть в валидаторе, что единственное что изменилось — это автокомплит. А если я с самого начала не заморачивался валидацией, то этот инструмент мне и не поможет: Так что изначально всё-таки нужно страницу довести до ума. А есть возможность валидировать только синтаксис и вложенность тегов без DTD. На мой взгляд этого было бы достаточно для большинства случаев и не выдавало ошибки там, где их нет. НЛО прилетело и опубликовало эту надпись здесь. Под синтаксисом я понимаю набор правил, которые позволяют сказать, что данный набор байтов — html код. Теги, экранирование спецсимволов, атрибуты тегов. Следует четко понимать, что эта статья не призывает наплевать на спецификации и валидацию, а всего лишь призывает использовать необходимые вам техники, которые сделают работу легче или результат — лучше, даже при том, что они не пройдут валидацию. Просто мои комментарии, выражающие подобное отношение к валидации, в некоторых случаях вызывали возмущение, как будто я призываю писать код как попало. И с первого взгляда не понятно где это произошло. С помощью валидатора это место быстро находится. Это в случае валидного документа. В случае невалидного придется сначала промотать предыдущие ошибки. Это как раз к проверкам 1 и 2. Спорная 4 делает другое. Да Валидация HTML5 исправит некоторые проблемы, которые были с валидацией HTML 4. Я тоже использую вспомогательные атрибуты. На самом деле автор и я тоже призывает не к эмоциональному холивару, а к взвешенному обсуждению: Виталий Харисов ответил когда-то на вопрос, для чего в Яндексе валидность примерно так: Ну в Яндексе по-моему с валидностью не очень. У заглавной страницы так точно: Забили на валидность главной, слишком сложно и незачем поддерживать. Ещё не все основные производители браузеров зарелизили поддержку HTML5, потому в живых проектах думаю это преждевременно. Я всегда стараюсь верстать валидные страницы, в то же время понимая что некоторые корректные элементы не пройдут валидацию… по возможности пробую обойтись без них. Полная чушь от начала и до конца: Валидатор проверяет соответствие спецификации и только. Не хотите соответствовать — не соответствуйте. Как вообще валидность или не валидность кода связана с вебразработкой? Я считаю, что валидатор быть обязан и обязан быть максимально жёстким, а дальше уже личное дело каждого- будет он гоняться за валидностью и соответствию стандартам или нет. Личная позиция по поводу требований валидности для кода: То есть писать невалидный код можно и иногда нужно! И без валидаторов будет бардак. Да, и не используйте strict DTD и вообще DTD если не хотите соответствовать стандартам, всё очень просто. Браузеры вас прекрасно поймут и без доктайпа. Поймут но не все. Самым безопасным считаю использование переходного док тайпа, а не стрикта. Так по-моему лучше всего получается. Я просто к тому, что глупо писать strict и использовать, например, фреймы или всякие устаревшие атрибуты у тегов вроде color. Вы если заявляете strict — то и пишите strict код. Вы про существование Quirks mode вообще в курсе? Причём здесь Quirk mode? Не описан доктайп — врубается Quirk. Разные CSS для разных старых браузеров ещё никто не отменял. К тому же, я не против доктайпа как такового. Quirk нуден если доктайп не описан вообще. Только зачем этот анархонизм, который остался со времен IE5? Да проблема в том, что допустим я совершил синтаксическую ошибку в коде — это плохо, но браузер это съест, но валидатор покажет ошибку и я ее исправлю. Ну и в чём проблема? Прогоните через валидатор и увидите свою ошибку. Валидатор-то есть, слава Богу, так что пользуйтесь. Оба случая в валидаторе будут помечены равнозначно — как ошибка, хотя на самом деле ошибка одна. На самом деле ошибки две. Стандарты пишут не просто так, не будет стандартов — будет анархия. Итак, мы пришли к выводу, что Google Suggest и аналоги — это анархия: А при чём тут гугл саггест? Я вам не предлагаю соответствовать устаревшим стандартам, я говорю лишь, что валидатор обязан проверять код на валидность исходя из принятых стандартов и не давать поблажек. Проблема в том, что валидатор и стандарты w3c неразрывно связаны. И если стандарты отстают от практических потребностей, то это проблема и стандартов и валидатора, который используют конечные разработчики для проверки своего кода. Да здравствует великий tag soup! Где-то читала ссылки нету , что злоумышленник может сломать всю страницу при определённых обстоятельствах, так как определённые символы специфического шрифта в title до указания кодировки неправильно распознаются. Ну и браузер должен знать в какой кодировке показывать title страницы. Ой, что это я такой устаревший топик нашла? Даже и не обратила внимание на даты, простите. Я лично за логичность и чистоту кода и это не мешает мне пренебрегать валидацией. Почему никто до сих пор не вспомнил про хаки для ИЕ6? Ни один хак никогда скорее всего не пройдёт валидацию так как хаков нет и не может быть в спецификации. Это уже скорее ухищрение для обхода багов 6-го осла, например. Любой стандарт потому и стандарт, что изначально предполагает максимально идеальный вариант хода событий. Короче валидатор наивно полагает, что абсолютно все браузеры одинаково хороши и требует стандартизированного к ним отношения. Но мы-то с вами знаем…. Валидатор про браузеры ничего не предполагает, он лишь фиксирует факт следовал ли разработчик рекомендациям стандарта или нет. Точно такой-же пост можно было написать и про русский язык. Либо вы упорно говорите и пишете по русски правильно, надеясь что рано или поздно все будут делать также, либо вы говорите и пишите как вам удобно, соблюдая элементарные правила. А валидатор — это такой grammar nazi. IMHO — html пишется для роботов и он должен быть валидным. В этом случае если робот неправильно обрабатывает валидный код, то это баг робота. А всех роботов рано или поздно починят, если не люди то другие роботы. Я идеалист, простите меня. Технически код можно делать невалидным. Идеологически можно поспорить, но железных аргументов не найдется ни у одной из сторон. А мне просто нравится, когда код чистый и валидный. Я рассматриваю этот вопрос в эстетическом плане. Дополнительных трудозатрат у меня на это не возникает, так почему бы не сделать себе приятно? Ну Вы понимаете, что в реальности навешивание autocomplete через JS — это хак валидатора. Если бы валидатор генерировал страницу как браузер и потом проверял валидность, такой вариант не прошел бы. Так что на самом деле код не валидный, мы лишь просто обманули валидатор таким образом. Я делаю это для собственного удовольствия. Просто в конечном итоге погоня за значком валидности может обернуться не одним десятком килобайтов JS. Ни разу не сталкивался с таким. Возможно, это зависит от привычного стиля, способа верстки. Если Вы исключительно верстальщик, то да. Если же у Вы разрабатываете полноценное RIA со всеми вытекающими, то тут столкнетесь наверняка. Нет, я не верстальщик. И как-раз верстальщику сложнее, он не сможет изменить логику приложения, в случае чего. Сразу оговорюсь, что логику менять не приходится. Ни разу не сталкивался с ситуацией где требуется атрибут autocomplete только для того чтобы отключить autocomplete. Как правило его выключают по причине того, что он мешает какому-либо js обработчику поля. Посему и сменить этот параметр можно и нужно исключительно при навешивании этого самого обработчика. Поле ввода для номера кредитной карты, CVV и срока действия — самый простой и яркий пример. Вероятно, не довелось мне сталкиваться с такими полями. Если такое добавлять для каждого кастомного атрибута, то размер страницы разрастется до неприличных размеров. До каких таких размеров? До размеров noindex и autocomplete? Лишние байт не играют большой роли в современных html-страницах на и более килобайт. Не только в IE, но и в FF. К счастью те времена прошли. Пока коментов мало, схожу за попкорном. Валидность не цель, а инструмент для быстрого вычисления ошибки в коде. Затем, что стандарты, а вместе с ними и валидатор, устарели и не соответствуют реальным потребностям. Если вы делаете валидный код и вставляете туда невалидных тэгов, то вы точно также сможете пользоваться этим инструментом. Если у вас вся страница состоит из говнокода, то пользоваться этим инструметом вы уже не сможете. Посмотрите на проект ARIA. Там кастомные атрибуты повсюду. И ошибок валидатора будет куча. Но это вовсе не говнокод. Про какой поект идёт речь? Может быть вы знаете для этого другие, более удобные инструменты? Заказчикам абсолютно без разницы валиден код или нет — это факт. Сейчас делаем сайт по производству фурнитуры для мебели. Офис заказчика находится прямо в цехе. Как вы думаете если попытаться доказать своё преимущество перед др. Тут нужен только прагматичный подход. Не робит — не круто. Если заказщику нужен сайт, то ему без разницы, если заказщику нужен код, который придётся поддерживать, то выберут того, кто верстает валидно. Это типичное заблуждение, что валидный код проще поддерживать. В погоне за валидностью вот некоторые установку атрибутов в JS выносят, поди найди потом, откуда он берется. Попытки обмануть валидатор, чтобы он не заметил невалидный код также мешают человеку впоследствие поддерживать его. Идиотов конечно везде хватает, но я не про клинические случаи сейчас, а про тенденцию. В крайних случаях, если нужно — можно добавить невалидные атрибуты и пару невалидных тэгов. Но всё остальное должно быть DTD XHTML 1. Но за такое хочется руки оторвать. Заказчику, если мы говорим о сайтах, нужен конечный ПРОДУКТ, который он будет поддерживать через админку или ещё как-то. Сам код ему нахер не нужен. Те же Лебедевцы, например, да и не только они, на сколько знаю, перешли на доплату если надо сверстать кроссбраузерно с ИЕ6. Тоже самое можно сделать и с валидностью. Если заказчику уж прям сильно надо кнопку, то без проблем. Если сайт разрабатывается с нуля, то валидность обеспечить гораздо легче, чем поддержку IE6. Просто если написать например — это уже не валидно, а если — валидно. Разница в пробеле перед закрывающим слэшем. Мне пофигу на этот пробел так как всё работает, а валидатору нет. ВордПресс, например, автоматом этот пробел добавляет в каждый закрывающийся тег. Выходит ВП вообще надо выкинуть на помойку и всех блоггеров пересадить на Друпал или Битрикс. Тогда передам на пальцах: Если слэш стоит сразу после '', то валидно. Если мы о XHTML, то с пробелом перед слешем или без — пофиг, оба варианты валидны. Сдаётся мне, вам вот этим навеяло. Полностью согласен, самое плохое, что этот миф вырос на столько, что валидность стали требовать заказчики, обычные менеджеры, которым очень трудно объяснить технические нюансы. Кстати, можно написать свой валидатор, без блэкджека и шлюх, а просто для того, чтоб им пользоваться удобней было. Думаю, валидность написанного кода следует сравнивать с грамотностью при письме, а валидатор с проверкой правописания, скажем в Ворде или в браузере. В нашей речи и в синтаксисе языка разметки есть определенные правила. Ну и понятно, что для проверки уровня своей грамотности мы можем использовать удобные инструменты в программах, которыми пользуемся. Валидатор, для языка разметки, и есть таким инструментом. Тут должна быть другая аналогия: Обратное, кстати, тоже верно. Слегка перефразируя цитату из корневого поста: Готов послушать Ваш вариант про валидный autocomplete: Код валидным быть не должен, что тут обсуждать. Код должен быть рабочим и легко поддерживаемым, а это отнюдь не одно и то же. Если верстальщик считает валидатор, а не качественно решенную задачу, мерилом своего профессионализма и крутости, то он говнокодер, да. Например, что блочный элемент не вложен в строковый. Я с помощью валидатора выявляю незакрытые тэги. Лучший валидатор — это браузер: Я вообще не понимаю, о какой валидации в реальной жизни может идти речь. То есть, если у вас на сайте стоит реклама от Яндекса — то ваш сайт автоматически не валиден. Будет ругаться, так как валидатор заточен только под HTML, но не под XML или SGML. Вот такой вариант будет валидным всегда! Изобрел этот метод когда реально невозможно было сделать валидную верстку, а заказчика ну никак не переубедишь, давай валидную верстку. Что вы будете делать? Переверстывать весь макет, и просрочите все сроки или вставите одну строчку? Поскольку сайты тестируются браузерами, то единственным валидатором может быть только браузер. Все остальные инструменты для тестирования идут в дополнение с самой разной степенью значимости. Валидация и браузер — разные понятия. Но, похоже, что дело Самизнаетекого живет и процветает. В мире, кроме браузеров, существуют еще программы, которые умеют работать с HTML, CSS, XML и так далее. Подумайте над этим на досуге. А никто не говорит, что это одно и то же. Польза, которую она приносит слишком мала, чтобы об этом задумываться. Я грабберы писал, т. Огромное кол-во существующего невалидного HTML не позволит браузерам его не обрабатывать, а свобода, которую дают браузеры, всегда будет порождать еще больше невалидного HTML-a. С XML разговор другой. И, кстати, ни один браузер невалидный XML не отобразит. Поэтому я на него даже и не смотрю. Но это вопрос не технологий, а отношения к работе. Мне кажется, если ИЕ6 уйдет из бытия, то все ходивары про валидацию сойдут на нет. IE6 — зло всех времен и народов. Валидация, по сути, показывает, насколько ИЕ шаловлив. Вам стоит разобраться в терминах перед тем, как писать подобное. Нас поймут, если мы будем писать неграмотно. Но мы стараемся следовать правилам русского языка. Ну в английский или американский? Валидатор нужен тому, кто учит технологию. Кто выучил ее, тому он не нужен. Гораздо более важно, чтобы сайт отображался одинаково в разных браузерах. Да и бывает приходится чем-то жертвовать ради валидации… microsoft. Это статья уже морально стара, об этом можно было говорить еще несколько лет назад. Сейчас наступает эпоха HTML5 и даже MS стал прикладывать усилия по подавлению младших версий IE, и активно пиарить IE9. В настоящее время не профессионально говорить об этом. А все приведенные доводы автора это лишь отмазка технически слаборазвитого разработчика, которому лень доводить код до идеального состояния, а также которому лень искать новые решения кроме как добавить не валидный аттрибут. На счет автора… странно, что JS-developer из Yahoo может говорить такие вещи. Эпоха HTML5 еще не наступила и посмотрим насколько затянется ее наступление. Это не отмазки, это реальные проблемы, выше уже обсуждали конкртеные примеры. Уж поверьте, ему то не лень искать технические решения. Советую ознакомиться с его книгой High Performance Javascript: Валидация всего лишь приучает разработчиков писать код правильно, в том формате который спокойно поймут другие разработчики и смогут поддерживать если что. Со временем надобность валидации отпадает, но привычка писать хороший код остается. Согласитесь, есть разница между: Сейчас да, но в те времена когда я начинал писать html такой код был нормой. Потом появилась мода на валидацию и многие научились писать правильный, читабельный код. Сейчас большинство пишет нормальный код и надобности в валидации больше нет. У меня есть интернет-магазин. Хтмл-код, который отдается посетителю супермегаНЕвалидный, например: Так что все эти валидации на мой взгляд — удел параноиков. Главное, чтобы сайт выполнял свою основную задачу, в моем случае — продавал. Вот на тебя и плюют, когда с мобилок нормально зайти не могут, когда в отдельных браузерах вёрстка едет к чертям. Мне не повезло, я в вёрстке немного разбирась, поэтому, на таком сайте никогда ничего не куплю. Сразу пахнет шарашкиной конторой. Недавно покупал молоко в коровьем хлеву. Молоко просто супер, сливок пол-банки. Но вот обстановочка… Мощный аромат навоза, под ногами навоз, в сторону посмотришь — из коровы навоз валится. Мне в моих лакоботах сложно было пробраться до холодильника. Ты продаёшь в таком же хлеву. Кругом говно, в конце пути товар. Такой путь пройдёт не каждый. Одно дело супермегаНЕвалидый, другое дело если код — полное говно. Вот будет смеху когда вы захотите расширять функционал и столкнетесь с плевками разработчиков, завышенными бюджетами и раздутыми из-за этого сроками. Мне кажется, нет никаких причин гнаться за идеальной валидностью ценой потери удобных инструментов noindex, autocomplete и т. Однако, несоблюдение основных важных правил неправильные вложения тегов, отсутствие закрывающих слешей, объявление стилей в теге и т. Автор не осилил DTD и XML Schema и ругает валидацию. Неужели так сложно при использовании каких-то доп атрибутов, тегов и т. Однако сам стандарт является не жестким кодексом правил, а просто сводом рекомендаций. Кроме того плевать как код проходит валидацию, работать с этим кодом будет браузер, а не валидатор. Многие работодатели очень любят оценивать верстку именно по валидности, часто берут на работу именно тех кто пишет по стандартам, но никогда на собеседовании не замечал, чтобы страницу проверяли на скорость загрузки и ее Вес, действительно зачем?! Метки лучше разделять запятой. Сейчас Вчера Неделя Объединяем акторов и SEDA-подход: Где лучше всего жить и работать разработчику 22,3k JavaScript как мыслевирус 29,7k Интересные публикации Хабрахабр Geektimes. Автономный способ обхода DPI и эффективный способ обхода блокировок сайтов по IP-адресу. Как настроить командную работу и сохранять спокойствие в чатах Телеграма, если всё горит, и все в аду. Учим робота готовить пиццу. Биохакеры закодировали зловред в ДНК, чтобы атаковать софт для секвенирования генома GT. Рассказывать ли сотрудникам о социальной инженерии? Не Роскомнадзором единым GT. Умный замок, взгляд параноика GT. Прокуратура вынесла предупреждение фермерскому кооперативу LavkaLavka из-за приема биткоинов GT. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.

Данте цитаты о любви

Как определить гайморит у взрослого

Карта памяти panasonic sd

Мирамистин инструкцияпо применению ингаляции детям

Тц атриум схема магазинов

Форд транзит заводится и глохнет причины

Узи признаки дгпж предстательной железы

Принцип разделения гос власти

Срочный кредит с плохой историей

Хорошо добраться до дома картинки

Отчет аспиранта образец

1 понятие власти