Контролировать все и вся на web-странице - задача не из простых.

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

А трудности верстки на процентах всех элементов web-страницы, известны, в ряде случаев практически невозможно добиться идеальной визуальной совместимости. Сложности подстерегают на каждом шагу.

К примеру - великое разнообразие форм, приведение их в более или менее божеский вид даже с использованием пикселей вызывает порой не преодолимые трудности.

Вообще, проценты, штука не понятная, физического смысла не имеющая.

Может быть, именно по этому производители браузеров не обращают должного внимания на эту сторону вопроса и от сюда столь вопиющие разночтения по визуалу при попытке сверстать, что либо на них.

Примеры четко показывают, что при переходе с одного разрешения на другое, смотрим в диапазоне от 1024*768 до 1600*900, макет страницы идеально выглядящий при нынешнем дефолте (1024*768), может разочаровать любителя прекрасного на иных разрешениях, легко и просто.

Понятно, что сейчас практически не возможно встретить страницу, где каждая колонка или блок имеют свой индивидуальный цвет, border. Приводя в качестве иллюстрации подобного рода разметку, только показываю все не совершенство крутых и не очень, но кем-то любимых по необъяснимым причинам браузеров.

Но это не единственная боль и печаль.

Переход с пикселей на проценты ставит еще более глобальную проблему.

А именно - графика.

При чем не просто картинка, заключенная в

<img src="/">

Тут задав ширину в процентах худо-бедно, можно получить приемлемый результат, а вот как быть с background:url(XXX.xxx)?

А если вернуться к "Не АК, но автомат…" и посмотреть на проблему в более широком аспекте, придется признать, что на сегодняшний день, средствами html и css, озвученное, не имеет полноценного решения без привлечения JavaScript.

Кто-то скажет, к чему все это? Зачем лишняя головная боль?

Нет у меня ответа.

Но и положение вещей, когда практически никто не задается подобными вопросами и не ищет решений, а кризис в данном случае на лицо, лично меня не устраивает.

Традиционные, устоявшиеся каноны, где все сводится к устранению мелких, частных проблем, рано или поздно, а производители мониторов не остановятся на достигнутом, приведут в тупик и ждет нас возврат к плоским страницам без колонок и прочих атрибутов уже привычных глазу.

Тенденция прослеживается, может и не очень четко, но она есть.

Дмитрий, написав продолжение, привел пример, на мой взгляд, не совсем удачный, колонки, отведенные под навигацию, не имеют плавающей ширины.

В комментариях им же был дан линк, еще на один пример, где не используется библиотека jQuery, но и в нем нет универсальности, размер шрифта при переходе с одного разрешения на другое, простом изменении размеров экрана монитора, меняется только в колонке отведенной под контент. Попытки применить работу скрипта ко всей странице, всем колонкам, успехом не увенчались.

Возможно, кому-то удастся сделать и это.

Проблема обозначена. Поиск не простых решений продолжается…

В математике не силен,
Купил за 5, продал за 10,
Так и живу на 2%...
Проценты бич верстальщика…

Давайте поговорим о возможности автоматического или динамического реагирования web-страницы в зависимости от размера диагонали и разрешения экрана монитора, а также простого уменьшения размеров окна браузера с привязкой пропроционального изменения размера шрифта при тех же условиях.

Тема не избитая, еще многое предстоит решать, плохо то, что ни W3C, ни производители браузеров по настоящему всерьез, этой проблемой не озадачивались.

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

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

Нет концепции.

А вот заблуждений на этот счет не счесть.

Скажем, есть очевидная проблема, если быть точным то две, как минимум, суть их в следующем.

Стандартная трех колоночная разметка.

Что она представляет собой в большинстве случаев?

1 ***

Боковые колонки имеют фиксированную ширину, область контента, почти всегда с небольшим люфтом так, как основной контейнер ограничен по ширине с помощью min/max-width.

Допустим, при нынешнем дефолте - диагональ 17”, разрешение 1024*768, страница занимает все доступное место.

При переходе на иное разрешение, к примеру - 1600*900, если наша страница не ограничена на уровне 1280px, как рекомендуют, из-за плавающей ширины центральной части, разметка превращается в черт знает что.

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

Даже если страница по min/max-width, все-таки будет ограничена на уровне 1280px, пропорции не соблюдаются, как на этом разрешении, так и на разрешениях выше.

Смотрим. Одна и та же разметка - в первом случае макет с фиксированной шириной в 1000px, следующий ограничен по max-width:1280px, третий - max-width:100%.

Выбираем разрешение экрана монитора в диапазоне от 1024*768 до 1600*900.

Думаю, ни у кого не возникнет иллюзий, насчет того, что проблема, озвученная чуть выше, имеет место быть.

Выход в данном случае один - все колонки должны иметь плавающую ширину.

Самый подходящий вариант, все размеры в процентах, но так ли все просто с ними?

Давайте посмотрим.

Основа та же - разметка, из предыдущих примеров.

Более или менее идеальный вариант, вы можете попробовать сами поиграть процентами, получите массу удовольствия в попытках примирения браузеров, приближаясь к полной визуальной совместимости :)

Итак, основа имеется, но это еще не все.

2 ***

С горем по полам мы заставили макет худо-бедно динамически подстраиваться под диагональ и разрешение экрана монитора без участия пользователя.

А вот, как быть с размером шрифта?

Указание оного таким образом - body {font-size:100%;} не решает проблем, а предлагать пользователю для увеличения размера шрифта понажимать какие-то кнопочки, по меньшей мере, глупо.

Хотелось бы следующего.

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

С помощью "Каскадных таблиц стилей", задача, похоже, не имеет решения.

Тут нужно сделать не большое отступление.

Многие гуру от верстки, чтобы они о себе не думали, проповедуют политику двойных стандартов.

Это касается использования JavaScript для разметки каркаса страницы. Причем во всем остальном наличие скриптов их не пугает, и лепят их они, где надо и не надо.

Отчего так затрудняюсь ответить, субъективно, скорее всего, от не желания заниматься проблемами всерьез, это ж, сколько надо времени потратить, лучше поспамиться по блогам, блеснуть знаниями на форумах, тут его хватает, но ни на что другое уже просто не остается.

Обратите внимание на последний пример. При разрешении 1600*900, текст читать затруднительно, в body стоит font-size:100%, к тому же в колонке будет меню, а ему-то практически всегда задают фиксированный размер.

Картинка так себе. Колонка стала шире, размер шрифта меньше, ни о каком соблюдении пропорций речи не идет.

Вот тут-то бы и пригодился JS, который в зависимости от базового размера шрифта и определенной ранее величины размера экрана монитора, мог бы этот самый шрифт динамически подстраивать до более или менее приемлемого в плюс/минус, как при простом изменении размера окна браузера, так и при переходе с одного разрешения на другое.

Частично рассматривал проблему в "Контроль..." и продолжаю обдумывать те или иные аспекты этого взаимодействия, по возможности пытаясь полностью, исключить пользователя из процесса, все в динамике и на автомате.

И вот тут можно сказать, что крупно повезло.

Читаем: "Умные динамические колонки с применением CSS и jQurey".

Да, не обидится на меня Дмитрий, но его статья, вернее вольный перевод, ближе к "гламуру", но удалось увидеть в ней рациональное зерно. В комментариях подал идею, Дима выложил пример на ее основе, и по моей просьбе в личной переписке, довел до ума эту фишку применительно к моим фиксированным блокам на web-странице.

За что еще раз выражаю признательность и благодарность.

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

Програмисты на JS окликнетесь, окажите посильную помощь в решении не тривиальной задачи.

Главное начало положено, теперь дело практической проверки в реальных условиях web’a.

Вообше, идеальным решением было бы то, если бы данная фишка была бы изначально встроена в движок браузера, но когда еще "расчухают" необходимость этого производители браузеров не известно, а жаль…

И не забыли бы они о процентах, свели бы к единому знаменателю, плеваться хочется, во все стороны, без остановки :(

Не знаю, приживется ли идея или это мертворожденный ребенок, но пока я от этого в прекрасном расположении духа :)

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

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

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

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

Хочется выразить признательность Вадиму Ласто, благодаря которому и появилась вариация на тему.

Одной из главных проблем в предлагаемом мной методе разметки каркаса web-страницы с фиксированными элементами, является вполне закономерное желание простыми средствами получить возможность центрирования макета относительно вертикальных границ окна браузера при различных размерах диагонали и разрешениях экрана монитора с помощью привычной всем связки - margin:0 auto; и min/max-width с эмуляцией оного для IE6, без изменения остальных размеров.

Рассмотрим базовую разметку:

<body>
  <div class="wrap">
    <div class="header">Header</div>
    <div class="middle">Middle</div>
    <div class="footer">Footer</div>
  </div>
  <div class="fixed">Fixed</div>
</body>

Чтобы зафиксировать колонку, запретив ее прокручивание по вертикали, выполняем стандартную процедуру, прописав в стилях:

html {overflow-y:hidden;}
html,body,.wrap {height:100%;}
body,.wrap {position:relative;}
.wrap {overflow-y:auto;}
.fixed {
  position:absolute;top:XXpx;
  right:XXpx;bottom:XXpx;width:XXpx;
}

Теперь вертикальный скролл принадлежит контейнеру с классом wrap, и вот тут-то начинаются разночтения, блоки header, middle, footer позиционируются относительно границ .wrap, а блок .fixed относительно границ body.

Если задать margin:0 auto; и min/max-width для .wrap наша фиксированная колонка при уменьшении размеров окна браузера будет наезжать или прятаться под него, здесь рулит z-index.

Этого можно избежать передав стили: margin:0 auto; и min/max-width - body, но вертикальная прокрутка принадлежащая контейнеру wrap будет оторвана от правой границы окна браузера, что по визуалу смотрится совершенно не к месту и нарушает целостную картинку.

Идея Мастера Lasto заключается в следующем - надо тем или иным способом попытаться скрыть вертикальный скролл. И ему удалось, мягко, но настойчиво побороть мои сомнения, относительно того, что для пользователя подобного рода изыск, может показаться ущербным и ввести его в ступор :)

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

Но стоит ли этого бояться?

Нечто подобное предлагалось пару лет назад - оригинал, перевод, но, посмотрев пример к статье и увидев дополнительные прокрутки, что абсолютно не украшают, кто бы, что не говорил, и не под каким "соусом" делать этого я бы не стал, а также отсутствие возможности простыми средствами прикрутить min/max-width, в голову, так или иначе, придет мысль, что прием, озвученный в данной публикации - путь в никуда.

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

Поиздеваться над стилями и html - ох, как люблю :)

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

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

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

Вернемся к вертикальному скроллу.

Так, как мы используем абсолютное позиционирование, проблем нет никаких.

Собственно в базовой разметке это решается сдвигом фиксированного блока в право, что приводит к накрыванию прокрутки.

Но лучше и проще всего, завести еще одну фиксированную колонку соответствующего размера по высоте и ширине, с фоновой заливкой цвета body, позиционируя ее на вертикальную прокрутку и задав необходимый отступ слева контейнеру с классом wrap на туже ширину, что имеет дополнительная фиксированная колонка, получая строго отцентрированный каркас страницы при любых размерах диагонали и разрешениях экрана монитора.

Пример.

Это наиболее универсальное решение и оно пригодится для иных макетов, производных от базовой разметки, не все, но возможные варианты.

Тогда наш html-код примет следующий вид:

<body>
  <div class="wrap">
    <div class="header">Header</div>
    <div class="middle">Middle</div>
    <div class="footer">Footer</div>
  </div>
  <div class="fixed">Fixed</div>
  <div class="fixed_scroll"></div>
</body>

При отсутствии вертикальной прокрутки, страница вглядит несколько не обычно, нет опознавательных знаков для пользователя, чтобы хотя бы приблизительно определиться на каком участке оной он находится, но меню расположенное в фиксированной колонке, которое всегда доступно, с лихвой окупает это маленькое досадное недоразумение :)

Проверено и работоспособно в IE6(7,8), FireFox 3.08, Google Chrome, SafariWin.

OPERA, у меня стоит версия 9.64, в мадших версиях разметка не проверялась, вскоре по праву займет достойное место "дедушки" (IE6), которому давно пора на пенсию, хотя с возложенной на него задачей, даже не понимая одновременно top:XX; и bottom:XX; справился отменно, получив "черную" метку и будет первым браузером, занесенным мной в разряд изгоев, за свою тупость :(