SelenIT

Если ориентироваться на IE8+, в принципе, можно и одним дивом обойтись, с градиентом вместе. Но для въедливого заказчика, пожалуй, лучше сделать с оберткой.

Всегда при подобных проблемах смотрите итоговую DOM, которую строит браузер. Она может сильно отличаться от того, что написано в коде. Особенно для элементов с опциональным закрывающим тегом, как в этом случае. HTML — это не XML, где можно вкладывать что угодно во что угодно, лишь бы порядок закрытия тегов сошелся.

Телепательная машинка подсказывает, что "элементы, задействованные на уровне сервера" — это что-то вроде <form runat="server"> из ASP.NET (таким штукам, как правило, ID-шки раздает сам фреймворк, порой абсолютно непроизносимые). А "не задействованные..." — соотв-но, все остальные.

А в абзацах ли? Посмотрите DOM страницы файрбагом ("стрекозой", "инструментами разработчика" и т.п.) — наверняка удивитесь. А потом внимательнее присмотритесь к описанию тега <p> в спецификациях...

Ага, похоже на баг валидатора. Возможно, как-то связано с этим (судя по симптомам). Можно дописать туда же в багзиллу, авось обратят внимание и поправят. Хотя при том бардаке, что творится в CSSной рабочей группе (производители браузеров наперебой толкают в стандарт свои проприетарные рюшечки, а основополагающий модуль синтаксиса 8 лет лежит в глухом черновике, и т.п.) это еще мелочь. Вообще само понятие "валидации CSS3" (при безверсионной-то модели развития!) в таких условиях вызывает у меня обоснованные сомнения...

Position: fixed напрочь рвет связь элемента с предком и привязывает его к одному месту окна, фиксируя при прокрутке. Зачем он тут вообще?

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

Известный способ (если не самый популярный), но 1) в вебкитных могут всё равно оставаться однопиксельные зазоры, 2) не всегда явный размер шрифта подходит (напр., его уже не смасштабировать вместе со шрифтом родительского элемента). Решение тем и отличается от его эмуляции, что работает всегда, а не только при некоторых допущениях

Насколько я в курсе, истории успеха обычно строятся по чуть другому шаблону: у человека был стабильный среднеунылый источник средств к существованию плюс прикольное хобби just for fun. А потом внезапно (само или с помощью "доброй феи", между делом предложившей запихнуть это прикольное хобби в няшный беленький корпус с зализанными углами) обнаруживается, что это хобби способно приносить фан и множеству других людей — в т.ч. тех, кто готов платить за это баблосы, в т.ч. не самые малые . Впрочем, не знаю, может, это была специфика еще того техноромантичечного века... хотя, по-моему, в эту схему и Цукерберг неплохо вписывается...

Да и самого 3D в вебе уже было, что букв на аббревиатуры еле хватает — VRML1, VRML2, 3DML, X3D... Но шут его знает. Тогда ведь не было "Аватара", притянувшего за собой "очкастые" телевизоры с веб-клиентом, и понтовых мобилок с экраном а-ля советские "стереокалендарики". А это уже, в отличие от угловатых VRMLных и квадратно-гнездовых 3DMLных ерундовин на мерцающих ЭЛТшках (вдобавок требовавших громоздких плагинов), прикольный генератор вау-эффекта абсолютно задешево. Если браузерное 3D насобачится подстраиваться под такие девайсы — какую-то долю рынка рекламных фишечек оно, возможно, и прихапает...

Видимо, корень проблемы в том, что по 7-ю версию IE не делал различия между html-атрибутами и одноименными DOM-свойствами. Начиная с 8-ки это стали вычищать, но, похоже, не всё и не сразу. В 9-ке colspan/rowspan вроде уже адекватны, но, ЕМНИП, бывают сходные проблемы с новыми атрибутами HTML5 типа required...

Лично я использовал в виде По идее, only screen должно предохранять от десктопов, да и мониторов с максимальной физической шириной 480px давно никто не видел. Честно говоря, не помню, где нагуглил, но мою проблему это решило и жалоб не поступало

Как правило, психология. Обычно мозги нацелены или на решение проблем, или на поиск виноватых/прочих объективных (в кавычках и без) помех. Это как Quirks mode/Standards mode в браузере — либо одно, либо другое. Почему напускная. Я действительно симпатизирую энтузиастам-самодельщикам, у которых что-то получается (а тем, у которых получается хорошо — по-доброму завидую). Хотя сам пока ничего не добился, увы (но я и не гений, мягко говоря).

Это для айфонов (которые бывают шибко умные, но недостаточно разумные)

Нет, везет некоторым из тех, кто пытается делать хоть что-то (придумывать принципиально новое или улучшать/оттачивать/делать привлекательнее для масс что-то существующее — уже не так принципиально). Тем, кто ничего не делает, а только ждет готового будущего на блюдечке и ноет, что "будущее какое-то не такое", повезти не может по определению. Сугубо имхо, разумеется.

1) Реальная востребованность возможна в специфических веб-приложениях (развлекательных прежде всего) под iШтуки и андроид-планшеты (судя по caniuse.com). В остальном вебе будут пиариться как технология ради технологии (прикольные демки, конкурсы а-ля CSS1k и т.п.). 2) Да, как только возникнет реальная практическая потребность (см. п. 1). 3) Сплэш-скрин Сафарей — это оно? 4) Старье — нафиг, выбирать те сферы, где его нет по построению (опять же см. п. 1). Либо старая добрая грейсфул деградейшн 5) Да, определенно. Еще :target как минимум (на котором уже делают анимированные баяны и табы), а также всевозможные :checked, :(in)valid и т.п. моднявые подвыподверты контролов форм, справедливости ради. Но в целом согласен, что до полной замены JS-анимаций стилевыми еще о-очень далеко. Мне пока обычную выпадающую менюшку с задержкой исчезновения при mouseout-е (чтобы не приходилось, промахнувшись на пиксель при раскрытии четвертого уровня с третьего, чертыхаться и начинать с начала) кто-нибудь бы показал... Другое дело, что даже скриптом очень трудно оживлять то, что браузер и в статике-то не умеет. Например, изображать объемную перспективу...

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

С таким отношением' date=' как по ссылкам, имхо, того будущего, которое "обещали" Ефремов с Булычевым, имхо, мы и в виде "нарисованной превращающейся картинки" не дождемся. А вот с подходом Дэнни Дэвиса (из хайнлайновской "Двери в лето", явно во многом писаного с энтузиастов-самодельщиков типа Возняка с Джобсом в их юные годы), или, на крайняк, создателей "Марсохода" и "Кулибина" — кто знает

На чистом CSS, да для произвольной высоты, да с горизонтальным основным порядком — имхо, вообще никак, и еще долго. Если бы блоки шли сверху вниз, мультиколонки могли бы выручить (возможно, в комплексе с writing-mode для IE8+). А из скриптов вроде как jQuery Masonry как раз "в масть"...

Всегда или только когда курсор в этой textarea стоит? Имхо, если второе, то просто textarea "захватывает" энтер как обычный вводимый символ. Может, на textarea onkeypress продублировать?

Судя по примеру из спеки, вполне по назначению (имхо). Сам слышу про этот атрибут впервые, не без удивления (тоже считал скрытие/показ прерогативой CSS), но опред. логика в нем есть — этакий "ультрарадикальный" disabled...

Дурацкий не дурацкий, но это единственный реальный выход. Остальные — лишь эмуляция. В HTML (включая 5) есть еще выход — воспользоваться опциональностью закрывающих тегов для <li> (кстати, IE7 эти закрывающие теги в любом случае игнорирует). Тогда и читабельность сохраняется, и пробелов между элементами не остается. В XHTML, понятно, так нельзя, но нужно помнить, что 99% "якобы XHTML" — не более чем самообман и обман валидатора...

Отступы между инлайн-блоками — обычные межсловные пробелы и убираются с помощью word-spacing: -[величина пробела] (для практически всех популярных шрифтов, кроме Верданы, это -.25em). У вебкитных браузеров с этим есть баг, но на него существует противоядие в виде display:table для контейнера. Недавно обсуждалось поблизости.

С точки зрения валидности — полностью едино. Валидности пофиг на смысл, ей важно формальное соблюдение правил вложенности (для разметки) и отсутствие незнакомых слов (для стилей, хотя там само понятие "валидности" весьма произвольно). Запись <td id="div1" class="left green content bbb" style="color:red; text-align: right"> вполне себе валидна, хотя нарушает кучу "правил хорошего тона". А так, имхо, CSS на то и C, чтобы накладывать по каскаду всё, что нужно, от всего, что можно. Т.е. мультиклассы — самое прямое использование мощи CSS. Само собой, имена классов должны быть "говорящими", крайне желательно — чтобы они отражали суть элемента, а не только особенности оформления (хотя это вопрос дискуссионный, в пользу презентационных имен классов тоже есть разумные доводы, главное — не доводить их до абсурда а-ля пример из предыдущего абзаца.

Так просто не получится, у таблицы есть строго определенная модель содержимого (thead/tfoot/tbody — tr — th/td), и всё, что в эту модель не укладывается, парсер просто выбросит прочь, как организм отторгает чужеродную ткань . Div — контейнер блоков, а не просто абстрактная объединялка чего угодно. Строки таблицы можно сгруппировать с помощью tbody.