SelenIT

В спеке говорится, что «если указано только одно значение, второе значение предполагается равным 'center'». Соотв-но, для самого значения 'center' получается, что оно задается для обеих координат.

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

Либо background-image:url(http://cs616524.vk.m...TniGjCTk_XA.jpg); background-repeat: no-repeat; background-position: centerлибо background: #EEEFF3 url(http://cs616524.vk.m...TniGjCTk_XA.jpg) no-repeat center т.к. backgroung-image не может переварить значения для др. свойств.

Вообще-то он уже пару месяцев как Candidate Recommendation. Не путайте Editors draft (редакторскую версию спеки с последними правками, существующую всё время, пока над спекой ведется хоть какая-то работа, хранящуюся в девелоперской ветке работчей группы) и Working Draft (статус спецификации, еще не готовой, но уже опубликованной в разделе w3.org/TR). Не встречал подтверждений. Большинство более-менее разбирающихся людей, у кого я спрашивал, говорят, что практически не влияет. Сюрприз от W3C:) Это не обертка.

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

Кстати, да, метрики же для Win и Mac разные. Сталкивался с ними в самодельном иконочном шрифте. Теоретически, можно попробовать пересохранить ttf тем же FontForge-м, слегка «подкрутив» метрики, и попробовать перегенерить весь набор заново. Приличные шансы, что поможет.

Честно говоря, с задачей расстановки постоянных промежутков между инлайн-блоками я пока не сталкивался . Мне чаще встречалась задача гибкого растягивания такого списка по ширине (тогда justify + псевдоэлемент-распорка с width: 100%) и сжимания вплотную (в боевых проектах, если нет возможности честно удалить пробелы, в основном использую font-size:0). Ну а так, видимо, альтернативы letter-spacing'у нам просто не оставили. Можно посмотреть в сторону флексбоксов с justify-content: space-between/space-around. А про монокультуру вебкита это я просто ворчу по-стариковски, не обращайте внимания. Просто тут недавно многие радовались «пусть будет один вебкит, он классный», а другие вспоминали, что IE5.5 в своё время тоже был классным. И увы, чем дальше, тем больше тревожных аналогий...

Скорее всего не нужно. Шрифт древний, даже старые источники приводят огромные цифры его распространенности как для Win, так и для Mac (только с iOS вот загвоздочка), предлагая Geneva либо Segoe в качестве фоллбэка (плюс Вердану на крайний случай).

Мда. Баги вебкита — престранный предмет: вроде пофикшены, вроде и нет. Вот они, первые ласточки новой монокультуры...

Padding-top в процентах?

Без хорошего JS-пинка типа html5shim или банальной стопки document.createElement(...). Который, к сожалению, формально считается «блокирующим ресурсом».

Только делая надписи картинкой (или флешем, как баннер «Новый дизайн...» на том же fl.ru, хотя это уже само по себе некроссплатформенно). Что может быть оправдано в редких исключениях типа текстовых логотипов — но и только.

Боюсь что так: наложение скриншотов с IE9 и Fx в Win7.

Похоже, line-height в винде центрирует прописные, в маке — строчные. А в этом меню еще центр ul визуально поднят относительно видимой середины голубой полосы (ul высотой 40 прибит к верхнему краю nav-a высотой 44 и наезжает на верхнюю серую полоску). Может, раз уж элементы списка инлайн-блочные, лучше задать line-height: 44px самому ul, а li-шкам — line-height: 1 и vertical-align: middle, а height убрать?

http://htmlbook.ru/html/input/type

Самая удобная и наглядная сводка работ по CSS, пожалуй, здесь. Еще нескромно предложу вот эту попытку объяснения всего этого безобразия

Абсолютно правильно. Да, убрали. Теперь подзаголовки рекомендуется размечать как-то так.

Да, Latest Editor's Draft — это самый новейший вариант текста с текущими редакторскими правками (в результате которых могут возникать противоречивые куски и т.п.), а Latest Published Version — более-менее вычитанная редакция «для всех» (формально ее нельзя считать окончательной до перехода в статус Recommendation, некоторые вещи в ней могут еще измениться или перейти в другую спецификацию — они перечислены как «features at risk» в самом начальном разделе «Status of This document», но в целом, начиная с нынешнего статуса Candidate Recommendation, ее можно считать достаточно стабильной). Предыдущая Published Version была в декабре 2012-го, следующей, имхо, можно ждать где-то через полгода. Следующее обновление статуса (до Proposed Recommendation — спецификация проработана теоретически и независимо реализована как минимум в 2-х браузерах), по этому же документу, ожидается где-то следующей осенью.

Скорее WHATWG разрабатывает «всё сразу», а W3C — частями (как бы «первая очередь» и «вторая очередь» «строительства» спецификации). Правильно.

В стандартном режиме (с доктайпом) высота строки не может быть меньше высоты строки, унаследованной от родительского блока (в данном случае это дефолтные браузерные 20px). В режиме ископаемой совместимости (без доктайпа) браузер пытается угадать, «что имел в виду автор», но может делать это как попало, вдобавок забывая всё новое (особенно это касается IE). Здесь лучше использовать вместо span-ов осмысленные элементы типа заголовка и абзаца.

Вот так на безретиновом айпаде в iOS6: Объяснения у меня пока нет. Шрифт всё-таки явно тот же, но хинтинг другой (или его нет). Припоминаю, что пару лет назад тоже сталкивался со странностями вертикального позиционирования в Mac/iOS. Этот фикс не поможет?

Очень похоже на неубранное дефолтное подчеркивание ссылки. Которое рисуется под пробелом, который почему-то есть между картинкой и закрывающим </a> у линкединовской и фейсбучьей кнопок, и нет у остальных.

Для продакшн-решения — вряд ли. Для саморазвития, чтоб научиться «еще и так» — имхо, вполне Кстати, выше я действительно что-то намудрил, можно намного проще. С «ушами», имхо, можно использовать тот же принцип — по паре псевдиков (верхняя и нижняя половины бордера с тенью) на каждое «ухо». Высота слайдера ведь, к счастью, фиксированная...

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

W3C решили утверждать спеку в 2 этапа. Сначала (в 2014-м, т.е. вот-вот) то, что уже более-менее стабильно и худо-бедно работает в браузерах — это HTML5.0. Потом (ориентировочно в 2016-м), впридачу к этому, остальные прикольные штуки, пока по большей части экспериментальные — это HTML5.1. Сейчас, правда, Стив Фолкнер с командой втихаря пытается переписывать в HTML5.1 и некоторые старые куски, «исправляя» то, что, по его мнению, Иэн Хиксон нагородил «неудачно» — но до 2016-го еще есть время, авось как-то утрясется. Есть еще «живой стандарт HTML» WHATWG, построенный по принципу «всё в одном» (и стабильная основа, и экспериментальные фичи, и вещи, вынесенные у W3C в отдельные спеки, типа микроданных и JS-овых API). Его до сих пор единолично поддерживает Хиксон. И есть мнение, что для разработчиков браузеров он где-то даже авторитетнее, чем W3Cшные «снэпшоты». Думаю, есть смысл равняться на HTML5.0 и «живой стандарт» (у последнего есть упрощенная «вебмастерская редакция»).