SelenIT

Если верить отладчику, который по F12, то как минимум под эмуляцией IE8 в IE9 eot-ки грузятся (браузер их запрашивает, при отключении стиля откатывается на дефолтный шрифт с засечками). Почему рендерятся крупнее, тоньше и с большим межбуквенным расстоянием — другой вопрос... На мой взгляд, самая большая беда от того, что адрес наверху не влезает в отведенные ему 270px (а из-за него не влезает заголовок, и дальше идет цепная реакция), убрать/увеличить ограничение ширины адреса и добавить clear для .block1 — и уже будет не так страшно. Еще вариант — поставить только для IE8- отрицательный letter-spacing.

Как минимум, это не по феншу спецификации: разрешенная модель содержимого у label — phrasing content («инлайновые элементов» по-старому). А ради чего всё? Только ради того, чтобы по клику на весь блок переключалась радиокнопка без скрипта?

Всё получается, вроде (чуть доработанный пример Artwanа).

Псевдоэлемента, наверное? А зачем два? А обычная box-shadow:inset проблему не решит? Если элементов и так куча, думаю, плюс-минус два бокса, пусть и позиционированных, фатально погоды не сделают, преждевременная оптимизация необязательна. Но, да, можно проверить.

Это как раз допустимо. А вот повторяющиеся id-шники и лишняя кавычка перед reqiured в <textarea> — да, бяка.

Возможно, причина в тегах HTML5, которые IE8- игнорирует без JS-пинка (html5shim и т.п.)

У микроданных и aria-ролей разные ниши. Микроданные служат для внедрения в страницу добавочной машиночитаемой информации о содержимом (например, о том, что некое название, некая картинка и некий текст в несколько строк — не какие-то несвязанные обрывки, а название, логотип и адрес одной фирмы соответственно), их главный адресат — поисковики (и другие «пауки», извлекающие из страниц осмысленные куски информации, напр. контакты для тел. книги). До микроданных эту же задачу пытались решать микроформаты и RDFa (они и сейчас еще используются, но ведущие поисковики сделали ставку именно на микроданные — см. ответ выше про schema.org). ARIA-роли — это про доступность (accessibility), их адресат — вспомогательные технологии (экранные читалки для слепых и т.п.). Они пытаются подсказать, для чего используется тот или иной элемент, чтобы эти технологии могли наиболее удачным образом представить его пользователю (например, не диктовать долго и нудно многоуровневое навигационное меню, а спросить «Пропустить навигацию?» и при утвердительном ответе перейти сразу к основному контенту). Новые теги частично пересекаются с ARIA-ролями (есть даже какая-то табличка соответствия между ними, там же, кстати, есть пояснения, в каких случаях стоит явно указывать роль, а в каких нет). Но они задуманы как более универсальная вещь, не ограниченная вспомогательными технологиями, и изначально нацелены на любые машинные анализаторы (включая те же поисковики и даже дефолтные стили браузеров). В том ли направлении пойдет эволюция этих анализаторов и справятся ли новые теги с этой задачей — поживем-увидим

А перед доктайпом ничего лишнего нет (коммента, BOM-метки от UTF-8 и т.п.)? Что показывают Browser mode/Document mode по F12?

IE в Quirks (в котором он не знает max-*) не валится случаем? Доктайп стоит?

Для работы в IE у самого шрифта должно быть выставлено свойство «устанавливаемый» (installable), где-то в самом файле (более точно, к сожалению, не знаю). Насколько я в курсе, fontsquirrel.com при генерации набора для @font-face ставит его автоматически, в редакторах шрифтов типа FontForge нужно ставить галочку в свойствах файла при сохранении, в других конвертерах/генераторах может понадобиться порыться в настройках.

А объяснить всё-таки придется . Clearfix — тоже далеко не панацея. В данном случае повезло, что у контентной колонки стоит margin-left на ширину левой колонки, иначе отсутствие отдельного контекста (а overflow — часто наименьшее зло для его создания) принесло бы очень неприятный сюрприз. Имхо, нужно разобраться с причиной, а не исправлять последствия.

К сожалению, это старый баг вебкитов и их наследников, который они не собираются чинить. Так что придется как-то обходиться без фонов для tr, а ставить их для ячеек либо для всей таблицы. А вообще в наши дни такие заголовки можно (и, имхо, желательно) делать CSS-градиентами и border-radius'ами.

Для меня — пожалуй, вложенность систем координат. От чего отсчитываются координаты прямоугольника (от viewBox-а или от width/height), на что из этого умножаются проценты в стопах и т.п. Плюс про preserveAspectRatio надо тупо знать, тот же Иллюстратор его по умолчанию не ставит, а без него бидапичаль. Ну и вообще, после того, как HTML годами отучал от записи оформления в тегах, приходится переступать через какие-то устоявшиеся привычки Причем Сафаря тоже в основном мобильная, имхо. Учитывая спорную репутацию iOS7, 6-я версия может оказаться более долгоживущей, чем предыдущие. В свете всего этого я считаю, что 1 строчка с префиксом всё же «меньше писать» по сравнению с целым файликом на другом языке, поэтому добавить поддержку iOS6-/Андроидов мне труда совсем не составляет, а IE9 обойдется . Но в любом случае делать SVG-файлик на случай, если браузер не поддерживает беспрефиксного градиента... ну никак, никак не могу отделаться от ощущения, что это очень напоминает вот этот сюжет

Она самая, спасибо! AFAIK, SVG, в отличие от растровой графики, можно внедрять в CSS и без base-64-кодирования (правда, с url-эскейпингом), и цвета при необходимости редактировать там же. Честно говоря, про вариант с отдельным запросом я вообще не думал (там же весь файл весит чуть ли не меньше, чем HTTP-заголовки, а если соглашаться на отдельный запрос, то так можно докатиться и до растровых картинок и поддержки IE8 заодно... ой, что-то меня не в ту сторону понесло ). Я вообще-то думал, что речь об убирании лишнего из результата того же colorzill'овского генератора и ему подобных... Видимо, кому как . Мне вот стыдно признаться, но я не смог разобраться за два года — до сих пор подглядываю в доки и те же генераторы... Уже не аргумент, потому что Под вопросом лишь единственный оставшийся префикс, и то от силы на ближайших полгода.

Обсуждали, да (к сожалению, не могу найти ссылку на то обсуждение), но я до сих пор не избавился от ощущения, что использование целого SVG в качестве фолбека для одних лишь градиентов подозрительно смахивает на использование джипа в качестве фолбека для скутера Имхо, если надо поставить градиент быстро и только для нового, а для хлама типа IE9 приемлема деградация, достаточно стандартного CSS-синтаксиса. А если в любом случае используется SVG, я не вижу смысла дублировать его еще и CSSом, усложняя и без того неочевидный (по крайней мере, для новичков) код. Разве что Опера на Престо с ейным хитровывернутым скроллингом, но она стремительно уходит в историю...

Главное отличие префикснутых градиентов от стандартных — там указывается не конечная, а начальная точка. Вместо "to top" пишется "bottom" (без "to"!) и т.д. А смысл в связке? Чем SVG-градиента, если он уже есть, недостаточно? Из-за того бага в Опере/Престо при скролле — так сколько ее осталось, той Оперы?

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

Мне не кажется — активные области там (по крайней мере у меня в Fx24) тупо прямоугольники...

У type="search", ЕМНИП, была проблема не то в Сафарях, не то в чем-то подобном, что размер шрифта можно было выбрать лишь из очень ограниченного набора. Про box-sizing я первым делом подумал тоже, но у меня проблема не воспроизвелась, возможно, тут что-то другое. Я, правда, предпочитаю элементам форм border-box задавать, у меня с ним проще получается.

Оперы 12.x и последняя (15+) — вообще-то два разных браузера, на разных движках. Но лично я не наблюдаю разницы ни в той, ни в другой (в таком примере, пробовал с разными стилями).

У каждой стороны веба своя специфика. Клиентская часть сильнее связана с визуальной стороной, с дизайном, спецэффектами, адаптацией вывода для разных устройств (в т. ч. мобильных), много сложностей связано с "глюками" браузеров и поиском обходных путей для них. На серверной стороне приходится больше работать с данными, решать задачи их хранения и поиска, красота этих решений никому не видна и проявляется лишь в функциональности, зато, пожалуй, поменьше непредсказуемости. Часто обеим сторонам приходится тесно взаимодействовать, так что минимальное представление о другой стороне никогда лишним не будет. Начинать, возможно, проще с клиентской - сделать интересный сайт можно и на статичном HTML. А дальше экспериментируйте со всем и смотрите, к чему сильнее тянет...

В каменном веке это можно было бы сделать через <area shape="poly"> c 4 координатами. Но сейчас, да, предложенный выше вариант самый логичный.

Учите HTML5, другого де-факто просто нет. Начните ознакомление с этой статьи. Она про PHP, но первый раздел актуален и для других серверных языков/технологий.

Пример для вдохновения: http://kizu.ru/fun/legends-and-headings/

Запись правильная. AFAIK, document.location считается устаревшим, актуален window.location, а window. можно безболезненно опускать. Неожиданности могут быть, например, если в структуре сайта появится категория cartridges)