Умная адаптация ширины блочных элементов на чистом CSS 2.0

[infinius]

Возможно, я не правильно вас понял, но почему бы не использовать:

.page-constrain {
    width: 75%;
    min-width: 960px;
    max-width: 1600px;
    margin: 0 auto;
}

[Pagefest]

Дополнил пост ответом на ваш вопрос — по соображениям совместимости, IE до сих пор (вплоть по актуальную 9 версию) тупит при одновременно указании width и min-width/max-width.

[infinius]

Хорошо. Не буду настаивать на экспрешенах.
В любом случае, попробуйте SASS+Compass, это позволяет не заботиться о таких вещах.

[fritz321]

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

[Pagefest]

Поподробнее?

[Pagefest]

Всё, нашёл проблему, дополнил пост.

[XHunter]

И получаем пустые полосы по краям на любом разрешении. Какая-то странная реализация.

[Pagefest]

Пропорциональные основному полю пустые полосы регулируемой ширины.

[dom1n1k]

min-width: 960px;
max-width: 75%;

А что будет, если 75% окажутся меньше чем 960px? :)

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

[Pagefest]

Ширина ограничится минимальным габаритом ;-) На самом деле рабочий и проверенный временем приём.

[battrack]

Я для IE вопрос максимальной ширины так решал:
В css вместо max-width прописываем:
width:expression(document.body.clientWidth < 996? «996px»: document.body.clientWidth > 1440? «1440px»: «auto»);

[Pagefest]

Хабр?)

[fritz321]

Ну хабр то вроде бы совсем не резиновый

[Pagefest]

А вы окошко браузера по ширине помасштабируйте — он вполне себе резиново себя ведёт тоже с некоторыми ограничениями минимального и максимального горизонтального габаритов (800 и 1154 px соответственно), разве что без примочки пропорционального изменения боковых полей. ;-)

[fritz321]

Извините, но так и не нашел резиновости.
Уменьшаю размер окна — все уменьшается, а поля увеличиваются, увеличиваю — увеличивается текст, а поля уменьшаются…

[Pagefest]

Тут резиновость есть именно в части изменения ширин основной и внутренних (контентной и боковой) колонок. Стопроцентной полноценной резины на Хабре нет, тут она, как и в большинстве случаев — не нужна.

[dom1n1k]

Ну не совсем.
Резина под абсолютно все разрешения — да, миф. Даже если под «абсолютно всеми» подразумевать, например, только десктопы, без учета мобильников.
Но чтоб тянулось под некий разумный диапазон разрешений (ну скажем, 1024...1440) — это более чем реально, все там нормально будет, если мозги включать. А сверх — можно ширину и ограничить.

Как ни крути, фиксированная колонка 960 это вчерашний день. Мне очень грустно смотреть на такие сайты, имея монитор 1920. Сайты, которые тянутся хотя бы до 1200-1400px уже намного удобнее.

[Pagefest]

Я согласен с dom1n1k про фиксированную колонку в 960 px, это крайне уныло выглядит в разрешениях от 1600 и больше. Для дектопов в очень больших разрешениях (от FullHD и выше) резина опять же теряет смысл свыше некоторого максимального значения ширины колонки.

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

Обновлю пожалуй пост на эту тему.

[dom1n1k]

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

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

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

Вот как раз-таки использование адаптивного дизайна «на скорую руку», без серьезной проработки и тестирования — вот это да, это отли-ичный источник потенциальных глюков. Уж поверьте.
Повторюсь, сама по себе технология отличная, всячески её поддерживаю. Но она требует значительно более высоких затрат и квалификации разработчика.

Насчет «идеальных» примеров — навскидку не знаю. Но просто разумный пример — главная Рамблера. Она тянется между 1024 и 1280.