SelenIT

Это давно известная проблема - IE ниже 9-го не понимает XHTML и ничего с этим не поделать (можно "скормить" ему контнт как HTML или как абстрактный XML, но и то, и другое - костыли, а не выход). А другие браузеры, что, поняли? Это был настоящий XHTML, с правильным MIME-типом?

Солнечный парус в прошлом году вроде как успешно обкатали японцы. "Верить или нет" куче научных работ, основанных на результатах "Аполлонов" - личное дело каждого (свобода слова и всё такое), но прилюдно кричать о своей вере на слово развлекательной передаче Fox-TV (откуда, вдруг кто не знает, пошла байка про "голливуд") и выпертым из НАСЫ за пьянство лузерам типа Ральфа Рене и Билла Кейзинга (ну и их доморощенным повторякам типа Мухина, само собой) - прежде всего расписаться в собственном кругозоре на уровне тех самых попкорно-гамбургерных "средних американцев" из анекдотов. Вот хороший сайт для желающих прояснить для себя вопрос (ссылки на мнения противной стороны там тоже представлены, есличо). В данном случае не будет. Снова будет как-то так...

Вот нашел детальное объяснение баяна "по горячим следам" (и то в веб-архиве, основная ссылка протухла — 2004-й год как-никак!): http://web.archive.org/web/20041204125225/http://www.atsnn.com/story/30048.html Вкратце — 1) НАСА никогда не называло цвета на снимках "настоящими", а лишь "наиболее похожими на настоящие", 2) цветовое пространство RGB на значительной части марсианских снимков действительно искажено, т.к. в качестве точки красного берется 750нм — на стыке красного с инфракрасным (но это практически не сказывается на передаче окраски грунта), и 3) синий образец с этого циферблата ярко отсвечивает не только в синих, но и в ближних инфракрасных лучах, что добавляет путаницы при использовании фильтра на 750нм. Можно самим собрать в фотошопе снимки практически без искажений, используя канал 600нм (оранжево-красный) вместо 750 (черно-белые исходники каждого канала доступны на сайте НАСА), но в этом канале видно меньше деталей, а для НАСА важны именно они. А по Бёрду Киви, похоже, плачет орден почетного слоупока...

Если вы не настраиваете сервер на отдачу страниц с mime-типом application/xhtml+xml, то вы уже работаете с HTML5 . Он допускает XHTML-синтаксис для HTML-страниц (в отличие от настоящего XHTML, между прочим).

Первая же фраза по ссылке: "Once a box has been laid out according to the normal flow or floated, it may be shifted relative to this position" — "Когда элемент расположен на странице в соответствии с норм. потоком или зафлоачен, он может быть смещен относительно этой позиции".

Ух ты, и действительно ведь. Загадочная она всё-таки, норвежская душа!

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

Имхо, спорный тезис всё же. Обычно в футере второстепенная информация, а при фиксации она всегда будет отнимать место у действительно полезной. На очень тесных по высоте экранах (те же нетбуки) это может быть критично. Отпихивание футера контентом вниз в таком случае удобнее.

А смысл? Показать скрытый див, а через полсекунды загрузится запрошенная страница и всё исчезнет? Вариантов я вижу два: 1) добавлять параметр для новой страницы, чтобы она сразу отрисовывалась с открытым чем нужно; 2) подгружать контент аяксом, а URL для современных браузеров подменять через History API из HTML5 (если нужно). Первый способ проще и надежнее, второй моднее и круче

Switch74, спасибо, теперь резоны понятны. Хотя плодить скроллбары — тоже зло, в экстремальном случае "один таб — одна строчка, другой — тысяча", согласен, это зло будет меньшим, но вот когда во всех табах контента пикселей на 500-700 высоты, а просмотр идет на нетбуке с 600 пикселями высоты экрана на всё... имхо, лучше уж прокрутить весь сайт на пару оборотов колесика ради просмотра футера, чем сплющивать каждый таб до окошка на полдесятка строк с бешеной прокруткой внутри. Короче, надо смотреть по ситуации. Однозначно обзывать резиновый min-height "бредом", по-моему, всё-таки нет оснований.

Switch74, а чем всё-таки плох min-height в процентах?

По-быстрому склепать что-нибудь на базе таблицы, типа такого навскидку — не вариант?

Судя по всему, никто, кроме вас, не понимает. Я, например, не понимаю. Уж объясните как-нибудь популярно, для блондинок... P.S. Версию "прижатый футер не имеет смысла и противоречит чистой и светлой идее электронного документа" не предлагать — она тупо не соответствует действительности А проблема с перерисовкой вертикальных размеров у Оперы бывает, причем и c min-height, и с height. Вот в этой теме когда-то выяснили, что по крайней мере в современных версиях помогает display:table для контейнера. Еще Оперы до 12-й версии ненавидят размеры больше 32767px по модулю (неважно где — в padding, text-indent и т.п.), т.к. когда-то разработчики решили, что 32kpx "хватит каждому"... А по сабжу — первым делом выжечь все !important каленым железом. Видел хороший коммент на Хабре а-ля "!important — как последний патрон: оставьте для себя..."

В IE6 inline-block прекрасно делается комбинацией inline + zoom:1 (или любого другого способа задания hasLayout). А для изначально инлайновых типа <span> вообще работает как есть.

1) Вреда от кавычек нет, а польза бывает (напр., меньше риск побить разметку, а то и получить XSS, при выводе пользовательского текста в value элементов форм). Поэтому лучше брать за правило ставить их везде, где у атрибута есть явное значение. Атрибуты, не требующие указания значения, можно (и даже желательно) писать в сокращенном виде (readonly, required и т.п.), если доктайп это допускает (писать цветистые readonly="readonly" и т.п. нужно только в XHTML). 2) Всё верно, нет больше у таблицы такого атрибута. Центрируйте ее стилями (margin: auto).

Есть сильное подозрение, что CSS тут вообще ни при чем, а настраивать/допиливать нужно именно на сервере

Вот один из ответов: www.uniq-themes.ru/index.php/monetisations/1240-dostoinstva-joomla.html

Сайты на HTML (как и на всём остальном) работают по протоколу HTTP. Юзер нажимает ссылку, браузер посылает на соответствующий URI (адрес) HTTP-запрос, сервер находит соответствующий запросу HTML-файл и отсылает его браузеру в виде HTTP-ответа. Браузер читает этот ответ, парсит (разбирает) его на элементы, строит из этих элементов DOM-дерево и рендерит (рисует) его на экране. Если среди элементов попадаются ссылки на др. ресурсы (<link> на CSS-файл, картинки, фавиконка и т.п.) - для каждого из них браузер тоже отправляет HTTP-запрос, и сервер возвращает нужное в HTTP-ответе. Когда юзер нажимает какую-либо ссылку на странице, весь процесс начинается по новой. Сайт на Джумле (и любом другом движке), кстати, работает точно так же, только HTML-файл не лежит на сервере в готовом виде, а генерится сервером заново для каждого очередного HTTP-запроса. Так одна программа (скрипт) может заменить целую кучу однотипных HTML-файлов. Но на выходе тот же самый HTML.

Странно, я через developer tools выключал - в режиме IE8, вроде, помогает. В режиме IE7, да, надо еще что-то допиливать.

Только, прежде чем совсем убирать, во всех актуальных FF проверьте хорошенько

Теперь да А для чего у .col2 .content стоит жесткая высота 600px? Причем, как я понял, именно для IE8. Просто убрать эту цифру - не выход?

Проверьте закрытие тегов, особенно здесь (строка 615): </div> <div id="bottom-pagination"><span style="float:right"><span></div> И еще, зачем целый див-сепаратор, что мешает просто поставить border диву с товаром? P.S. Старый добрый ДБГ-06Т, отредизайненный в гламурненький красный корпус... как мило!

Разобрался. В этом тесте используется специательный шрифт, в котором вместо буквы "X" - сплошной квадрат Малевича. Интересно, что ситуация "флоат перед обычным блоком во флоате" (наткнулся на забавный пример в комментах здесь) в официальный тест, похоже, до сих пор не включена и, соответственно, не стандартизирована. По моему пониманию спецификации, правы там как раз IE и новые Оперы, но могу заблуждаться...

Как ссылка на отдельную картинку, полагаю . В отдельном CSS-нике в условных комментах.

Не совсем. За 100% высоты принимается див-контейнер таблицы, который служит началом отсчета для абсолютно позиционированных вещей (в данном случае псевдоэлементов) внутри нее. Верх и низ псевдоэлемента прижимаются к верху и низу этого контейнера соотв-но (т.е. он растягивается на всю высоту), а левая граница не задана, поэтому в качестве нее берется граница предка, т.е. ячейки.