HTML+CSS+JavaScript

Валидатор дает множество сообщений типа:

"Вы не указали цвет фона background-color (или background-color установлен прозрачным), но задали цвет color. Убедитесь, что последовательность цветов сохраняет текст читаемым."

Суть их ясна - валидатор не может знать, будет ли текст читаемым, и обращает на это внимание верстальщика.

Предупреждение - не ошибка, и вполне можно её игнорировать. Но, по идее, правильным было бы для всех элементов, у которых задается color, определять и фон background-color ?


(С переопределением вопрос отпал.)

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

В том плане, что соответствие, так называемым, "стандартам", вроде как, и правильно, и хорошо, но есть некоторые но.

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

Самый валидаторный валидатор - это браузер, вот если ваш сайт кроссбраузерно свёрстан и пользователю доступен этот результат без "кривизны" (кстати, валидность ещё не гарантирует кроссбраузерность, что тоже нужно понимать), тогда тест на валидность пройден.

Почему это так? Вы откройте эту страницу через валидатор, но от увиденного результата вы ведь не захотите покинуть этот сайт, и точно не назовёте его организаторов непрофессионалами, и точно сайт кроссбраузерный :)

Самый валидаторный валидатор - это браузер

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


Я могу сказать только то, что вы уже немного перегибаете :)

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

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

Интересно на сколько? Гугил обещался учитывать скорости загрузки сайта, что более важно, чем ругань валидатора или её отсутствие. И может и учитывает, но чтобы это дало глобальный сдвиг...



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

Например?

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

может и учитывает, но чтобы это дало глобальный сдвиг...

Нет, глобального сдвига ожидать не приходится.

Так, по мелочи.

что-то мне подсказывает, что с валидностью та же история :)

Да, та же история.

>он исправляет много весьма грубых ошибок
Более того, он позволяет ссылаться на несуществующие страницы. Из-за этого и Интернет существует - все остальные попытки провалились. Более того, так называемые "грубые ошибки" остаются таковыми, пока они допускаются случайно, а когда эти особенности браузеров используют крупные компании, чтобы сделать размер страницы меньше и сэкономить трафик ошибки превращаются в профессиональную работу. Более того, в рамках XHTML - это могут быть грубые ошибки, а в рамках HTML - следование стандарту. XHTML так и не смог стать стандартом де факто в Интернет (хотя усилия были приложены неимоверные), таковым стандартом по-прежнему остается HTML, более того, после почти 10 лет ухода от него идет новая версия HTML5, в которой "весьма грубые" ошибки еще более огрублены.

я правильный понимаю, что на ругань валидатора, условно говоря, забили?

Нет, просто валидатор постепенно входит в роль, которую он должен занимать изначально: инструмент разработчика, интересный только разработчику и никому больше. Т.е. если заказчик требует, чтобы код тщательно прокомментирован на русском языке и предоставляет два листа требований к оформлению кода, вы понимаете перед вами разработчики (с ними можно говорить на одном языке). Пока же с валидаторами такая ситуация, что не знаешь кто перед тобой, потому что профессионал знает что может дать валидация, он даже может её жестко потребовать, объяснив зачем она ему - ему плевать на валидатор, ему главное, чтобы этот кирпич многоходовки не подвел, так как потом, например, по коду будет ползать робот. Работа будет организована соответствующим образом - робот будет доволен. Непрофессионал не может объяснить зачем ему валидация - он начинает требовать, контролируя по валидатору. Т.е. фактически путаясь под ногами. Это каприз, любой каприз возможен, но за них взымается дополнительная плата. Вот пока, если разговор сразу начинается с валидации, нужно прощупывать, кто перед тобой (понятно, что я привел лишь два крайних типа, их гораздо больше)...

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

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

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

Хочу сделать небольшой сайт на 7 страниц (собственно, уже сделал) с моим пониманием качества сайта в целом, и отдать яндексоидам на аттестацию. На конкретнве огрехи они не укажут, но вцелом оценку дадут.

Предыдущая попытка дала такие результаты:
- оптимизация 72 %;
- устойчивость 8%.

Оба параметра неплохие, однако есть поле для деятельности.

Предыдущая попытка дала такие результаты:
- оптимизация 72 %;
- устойчивость 8%.

Где об этом можно почитать? Я, например, не совсем понимаю, что собой означает "устойчивость" :)

Устойчивость - это вероятность избежать фильтра за низкое качество сайта.

А как оценивается "качество сайта", какие критерии?

У качества страницы примерно 400 критериев, у сайта как такового еще около пятидесяти.

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

>А как оценивается "качество сайта", какие критерии?
Это попытка факторизовать то, что считается хорошим. Например, все знают, что стили нужно хранить отдельно от HTML кода, как JavaScript-код, что много переадресаций - это плохо и т.п. Я уверен, что вы все эти 400 факторов в той или иной форме знаете, ну пусть не все, но большинство. Просто согласитесь не каждый сайт и страница сверхидеальны... а у Яндекса нет возможности бесконечно наращивать сервера (тем более он сейчас работает не по Рунету, а по миру), поэтому он старается выбрать тех, кто идеальнее :)))

Забавно :)

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

В общем суть ясна, и, если в двух словах, можно процитировать абзац с сайта студии Лебедева:
"Во всей работе мы руководствуемся одним-единственным правилом из двух слов: «без хуйни». " :)

>Я вот считаю, что хорошее, это когда оптимизировано на скорость загрузки и работы (и с моей
>точки зрения это достаточно обосновано, так как мне доводилось заниматься этим вопросом
>вплотную), и часть этого - это цсс и скрипты в теле документа.
Я не думаю, что они тупо считают: есть или нет. Но вообще да, дорожка опасная... большой базис параметров - это не всегда хорошо. С другой стороны они этим много лет занимаются, вероятно понимают, что делают. Да и цель у них прозрачная - деньги (у Google, кстати тоже, он только по-русски хорошо индексирует, а напишите что-нибудь по-английски, да еще приносящее деньги - начинает артачиться).

Да и цель у них прозрачная - деньги

Я вот тоже на тему оптимизации начинаю задумываться не к сеошникам обращаться, а гугил адвордс, или яндикс директ :)

> Я вот считаю, что хорошее, это когда оптимизировано на скорость загрузки и работы (и с моей
> точки зрения это достаточно обосновано, так как мне доводилось заниматься этим вопросом
> вплотную), и часть этого - это цсс и скрипты в теле документа.
Не всегда так. Например не может быть ничего быстрее, чем отдача кода 304 на запрос if-modified-since. И яндекс этого очень хочет и ждет и приветствует. А встроив CSS в тело документа вы этого никак не сделаете. Таких примеров много.

встроив CSS в тело документа вы этого никак не сделаете.

Так у пользователя уменьшится количество запросов к серверу при загрузке страницы и за счет этого загрузка в браузер произойдёт быстрее. Актуально для ресурсов, где основная масса посетителей, так сказать разовые, тут надо исходить из задачи, а не из скорости работы запросов и пр. :)

Кэшированный CSS и JS вообще не будет загружаться (вернее загрузится один раз в начале работы с сайтом)... это тем более актуально, когда размер JS-библиотек во многих проектах достиг буквально мегабайтных значений.

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

Согласен.

у Яндекса нет возможности бесконечно наращивать сервера

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

Когда сайт выйдет на такой уровень посещаемости, что экономия на валидности станет оправданной, к нему будут применены другие критерии.

Как известно, что господам можно, за то холопов бьют.

Ну да, только весь Интернет, тем более моментально не станет валидным, более того, он не станет валидным даже за 10 лет (пробовали, не получается). Кроме того, как только он станет валидным - империи Google и Yandex пошатнутся, потому что нагрузка упадет более чем в 4 раза, если ориентироваться только на валидный код и вообще не работать с невалидным. Поэтому для новых сайтов код да, должен быть вылизанным, а вот со старыми - большая проблема, на них и информация есть, они и посещаемы, и переделывать их зачастую дорого и времязатратно.

Я полагаю, что так оно и есть. Поэтому к сайтам до 2009 года и подход другой, оттого и цены на старые домены возросли.

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

Хвать - а его уже зарегистрировали и выставили на продажу! Причем с оговоркой: "Мы не вступаем в переговоры относительно цен ниже 1000 евро, но это не значит, что данный домен мы продадим за 1000 евро. Пишите".

Написал ради интереса - узнать, сколько запросят.

>"к сайтам до 2009 года и подход другой, оттого и цены на старые домены возросли"

Это никак не из-за требований к "валидности".
Просто у Гугля увеличился срок "отсидки" новых сайтов в "песочнице".
А все прочие поисковики ориентируются на Гугль.