SelenIT

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

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

А мне последнее время вот этот генератор градиентов чаще "под горячую руку попадался".

А в диве с id="main" нужный див какой по счету (в каком по счете)? Это предсказуемо или нет? Вообще, какова конечная задача? Может, проще будет плясать от самой картинки, а не ее контейнера?

Что-то я "не нахоливорился" вчера в этой теме, хочется опять "пониспровергать основы" и подвести итог для себя (вдруг я действительно заблуждаюсь?) и для сообщества. Вот всех верстальщиков "сызмальства" учат, что незакрытые теги - бяка, ламерство, "какашкокод" и т.д., что "незакрытый тег обязательно где-нибудь аукнется", выйдет боком и т.п. Однако спецификация HTML прямо и явно разрешает опускать закрывающие теги для 18 элементов (а для 5 из них - и открывающие), а для 16 элементов закрывающий тег прямо запрещен. Отсутствие закрывающего тега не является исключительной ситуацией, поведение парсера в этом случае четко регламентировано и предсказуемо, различия в итоговой DOM сводятся к текстовым нодам на месте межтеговых пробелов и, как правило, не влияют на отображение CSS и работу скриптов. Так чем же всё-таки опциональные теги плохи на деле? Какие реальные проблемы из-за них встречались вам на практике? Имею в виду типовые рутинные задачи, не эксперименты с новшествами (как когда-то с новыми тегами в FF3.6 у Светланы) и не валидацию под XHTML-доктайп (с ним всё понятно, целесообразности самого этого доктайпа предлагаю не касаться). Речь о штатной ситуации с обычной разметкой с HTML-доктайпом (или вообще без), с обычным потоком давно поддерживаемых элементов, для которых закрывающий тег не обязателен. Например, <p>-шек или <li>-шек. Бывало ли у вас на практике хоть раз, чтобы от пропущенного </p> или </li> верстка "ехала" (а с его добавлением - вставала на место)? Прошу приводить именно реальные (в крайнем случае "лабораторные") примеры, а не абстрактные предположения в стиле "а вдруг там это...". Самому мне такие сходу что-то не придумываются (кроме совсем уж извратных и нежизненных, типа скрипта, тупо пересчитывающего соседние childNodes)...

Что значит "не подходит"? Элемент с id="main"-то, я надеюсь, на странице уникален? Или это не весь код, и у него внутри еще дивы есть? Тогда, если нужен первый, можно брать его по :first-child, а последующие - по цепочке соседей (#main > div > :first-child + div + ...) либо через :nth-child (если для новых браузеров). Но вообще, если этот див важен для оформления - лучше не поскупиться на класс для него, легче будет и верстальщику, и браузеру

Имхо, довольно удобно для веб-приложений, когда нужно добавить пару-тройку типовых действий по-быстрому. Не надо убивать штатное меню (которое не везде и убьешь, кстати) и рисовать свою выпадачку, мучаясь с координатами, а можно получить нужное поведение парой строк в коде. Жалко, что пока "не жизненно"... А insertAdjacentHTML - что-то наподобие innerHTML, только позволяет вставлять произвольный код не внутрь элемента, а рядом с ним (перед или после). Работает с незапамятных времен в IE (в 5-м точно была), а вот теперь вошла в HTML5

Судя по оф. докам, главная фича "восьмерки" - впервые реализовано контекстное меню из HTML5 (можно добавлять свои опции в контекстное меню браузера прямо из разметки, для любого эл-та). В CSS расширена эксперим. поддержка автопереносов "как в ворде" (добавлена куча поддерживаемых языков, включая русский), допилены background-size (честно говоря, не знаю, что с ним было не так раньше) и масштабирование SVG-фонов (а я проспал, когда вообще они в FF появились. В JS/DOM добавили insertAdjacentHTML (имхо, удобная штука), поправили баги в визивиг-редактировании и регулярках. Ну и еще пара десятков фиксов старых косяков по мелочи...

Насколько я в курсе, жесткого лимита нет, почти всё зависит от конкретного макета. Но есть правило юзабилити, что строчки текста не должны быть длиннее 60, в крайнем случае 70 символов. От этого, имхо, и стоит "плясать".

Соответственно, можно выбирать по ситуации, какой включалкой контекста воспользоваться: overflow, display:inline-block/table(-cell) либо упомянутый float. Помня, что у каждого варианта свои преимущества и ограничения...

В 80-90% случаев так и будет, потому что новые браузеры ведут себя по новой спеке, а сама спека написана по "усредненным" результатам наблюдений за поведением старых. Но в остальных старых браузерах скучать не придется. У старых IE к списочным "запчастям" вне списков (равно как к несписочным деталям в списках) особенно трепетное и "творческое" отношение...

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

Ух ты! От ссылки "два" у меня была та же реакция . До чего дошел прогресс, ай да третий CSS!

Может, просто сделать синий чуть темнее, тогда он будет похож на водную гладь (которая, логично, снизу)?

Я придерживаюсь мнения, что можно использовать всё, что эффективно решает задачу и не запрещено законами и спецификацией . По крайней мере, на мой взгляд, такое решение лучше, чем обнуление font-size (и последующая неизбежная борьба с фантомными пикселями в вебкитах). Проблем, честно говоря, не вижу вообще никаких. Даже если понадобится перевести код в XML — его всегда можно будет распарсить какой-нибудь HTML5lib, а потом просто поменять тип сериализации. Разве что косые взгляды со стороны других разработчиков старой школы... Правда, здесь я немножко предвзят, поэтому настаивать не буду UPD: может, холивор про опциональные закрывающие теги есть смысл выделить и вынести во флейм? А то к теме топика оно вроде не относится, но какую-никакую познавательную ценность, имхо, имеет...

Как вариант, фон для html + фон для body + два псевдоэлемента :before/:after для второго (или обоих) по такому принципу. IE7 и ниже придется довольствоваться простым бордером (хотя, если есть избыток времени и желания, можно поколдовать с фильтрами)...

Вот наглядный пример недостатка "навыков на уровне рефлексов" перед осознанным знанием, к которому я призываю А вот это правильный подход . Здоровье надо беречь!

Лучше ее не допускать . Если человек знает о существовании неявно закрывающихся элементов (например, о том, что <p> закрывается при первом открывающем теге блочного элемента), ему просто не придет в голову городить такую конструкцию. В отличие от человека, который слепо полагается на "рефлексы" (ну ладно, навыки, полезные при работе с совсем другой технологией ("возможно, когда-нибудь в будущем") — и слепо верит, что "правильное закрытие тегов" (в т.ч. одиночных) защитит его от всех проблем. Но поленился даже заглянуть в спеку той технологии, с которой он работает в реальности. Возможно всякое, но тёплое и мягкое всё-таки лучше различать (и вообще советую читать этот цикл статей того же автора вплоть до понимания Опциональные теги работают железобетонно, а совместимость с XML — нюансы, какие проблемы? (шутка, но с долей шутки Когда, не дослушав, бросаются учить других — имхо, едва ли лучше...

Можно очень многое через градиенты. Буквально сегодня у конкурентов вышла хорошая статья по теме. Еще много ценных образцов можно подсмотреть на CSS1k.com...

Был совет Я привел пример, когда полное соблюдение правил XML — нижний регистр, кавычки, закрытие всех тегов в правильной последовательности и т.п. — не только не избавляет от проблемы при работе с HTML, но наоборот, отвлекает от путей ее решения. Да, ситуация искусственная, но взята не из пальца, а из моей личной командной практики (плюс совсем недавно аналогичный вопрос был на этом форуме). Так "не стоит" или "нельзя" (не в смысле "запрещено", а в смысле "невозможно")? Опаньки. В основах плаваем, а других учить — туда же. Ну-ка, марш за парту... (саркастически ухмыляется, поигрывая здоровенной деревянной указкой) В общем, имхо, лучше делать дело, руквовдствуясь знаниями и пониманием предмета. Как человек. А не "рефлексами" — как, пардон, подопытное жЫвотное...

Она просто более необъятная, т.к. содержит предписания и для штатных, и для ошибочных ситуаций (причем не только для авторов, но и для браузеров). Упомянутый "otherwise" — тот самый случай ("вообще такого быть не должно, но если вдруг случилось — делайте то-то и то-то"). Есть сокращенная версия только для авторов (хотя и она впечатляет масштабами).

С точки зрения HTML4, слеш в <br /> — ошибка. Правильный браузер должен закрыть тег по слешу и отобразить знак ">". Опустить опциональный тег — не ошибка, а разрешенный спекой вариант синтаксиса. Именно. Вот каков будет итог кода <div style="color:red"> <p style="color:green">Хочу абзац <ul> <li>co списком</li> </ul> внутри </p> </div> какого цвета будет слово "внутри" и почему?

Именно sigma77, видимо, намекает на DOM, которую браузеры из этой разметки строят. Она при таком раскладе может быть о-очень разная...

Вот как раз не надо путать тёплое с мягким. XML — это XML, а HTML — это HTML, различий между ними больше, чем общих черт, и не надо даже пытаться натянуть шкуру одного на скелет другого (W3C вот 12 лет пытались — и чего добились?). Наоборот, постоянная оглядка на XML может привести к куче сюрпризов и непоняток при работе c HTML (а-ля "у меня же всё закрыто, в правильной последовательности, почему же мой список в абзаце не наследует его цвет?"). Я бы наборот рекомендовал новичкам осознанно (!) не закрывать все неявно закрывающиеся элементы (и даже опускать открывающие <html> и <body>, где позволяет окружение) — чтобы лучше прочувствовать специфику HTML DOM (что во что может быть вложено и т.п.) и логику парсера. Это знание избавит от удивления и при работе со скриптами (особенно с innerHTML и таблицами). А на XML, с его тремя-четырьмя безусловными простыми правилами (рассчитанными, если верить рекламным статьям начала 00-х, на парсинг тостерами и микроволновками) и блондинка перейдет без труда в любой момент. Если это ей действительно будет надо.

Имхо, всё проще: наличие исключения подтверждает наличие правила (для всех случаев, кроме явно указанных исключений)*. Поэтому, если сказано, что что-то "can be" там-то и там-то — это подразумевает, что в любых других местах это что-то "can not be"... *принцип римского права, который мы привыкли слышать в урезанной до непонятности форме "исключение подтверждает правило"