SelenIT

Zverushka, если никто в ближайшие дни мне не укажет на фатальный недостаток fsz.001px, то перейду на этот способ Кстати, как оно на Win8 себя ведет?

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

Можно ссылку на такой материал (чтобы народ знал своих антигероев)? На htmlbook.ru написано корректно: button - функционально почти полный аналог кнопке input, лишь позволяет использовать разметку внутри кнопки. А ссылка и так перекидывает куда нужно при нажатии, никаких дополнительных интерактивных элементов внутри ее не нужно (более того, нельзя - иначе у браузера может возникнуть когнитивный диссонанс).

Да, желтая линия убирается через outline:none (желательно при этом продублировать для :focus стиль для :hover-а). Но вопрос, какого Хикси кнопка делает внутри ссылки (в нарушение всех спецификаций!), это не снимает

Зачем??? Чем несчастная кнопка так провинилась, что ее мало того что в заключение, так еще и в ссылку? И какого результата вы ждали от такого загадочного действия?

Мда, в фоксе .01px "округляется" до единицы. Зато .001px (одна тысячная px) даже в фоксе округляется до нуля (т.к. меньше порога в 1/128), в остальных (включая Win Safari 5.1.7) тоже, но как "лекарство для андроида" тоже срабатывает! Конечно, перепроверьте на всякий случай, но, по-моему, это оно

Вообще-то векторная графика, притом встраиваемая в HTML (!), поддерживалась в IE начиная чуть ли не с 5-й версии — в виде VML (из которого во многом вырос SVG).

Лично я к старым андроид-браузерам отношусь примерно как к старым IE: полной красоты не будет, условия работы специфические, некоторые отличия от макета (напр., узкая колонка текста, чтоб влез в экран) — не баг, а фича. Так что сильно переживать из-за них, имхо, не стоит, а в последних Андроидах уже почти нормальный Хром. Но только что проверил — с .01px вместо 0 мой Андроид 4.0 ведет себя чуть приличнее (однопиксельный зазор лишь между последними двумя пунктами в каждой строке).

Последнее время в основном через fsz0. А в исходном примере у контейнера фактическая ширина 978px, а каждый блок занимает 309 + 2*9 = 327px. Закономерно, что уместить 3 блока (981px в сумме) в строку можно лишь благодаря небольшому нахлесту, который и получается в Хроме 25+ при одновременном letter-spacing и word-spacing.

это не метод: http://habrahabr.ru/post/137656/

Там не проценты, а примерно постоянная для каждой платформы ∆t в миллисекундах (60—200 в их тесте). Но опять же, это когда всё собрано вообще в один файл. Как по мне, это говорит главным образом о том, что не надо доводить стремление к минимуму HTTP-запросов до абсурдных крайностей.

Замеряли они только загрузку (в т.ч. из кеша).

Насколько я понял, тормоза создают не сами картинки и даже не base64-кодирование, а просто разбухшие файлы, которые поневоле грузятся и парсятся в один поток, без использования преимуществ параллельной загрузки. Особенно в таком варианте, как там тестировали — конский HTMLник «всё-в-одном» vs. (малюпасенький HTMLник + умеренной величины спрайт). По идее, с отдельным CSSником эта проблема должна свестись к минимуму.

Видимо, area таки не подходит, т.к. его координаты задаются в пикселах. Для новых браузеров, в принципе, можно обойтись одним SVG, примерно так. Для кроссбраузерности, наверное, проще и надежнее взять библиотечку raphael.js.

Двухкилобайтных — имхо, сколько нужно. По-любому на загрузку их по отдельности, даже ради получения 304 Not Modified в итоге, каждый раз будут тратиться те же 2 кБ одних заголовков + двойной пинг до сервера, так что добавочные миллисекунды загрузки и парсинга CSSника (с сервера ли, из кеша ли) всяко должны оправдаться. Авторы нашумевшего исследования советуют вставлять в data-uri «не более 3-5 картинок до 15-20 кБ каждая».

Спасибо, что не в 6 раз

Из современных, насколько я в курсе, никто не заглючит. Но могут быть приколы с :before/:after внешнего блока (они окажутся вне «виртуальной tr», которой рендерер обернет внутренний блок), если таковые понадобятся.

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

Почему не хотят? По-моему, они вполне прозрачные. Просто при ховере непрозрачность границ накладывается на непрозрачность фона, и итоговая прозрачность остается очень маленькой (как я предполагаю, (1-0.6)*(1-0.6) = 0.16, т.е. итоговая как-бы-opacity = .84). Выход, имхо, либо такой, либо такой.

Флексбоксы упрощают многие прежде извратистые задачи, но конкретно для «плитки» они вряд ли будут лучшим решением. Хотя бы потому, что многострочные флексбоксы пока не поддерживаются в Фоксе . Без допразметки более-менее гибко, наверное, пока можно сделать разве что как-то так. Но при фиксированных размерах, наверное, старые добрые margin-ы будут самым простым и надежным выходом.

У меня Win 7 (32-битная) и одинаково, что в 26-й, что в 27-й бете. Поймать баг удалось лишь при зуме на 3 шага (кстати, в Хроме тоже, но на 4).

Можно. С прозрачными border-ами были проблемы в IE6, но это давно неактуально.

"Искаропки" да, но честная винда обязана тут же предложить юзеру приоритетно обновиться до уже, видимо, 11-го. Вот с вистой, да, грустно, но сколько там ее осталось...

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

Поддерживаю. Всё, для чего имеет смысл команда "Skip to content", вряд ли имеет смысл помечать как основное содержимое. Исключение - навигация по самому основному содержимому (ссылки на якоря внутри него), что и иллюстрируется примером в спецификации. Зачем отдельный section вокруг единственного article, притом "безголового", и к чему тут figure, иллюстрацией чего в основном потоке оно служит? По-моему, тут хватит одного article с заголовком (если эти анонсы имеют смысл, напр., в RSSнике), а то и без них, с неявными section-ами по заголовкам, нормально...