SelenIT

Зачем дивы col1 и т.п. закрываются сразу после картинки? Разве текст не должен быть в той же колонке? Почему между второй и третьей колонками два закрывающих дива, а между первой и второй - один? Разве колонки не однотипны?

Имхо, реально всё. Вопрос в условиях и границах применимости решения (какие браузеры нужно поддерживать, нужна ли работа без JS и т.п.). А также в затратах времени и сил на него. На самый крайний-прекрайний случай — есть флеш (у >85% юзеров, если не ошибаюсь).

Меня последнее время занимает идея полной замены "нецелевых" флоатов на display:inline-block (с сохранением всех плюсов, избавлением от почти всех минусов и бонусами типа вертикального выравнивания и центрирования всей этой радости). До сих пор "полет мечты" сдерживало присутствие FF2- (который уже практически ушел за 5%-ю границу) но совсем недавно я узнал, что можно укротить и его (через проприетарные значения display типа -moz-inline-stack и дополнительную внутреннюю блочную обертку). Подозреваю, что последнюю можно заменить небольшим количеством XBL-магии (по аналогии с HTC-костылями для IE6), но опыта возни с ними у меня совсем мало. Но идея интересная, если будет досуг на ближайших выходных — непременно экспериментирую!

bottom:0; top:expression( eval(document.body.clientHeight + document.body.scrollTop - this.offsetHeight) + 'px' ); Привязка к позиции скроллинга в expression идет по верхнему краю, а не по нижнему, так что придется по-прежнему привязывать именно top, смещая его от верхней границы на разность высоты области просмотра и высоты самого элемента. И еще, корневым элементом может быть либо document.documentElement (в стандартном режиме, с правильным доктайпом), либо document.body (в Quirks mode, без доктайпа или с кривым доктайпом), но только один из них. У него и нужно снимать все размеры. В данном случае, судя по всему, используется Quirks mode, поэтому надо везде брать document.body.

Игорь Ермаков, хорошим тоном считается, когда базовая функциональность доступна и без JS — через обычные ссылки и формы с перезагрузкой страницы целиком — но при включенном JS все то же самое делается плавнее, красивее и с меньшим расходом трафика (благодаря асинхронной загрузке контента по частям). Это называется "ненавязчивым" (unobtrusive) JS. Библиотека JQuery располагает хорошими инструментами для осуществления этого (напр., кроссбраузерным событием onDomLoaded), но она по определению не может быть быстрее решения на чистом JS, написанного под конкретную задачу. А сравнивать скорость PHP и JS — все равно, что сравнивать скорость самолета и такси, идущего из аэропорта к вашему подъезду. Да, скорости разные, но маршруты и возможности — тоже...

yopopt, а зачем гадать? С точки зрения протокола HTTP (о котором вопрос), это все равно не более чем адрес. Потому что в HTTP нет ни файлов, ни папок, ни микросхем, а есть только адреса, запросы браузера к ним и соответствующие ответы сервера...

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

Это если локальный файл с диска тестировать. Если загружать по HTTP, как положено - никто ругаться не будет.

stosen, как вы представляете себе поведение браузера при нажатии на чекбокс, являющийся одновременно частью ссылки??

Как вариант - задать line-height меньше единицы и background:transparent. Но в IE все равно может быть коряво...

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

Дело не только в визуальном отображении. Парсер разметки не смотрит на CSS, стили применяются уже к отпарсенному DOM-дереву. Если парсер видит открывающий <p> после другого открытого <p>, ему незачем проверять, "а не сделан ли случаем этот второй <p> инлайновым" - его парсерово дело в этом случае тупо закрыть предыдущий абзац, как предписывает спецификация HTML, запрещающая вложенные абзацы. Кроме того, у реальных браузеров (особенно старых) различается и программная модель для разных элементов. Например, в IE в Quirks mode таблицы - несколько "вещь в себе": у них по умолчанию есть layout (в отличие от др. элементов), они не наследуют стили предка, они "экранируют" ссылки и т.п. Не говоря уже об элементах форм (впрочем, их не может быть внутри ссылки по другой очевидной причине). Чисто визуально же - чем отличается <span style="display:block"> внутри такой же "псевдоблочной" ссылки от дива в ней? Кроме того, что не сбивает с толку ни парсер, ни валидатор...

Мда уж, страсти по валидатору разгорелись нешуточные . Но насчет блочных элементов в <a>, по моему мнению, это не блажь валидатора/W3C, а очень полезный совет по избеганию граблей - от мелких визуальных типа таких до полностью нерабочей ссылки (вполне может получиться в том же IE, непример, при вложении таблицы в ссылку). Фокус в том, что в не предусмотренных спецификацией случаях браузеры строят DOM как им удобнее (как бы "исправляют битую разметку"), и никто не вправе их за это упрекнуть... А делать элемент ведущей в никуда ссылкой лишь ради "гламурного" поведения в вымирающем семилетнем браузере - имхо, идея не самая лучшая и без оглядки на валидатор. Вот насчет кастомных атрибутов для элементов форм - не спорю, удобно. Кстати, многое из подобного (упомянутый required, широко поддерживаемый браузерами autocomplete и т.п.) проходит валидацию как HTML5.

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

Может, лучше наоборот, www отбрасывать?

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

position: fixed. Для IE6 - эмуляция (есть как минимум 2 способа).

Тогда, имхо, только картинки. Две полоски 660×15px - для верхней пары закруглений и для нижней, абсолютно спозиционировать в .rightcolumn c top:0 и bottom:0 соответственно, а сплошную заливку (нынешний .transparency) растянуть уже между ними (top:15px; bottom:15px; _height: expression(this.parentNode.clientHeight -30 + 'px'). И им всем задать одинаковую прозрачность. Это если делать честную прозрачность. Но во многих случаях достаточно ее имитации - тогда все намного проще. Это случайно не для того сайта, что в подписи?

В IE, наверное, не этот костыль не сработал, а т.к. первые два по определению для Gecko- (Firefox, Seamonkey, Flock...) и WebKit-браузеров (Safari, Chrome) соответственно, а последний - черновик CSS3, не поддерживаемый пока нигде. Для IE можно нарисовать похожие закругления, используя VML, а для Оперы (9.5 и выше) - соответственно, SVG (пример).

Ширина таких блоков фиксирована?

Имхо, не так уж это и страшно в эпоху повсеместного gzip-сжатия при передаче...

Это был не текст, а неопределенная константа. Вот ради того, чтоб не попадаться на таких досадных мелочах, и нужно обязательно выводить (не обязательно на экран, хоть куда-нибудь) все ошибки, включая Notice (т.е. error_reporting(E_ALL) без каких-либо исключений!).

Mila, самый простой вариант (если бы не IE6) - использовать в качестве фона полупрозрачную PNG-картинку (для IE6 можно взять другую, непрозрачную - судя по закругленным уголкам из CSS3, вас устраивает graceful degradation для отсталых браузеров. Но можно попробовать "довести до ума" и ваш вариант - заменить в нем height:2500px; для .transparency на bottom: 0px; /* в сочетании с top:0px растянет блок на высоту родителя, но не работает в IE6 */ _height: expression(this.parentNode.clientHeight + 'px'); /* "костыль" для IE6 - и здесь без него никак... */

Это библиотека на JS, которая позволяет вместо громоздких document.getElementById('target') писать коротко $('target'), сглаживает многие различия между браузерами и делает еще много приятных мелочей, упрощающих разработку. Правда, за удобство приходится платить необходимостью подключать к своим скриптам неслабый файлик килобайт на сотню Сейчас подобных библиотек много, это как бы модно и действительно удобно. Но если юзать их бездумно, можно получить тормоза и др. проблемы...

Подойдет?