SelenIT

У меня первая мысль тоже была про телеобъектив. Кстати, "общепримиряющим" (устраивающим оба прочтения) решением, наверное, было бы что-то вроде такого

Зачем три таблицы, когда по факту одна? И да, у IE7- есть проблемы с border-spacing-ом и т.п., хотя при его теперешней доле, имхо, на это можно и забить. А вообще, на мой взгляд, вместо устаревших rules="cols" лучше задать какие надо бордеры ячейкам (в CSS) — и гибче в плане оформления, и реакция браузеров предсказуемее...

Да, этот. И всякие вариации на эту тему.

Можно еще как-то так.

Для настоящего фикседа, насколько я в курсе, не решается. Более-менее решается в эмуляции типа такой.

Насколько я понимаю, он заставляет браузер учитывать указанные ширину и высоту. Поскольку у картинки дефолтный display:inline, высота и ширина применяются к ней только благодаря наличию intrinsic dimensions ("внутренне присущих" размеров). В других браузерах поведение картинки изначально ближе к inline-block (имхо, именно его и логично бы сделать по умолчанию), поэтому указанные размеры держатся без подпорок. Вообще ситуация с недогрузившимися картинками для браузера так или иначе нештатная, и последнее слово так или иначе за разработчиками. У Мозиллы есть логика в том, что, раз уж картинка недоступна, чтобы хотя бы текстовый эквивалент был доступен в максимально читабельном виде -- без обрезки и скукоживания ("дизайн — ничто, содержание — всё"). У Хрома логики нет, это тупо баг . Опера, видимо, пытается усидеть на двух стульях (и дизайн не развалить, и текст худо-бедно показать, обычно тексты короткие). И задача унификации этого разнобоя не так уж тривиальна. Для критичных участков оформления (не иллюстраций и т.п.) есть резон использовать приемы типа такого...

Для FF проблема решается через display:inline-block для img (и, имхо, это надо бы вообще внести во все ресеты, т.к. сам по себе img по дефолту ведет себя именно как инлайн-блок, а вовсе не как инлайн). Опера чуть упрямее, но ей (по крайней мере последним версиям, в старых не проверял) вправляет мозги немножко JS. Но вот Хром, зараза... P.S. Транзишнл-доктайпам, вызывающим у браузеров когнитивный диссонанс limited quirks mode, уже лет 8 как пора на свалку. Они были нужны исключительно для временной поддержки проектов, изначально завязанных на "фичи" HTML3.2, а в эпоху HTML5 они вообще ни для чего не нужны.

Я присмотрелся к статистике получше и удивился еще сильнее: где в ней FF9? По наблюдаемой картинке поведение того, что она выдает за FF2, очень сильно похоже на то, как должен бы вести себя FF9 (взлет медленнее предшественников, вероятно, из-за общего празднично-каникулярного затишья). Имхо, пора писать суппорту лирушечки гневный багрепорт! )

ЕМНИП, Опера-в-мини уже не первый раз за последних два-три года преодолевает 10%-ную планку. Интереснее, имхо, статистика мобильных разрешений экрана, вот там как раз сейчас должна идти медленная, но неотвратимая революция. А по сабжу -- однозначно глюк. Может, это мобильный Огнехвост под вторым андроидом у них так распознается?..

Проще всего вставить внутрь этого блока обычную ссылку, сделать ей display: block с размерами нужной области и спозиционировать абсолютно в нужное место. А чтобы текст ссылки не мешал, можно, например, сделать ее полностью прозрачной (opacity: 0 + фильтр для старых IE). Можно поучиться у Стью Николлза, он некогда не одну @-у съел на таких эффектах

<meta name="keywords" content="список, ключевых, слов, через, запятую"> <meta name="description" content="Здесь идет краткое описание страницы, которое можно показать в выдаче Гугла и которое сможет заманить пользователя на нее."> Ключевые слова почти ни на что уже не влияют, но если они будут встречаться в заголовках, ссылках и т.п. — вреда точно не будет. А вот описание есть смысл сделать качественным, информативным и честно представляющим страницу. Увлекаться не стоит, десяток-другой ключевиков и один небольшой абзац описания — самое то.

В целях оптимизации сайта это не нужно.

Скачут не ячейки, скачет текст (из-за шрифта при наведении). Ячейки распирает только при сжатии таблицы донельзя, когда самое длинное слово упирается в паддинги (можно при наведении их просто уменьшить хоть до нуля). А вот border-collapse: collapse в FF9 дает забавный фичеглюк Кстати, если под новые браузеры — можно же, по идее, "в лоб" transform заюзать (а под IE8 попробовать старый добрый zoom либо фильтры)...

Если абстрагироваться от формы круголков при наведении, без допоберток получилось как-то так. В старье, естественно, "изяшная деградация". Это черная магия. Letter-spacing тут ни при делах, за пробелы отвечает word-spacing, а от бага в вебкитах помогает как раз display:table для контейнера. Хотя в данном случае, поскольку шрифт ссылок всё равно в пикселях задается, можно и font-size контейнеру обнулить, грубо, но действенно. Если уж от человеческого решения — честно убрать злополучные пробелы в коде — какие-то высшие соображения отталкивают...

Ни один браузер не поддерживает ни одну спецификацию W3C полностью. Sad but true. Да и данная спецификация еще только кандидат на утверждение. Но справедливости ради, в Сафарях 5.1.х и Операх 11.6х дела с сабжем получше, чем в предыдущих. Кстати, одно из решений для Сафарей (актуальных) и Хрома — заменить border на box-shadow с нулевым размытием, она там, вроде, и рисуется поаккуратнее...

Сафари до предпоследней, кажись, версии не понимал border-radius без префикса -webkit-. У Оперы до последней 11.6x была известная проблема с border-radius для img, можно посмотреть пару вариантов решения.

Проблемы — только если понадобятся элементы, "торчащие" из этого блока, типа выносок, кастомных всплывающих подсказок и лайтбоксов, при них будет появляться скроллинг. Вообще всё верно — clear работает в рамках блочного контекста, по умолчанию блок идет в том же контексте, что левая колонка, а overflow создает для блока свой отдельный контекст. Такой же эффект дают display:table/table-cell (поэтому в таблице clear не проваливался) и inline-block, можно подбирать что-то из этого по ситуации.

Почти всё. Если радиус закруглений у картинки задан не в процентах

Поздравляю!!!

Маленькое уточнение: по терминологии, пустым тегом называется тег без содержимого (<a></a> или <a/> в XML). А тег <a> без атрибута href допустим в HTML5, но толку от него немного (:hover в IE6 к нему не применяется, :focus оно не ловит и т.п.), ровно с тем же успехом можно использовать любой другой тег (в т.ч. повесить активацию смены картинки напрямую на li:hover, без прослойки).

Первым делом доктайп правильный нужен.

На сабжевый вопрос ответ "Никак и незачем". Форма в HTML -- всё от первого встреченного <form> до первого встреченного </form>, остальное должно игнорироваться (из-за багов браузеров возможны варианты, но, очевидно, полагаться на них нельзя — это же баги). На обдумывание в этом направлении даже время не тратьте. Для более детального ответа на вопрос "А что делать и как быть?" не помешало бы немного подробностей, какие данные, откуда, куда и когда надо передавать...

Увеличить высоту активной вкладки и заставить ее слегка "наехать" на основной блок?

Какой доктайп? И, конечно, минимальный пример кода бы не помешал. Скорее всего, кодировка в <meta charset="..."> не совпадает с реальной кодировкой документа.

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