SelenIT

Лично я — отрицательно (по тем же причинам, что озвучила sigma77 — никогда не скажешь наверняка, что у конкретного пользователя пробел будет точно 5px или точно .333em). Как и на обнуление font-size контейнеру с последующим выставлением его потомкам (в каких-то браузерах, не помню точно в каких, при этом оставались однопиксельные разрывы), хотя при фиксированном шрифте это чуть ближе к делу. На мой взгляд, единственное реальное решение — честно убрать эти пробелы, остальное — костыли. Но тогда приходится идти на компромиссы в плане читаемости кода. В частном случае списков можно воспользоваться преимуществом опциональных закрывающих тегов, при этом тоже пробелов не будет Почти аналогично в плане поведения самих блоков, не аналогично в плане влияния на внешний контейнер этих блоков (inline-блоки хотя бы сами не требуют clear-ить контейнер). Поэтому, сугубо имхо, inline-block всё-таки чуточку лучше. Но лишь самую чуточку

Имхо, inline-block скорее может претендовать на замену самим float-ам, с вкусными плюсами в виде произвольного выравнивания по вертикали и жирным минусом в виде значащих пробелов между тегами. Зато проблема необходимости в clearfix-е (в любом виде) отпадет сама собой. Про издержки inline-block для контейнера sigma77 уже написала, так что это явно не универсальное решение. Хотя иногда может выручить.

Кстати, тоже был бы счастлив слегка освежить эту историю про 100.01% и IE. Это связано с увеличением/уменьшением размера шрифта? А то у меня в памяти отложилась только вот эта таблица, где проблемы были вовсе не с IE, а главным образом с архаичными Операми (лет 6 как неактуальными). И, похоже, не только у меня. Сам давно не сталкивался (последнее время перешел на пиксели), на полномасштабное исследование не хватает времени. Так что буду безумно благодарен за любые более-менее свежие ссылки по теме! Упс: уже после поста вспомнил, что не так давно сам боролся с округлением em-ов в IE (хоть и слегка в др. контексте). Может, эти 0.01% реально уменьшают погрешность округления? Но, насколько я сейчас припоминаю, полностью свести эту ошибку на нет мне тогда всё же не удалось (и в других браузерах тоже, просто сбойных абзацев стало меньше)...

С display:table/table-cell/inline-block обрезания границ тоже не происходит. И с банальным float для контейнера (я очень долго других способов просто не знал). Правда, остается вопрос с шириной, но он решается (в частном случае, когда контента много — сам собой). Чисто идеологически, наверное, да, clearfix — меньшее зло (при том, что сама раскладка блоков float-ами — вынужденная мера). Но IE7(-)...

kira01, вам тут намекнули, что кавычки нужны для значения атрибута, а не его имени. И единица измерения "px" — она из CSS, а не из HTML (браузеры, скорее всего, поймут и так... но не факт, так что лучше сразу писать правильно).

Если критично, для старых IE можно вбить экспрешн, напр., из этой давней статьи моего бывшего коллеги. Элементов в списке вроде немного, сильно страницу это не перегрузит (а если и... — то так им, ретроградам, и надо!)

Скорее всего, это проблема шрифта. У меня в FF 3.6/WinXP в Википедии отображается нормально ("квадратик" появился только для WORD JOINER-а, который 0x2060 или 8288). Шрифт, надо полагать, дефолтный Arial...

Да, я имел в виду именно это . Есть хорошая статья по теме у Тьерри Кобленца (автора вот такого безобразия). Еще показательный пример есть в комментах к соотв. статье на Хабре.

В каком браузере? У меня в FF 3.6/WinXP всё нормально, красный лишь первый...

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

Абсолютно корректно. Как минимум, не менее корректно, чем верстка колонок float-ами Для создания контекста можно еще display:table или table-cell. У каждого способа свои плюсы и минусы (у overflow — невозможность сделать позицинионированные потомки визуально выступающими за блок, у display:table — ширина по умолчанию обжимается по содержимому). В большинстве случаев overflow — самый безболезненный вариант. У вариантов без создания контекста (clear:both для псевдоэлемента :after и т.п.) минус в том, что для старых IE всё равно приходится использовать костыль с контекстом (hasLayout), отчего по-разному ведут себя margin-ы и т.п. А пустой невидимый div с clear — универсально, но некрасиво и несемантично...

В данном случае ничего не скрывает. А используется исключительно ради побочного эффекта, описанного в цитате выше — создания нового контекста форматирования.

надо бы еще Апач перезапустить после правок конфигурации...

Не имеет. Внутри ссылки никаких "левых" интерактивностей быть не может, а то у браузера будет когнитивный диссонанс в момент клика. Если укротить кнопку стилями ну никак не выходит, можно по умолчанию оставить некрасивую дефолтную кнопку, а по мере загрузки страницы с помощью скрипта заменить или перекрыть ее красивой ссылкой. Тогда со включенным скриптом будет красиво, а без него — скромно, но хотя бы функционально...

Пока не знаю. Подозреваю, что на сегодня куча дивов — единственный практически применимый вариант...

В полиграфии еще не то встречается — напр., текст вокруг контура силуэта человека. Иногда дизайнеры и в веб такое тянут, приходится изворачиваться. Кстати, c inline-SVG это, случаем, изящно не решается?

Canvas бывает непрямоугольным? Сорри, можно пример?

Имхо, потому что CSS всё-таки в первую очередь создан для HTML, а HTML — это поток. Поэтому все типы блоков в CSS по умолчанию созданы быть максимально гибкими. Ограничь ширину — содержимое будет "разливаться" в длину. А еще содержимое может быть динамическим, а еще юзер может в любой момент ВНЕЗАПНО111 изменить размер шрифта и т.п. Задача, в которой приходится одновременно задавать (точнее, жестко ограничивать) оба измерения блока — относительная редкость по сравнению с задачей вписывания произвольного блока в заданное пространство по одному измерению. Плюс динамика — что проще анимировать скриптом, размеры или, скажем, свойство clip, где как раз все края задаются сразу одной строкой? Поэтому и живут размеры по раздельности. Удобств от этого много, а выгода от объединения — разве что небольшое сокращение кода, но с этим и gzip неплохо справляется... Вот возможность задавать непрямоугольные области была бы действительно кстати. Тем более в HTML она в каком-то смысле давно есть — в виде <area shape="poly">. А в CSS она становится особенно актуальной с приходом всяких трансформаций (а то несолидно как-то, когда блок повернут на 45°, а текст обтекает его по-прежнему как тупой квадрат)...

Можно в новых браузерах, с помощью box-sizing:border-box. В IE6-7 — только в Quirks mode. А так нужно или задавать размеры с учетом добавления паддингов и бордеров, или (чаще) указывать либо размеры, либо паддинги (напр. width:100% для блочных элементов обычно можно не указывать, они и так растягиваются на всю доступную ширину)...

xlife, что у вас делает <meta charset="utf-8" /> внутри <title>? Неудивительно, что парсер его там не находит и ругается, что "кодировка не задана, а не-ASCII-шные символы используются"...

У меня есть iPad на работе, смогу посмотреть завтра во второй половине дня, если дело терпит. Правда, как там делать скриншот, еще сам не знаю(. Но вообще, по моим наблюдениям, особых отличий от десктопного маковского Сафари при таких же размерах окна там быть не должно (если не использовать спецсредств типа смены стилей в зависимости от ориентации и т.п.)...

Не должно такого быть, проверьте еще раз. Вот на несоответствие фактической кодировки заявленной (напр. в meta charset указан windows-1251, а файл сохранен в utf-8, или наоборот) ругаться может.

Это еще зачем? Для простой проверки, отправлена ли форма, в PHP достаточно !empty($_POST), а вообще проверять надо те поля, с которыми предстоит работать, а не какие-то "левые". Но тут, насколько я дотелепал, нужно своё действие для каждой из кнопок...

По стандарту, насколько я в курсе, должны передаваться две переменные — BTN_EDIT.x и BTN_EDIT.y, с координатами места клика. Можно ориентироваться по ним. Хотя у "убогого сабмита" тоже можно убрать рамку, скрыть текст и подложить свой фон (хотя в старых браузерах с этим приходилось повозиться)...

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