Nanto

tini.kRyptoNite Блочные элементы запихивать в строчный? строчный элемент будет первый в теле документа?извиняюсь - под "сайт" оказывается имелось в виду слово... все равно line-height надо указывать! SLameN .head{line-height:56px;}

Х.З. IE DebugBar под рукой нет, может он переносит блок вниз, потому что они оба не влезают по ширине в родителя? (попробуйте строки до 250px уменьшить) шестому (да и седьмому) просто display:inline поставьте

Ну то есть можно сказать - не понимает! Суть-то использования !important как раз и состоит в переопределении специфичности селектора (в смысле правила), разве не так? мне в том примере не понятно другое: 1) html, body{ height:100%} - это понятно - растягиваем документ на всю СТРАНИЦУ (если не задавать html? а только body - то вроде растягивается только на высоту ОКНА - не помню точно, может и не во всех браузерах так) 2) position:relative для body - не понятно! блок (с position:absolute) внутри body и так будет позиционирован относительно body по умолчанию. Или это какой-то финт всё-таки? 3) для 6-го осла ставим height:auto. Вопрос - а зачем надо выделять шестого осла? зачем вообще нужен этот "height:auto"? почему не так: height:100%; (это фактически min-height для IE6) min-height:100%; (а это для всех остальных) Вернее даже так - height:100%; Зачем ещё min-height указывать? Вроде здесь когда-то нашёл: http://xhtml.ru/2005/10/18/footer-stick/ А тут оказывается целая диссертация по этой проблеме расписана - попробую въехать: http://xhtml.ru/2005/12/12/body_height_research/

Ну хорошо? а вот тут можете мне объяснить (имеется в виду правила для body) - что как работает, и почему именно в таком порядке? (это типа "кроссбраузерный блок на всю высоту страницы") html{ height:100%; } body{ position:relative; height:auto !important; height:100%; min-height:100%; } #div{ position:absolute; width:100%; height:100%; }

Выделил "некузявый" момент. Вот это "width:30%" всегда неопрятно выглядит, особенно на больших разрешениях - пустое место после последнего блока кривовато смотрится. Почему бы не делать "float:left", "float:right", ну и там "text-align:center" или "margin:0 auto" - блока-то всего 3!

Ну как же - если указано "width:auto", то min-width и max-width будут служить границами возможных значений для "auto", не?

а в каких случаях "width:auto" имеет смысл, если у блока уже проставлены min-width и max-width? не очень понимаю такой вид конструкций... а) Это хак для некоторых браузеров б) Чтобы ширина блока всегда растягивалась до максимума (но ведь по дефолту так и должно быть) в) Не имеет смысла

Как обсчитывается?

Вот: http://jsfiddle.net/4xDxK/6/ Много обёрток, но полностью соответствует требованиям автора! Заодно к вопросу - "зачем нужен костыль в виде min-height:100%" - вот за этим самым!

Опера - оперой... Но тут уже только IE8

position:relative зачем там? Блоки перекрывают находящийся в них контент.

а JS - это не костыль? Это протез натуральный!

Dell UltraSharp U2410 - без вариантов! Никто с этим запариваться не будет (особенно в случае недорогих моделей) - это раз. Во-вторых - калибровка имеет свойство "уползать", поэтому процедуру надо проводить раз в 2-3 месяца. В-третьих на корректное отображение цветов влияет кучу всяких параметров, вплоть до ориентации монитора по сторонам света (магнитное поле Земли вносит искажения) - не помню, но есть даже рекомендация - как ориентировать монитор Учесть всё это на заводе в принципе невозможно! Охват тут не причём. sRGB также (а если у нас монитор AdobeRGB кроет?). Задача калибровки - привести отображение цветов монитора в соответствие аппаратно-независимому цветовому пространству (Lab) - а затем уже автоматически (на программном уровне) происходит переход в RGB (профиль монитора никогда не равен ни sRGB, никаком другому цветовому пространству - это теоретические эталоны). Ну или грубо говоря, цель калибровки - устранить девиации цвета (расхождения в отображении фактического и эталонного цветов).

Я бы даже париться не стал! Таблицей бы сходу жахнул... Но если Вам принципиально именно блоками. То задачу надо разделять: а) делаем кроссбраузерный каркас с колонками на всю высоту и прибитым футером; б) вставляем слайдер - он все равно на JS, а посему влепить его можно будет как угодно - и overflow тут не нужен; что мешает например переключать display:none/display:block? Это я к тому, что в Вашем коде невероятно трудно разобраться - перемешанные height и min-height, колонки с их margin-padding-overflow, псевдоэлементы и т.д. и всё в кучу!.. Начните с каркаса и попроще-попроще...

Да уж... Посмотрев Ваш код немного в шоке... Зачем такого намутили? Чего хотели? "Футер к низу, колонки на всю высоту и overflow:auto"?

Только что сам с этим столкнулся - хотел уже тему заводить, но нашёл глюк сам!.. У Вас та же фигня! Опера начинает тупить при динамическом изменении высоты (без перезагрузки страницы) - у меня, например тупо тормозила - могла с задержкой ресайзнуть блок, а могла и оставить как был. У Вас оставляет без изменений. И вот гнусные разрабы вместо нормальной работы со структурными свойствами гонятся за "плюшками" CSS3! Короче, поковырявшись, нашёл затык, которой заставляет тупить Оперу - ей нельзя скармливать "min-height:100%" в некоторых случаях. Долго раскапывать в каких, но в Вашем в случае - замените в #content "height: auto !important;" на "height:100%", а "min-height" - удалите!

Этой "тупостью" на большинстве страниц в вебе футер "к низу прижимают"... Учите мат.часть!

А вот теперь я выскажусь в духе моих же оппонентов!.. А про маркетинг забыли? Что такое jQuery - это штука на которой сидит весь инет! И часто в требованиях к соискателю пишут уже не "знание JS", а "знание jQuery"... А популярность это деньги, поддержка, развитие... А холивары "что круче PHP или Ruby, C++ или С#" это чистой воды флуд! Никто из нас не Резиг и не Гейтс; и обхаять можно что угодно - "у Порше Карера проходимость хреновая - клиренс маловат"... Либо развиваемся и анализируем тенедции (у кого на это мозгов хватает - а это не просто алгоритмизация и знание синтаксиса, тут действительно интеллект нужен), либо "изобретаем велосипед" и плачем о том как "шарварный Майкрософт гонит всякуюнерациональную дрянь"... БУДЬ ПЕРВЫМ, и может ты станешь великим... Не стоит ходить по пятам в попытках улучшить старую схему - таких слишком много...

Адоба это ещё не центр мира... А ну как Гугл скажет - "Отказались? Замечательно! Теперь мы будем поддерживать - у нас как раз имеется новенький флэш-плеер..." И, имхо, всё таки мне кажется тенденции дуют не в сторону html5... Пользователю нужна уже полная мультимедийная поддержка (это минимум, а то и сервисы недоступные на локальных машинах...) HTML5 как ни крути это обеспечить не может! Тут уже и JS с Флэшем не справляются!.. Но начинание красивое и благородное - я как верстальщик обоими руками ЗА! К тому же, насколько я понял - в Адобе сидит очень неглупый менеджмент! Это я на примере граффических редакторов - они совершили ряд, на первый взгляд, очень нелогичных решений, которые умные (и уважаемые мной) люди назвали единственно верными и оправданными (например отход от CIECAM02)... Так что, кто знает, кто знает...

Ребят ну сказал же уже - сделал картинкой! Нафиг всякую ересь писать типа "background:#fff;"? тему вообще никто не читает? Если интересно заморочиться - вот вводные: body{ background:transparent url(/background.jpg) no-repeat 50% 0; } background.jpg - это картинка 1280x700 (не на белом фоне! - грубо говоря фотография)... как в определённом месте бэкграунда (а оно смещается при 1024<x<1280, и при этом бэкграунд центруется /background-position:50% 0;/) сделать разрыв бордера...

Так Вы до первопричин бед хотите докопаться? Это к Тиму Бернерсу-Ли! Вначале сменами стандартов всех запутали, а когда в нете получилась натуральная каша мала, стали "обратно совместимо" пытаться исправлять, да только всем уже по барабану - интернет теперь не для образования и игрушек, в нём теперь деньги все зарабатывают! А время - деньги, так что большинство скажет - идите вы со своими системами в ... у нас каждая копейка на счету, не до систем нам! Ответ: Вы просто слабо представляете ОБЪЁМ работы необходимый для перехода на общую систему! Проще все с нуля сделать (мне самому в разы приятнее делать что-то с нуля, а не перелопачивать чужую вёрстку во время очередного ребрендинга). Но время-время!..

Какие проблемы менеджмента? Вы о чём? Я о совместимости проектов... Делаем вёрстку в стиле БЭМ, всё как надо - отдаём партнёру сквозной шаблон... Оп-па всё развалилось... Потому что там вёрстку делал неизвестно кто и как, и чхать он хотел на специфичность селекторов и семантику классов! И лучший помощник в таких ситуациях не БЭМ, а Файербаг - когда надо вручную отслеживать все косяки, править их, каждое записывать через !important (потому как, не дай бог, снова косяки вылезут) и отсылать партнёру с просьбой добавить в конец своего стилевого файла! Конкретный пример - сделал шаблон всплывашки, всё как надо, перепроверил... У пяти партнёров разваливается!.. Полез смотреть в чём дело. А просто у четырёх партнёров в своих цсс-ках были проставлены z-indexы до миллиона (ребята, так сказать с ЗАПАСОМ делали). Выход? Вручную в своём шаблоне перепрописывашь z-indexы до 1000100... А Вы про менеджемент... Опять двадцать пять! Говорю же - нет опыта у минусовщиков... Каких партнёров знакомить? Например на том проекте, с которым работаю сейчас, где-то около 20 партнёров (а некоторые ещё и нерусскоязычные), которым мы отдаём сквозной шаблон с футером, хэдером и прочей требухой... И шаблон один для всех! И косяки постоянно всплывает (поскольку часто стили конфликтуют)... И мне что, с каждым связываться - давайте выработаем общую систему? Да нах это надо всем?.. Отдал шаблон, тестеры косяки заметили, файербагом отсмотрел, исправил и забыли! Или он по-Вашему должен свою верстку в соответствии с "системой" перелопатить?

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

Не господа - теоретизировать, конечно, хорошо! Но только тут тоже не лохи сидят... Могу рассказать о реальной практике работы с крупными проектами, и как там всё строится через ж...! А в теории всё конечно красиво выходит, угу... Спецификации CSS и HTML тоже по началу строгими и стройными казались, а во что вылилось? Что забавно - минисуют люди, которые не вполне себе представляют функционирование крупного проекта! Ну-ну... Ещё понравились слова про "железобетонную вёрстку" - в крупном проекте такой не бывает в принципе!