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

В Gecko есть -moz-column-count и -moz-column-gap из будущего CSS3 (и еще что-то оттуда же, но я решил для начала разобраться с этим). Я попробовал заставить IE действовать аналогично им. В процессе экспериментов IE многократно падал и ругался неопознанными ошибками, пришлось прибегнуть к "черной магии" и бубну... вот предварительный результат. Прошу сравнить с поведением "нативных" колонок в FF, и высказать свое мнение:

• нужно ли это кому-либо вообще;
• насколько криво это реализовано в примере, и
• можно ли это реализовать не криво и - предел мечтаний - кроссбраузерно.

За конструктивные предложения по последнему пункту буду благодарен вдвойне!

Да ну-у-у! Что же теперь - всю жизнь краснеть за экспериментальные недоделки?


Сделал следующее. Просто взял то же изображение  и вставил его перед заголовком первого уровня. Все - при определенном размере окна размер второй из колонок становится больше остальных ровно на высоту изображения (т.е. изображение "болтается" внизу).
"Черная магия и бубен" пока не очень надежны - при увеличении шрифта и изменении размера окна мой IE "завис".
Хотя и в FF можно видеть такую неприятность, как, например, "торчащая" строка в последней колонке. Ведь на газетной полосе строка будет "торчать" ниже основного уровня скорее в первой, нежели в последней колонке...

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

AKS, если не трудно, оцените второй вариант. Изменения по сравнению с первым:

• однопроходный алгоритм разбивки заменен многопроходным (максимальное кол-во проходов ограничивается в коде, я ограничил тремя), при обнаружении сильно выделяющегося по высоте элемента (как та картинка) предпринимается попытка переразбить колонки заново, сделав их повыше;
• оптимизирован алгоритм поиска места разбиения (вместо тупого перебора по словам - деление отрезка пополам);
• обработчик onresize переписан по-человечески (надеюсь;) через attach/detachEvent;
• увеличен таймаут при ресайзе (имхо, это должно повысить надежность против зависаний);
• добавлены комментарии 

Повесить IE6 новым вариантом (с 2-4 колонками) мне не удалось, IE7 - тоже, но в последнем обнаружилась странная неприятность - видимые "прыжки" колонок в процессе (пере-)разбивки. Почему-то со старым неоптимизированным алгоритмом такого не наблюдалось... не понимаю, где я накосячил...

Кстати, при каких настройках и параметрах (скрипта, системы) завис Ваш IE с первым вариантом?

Upd. Все-таки смог повесить IE6 :(. В ситуации, когда из-за "увеличения запаса" высоты колонок для картинки последняя колонка оказывается пустой (возможно при числе колонок от 5 и выше). Придется добавлять защиту от этой ситуации...


cruelangel,
1. В целом согласен, но бывают редкие исключения: очень длинные строки на широкоформатном экране читать тоже неудобно. Две-три колонки тут, имхо, вполне приемлемый компромисс. Главное, чтобы не возникало прокрутки - но как раз это условие, имхо, вполне можно обеспечить как раз с помощью presentational javascript'а.
2. Тоже согласен, но это следующий этап усовершенствования (притом пустячный, на две-три строчки кода). А пока я пытаюсь лишь воспроизвести поведение стандартных средств CSS3 .

Это сообщение отредактировал(а) SelenIT - 29.9.2007, 18:21

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

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

Добавил защиту. Вот исправленный второй вариант. Интересно, при каких условиях он завесит браузер?

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

cruelangel, 

Речь, пардон, не о дерьме, а об информации. Туалетную бумагу, в отличие от веба, я не читаю (хотя на правах тех. курьеза и существуют вот такие решения;). А эргономика восприятия информации - вещь неоднозначная и субъективная. Многих избыток пустого места просто раздражает (эдакая информационная "агорафобия")...

Это сообщение отредактировал(а) SelenIT - 30.9.2007, 01:43

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

с чем боролись (прыганье глазами вправо-влево с большой амплитудой) на то и напоролись (прыганье глазами вверх-вниз с большой амплитудой)

Это сообщение отредактировал(а) cruelangel - 29.9.2007, 20:07

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

ага, а ещё раз в пять минут показывать страшную кричащую рожу... разница-то ощутима...

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

Но если есть желание конструктивно покритиковать мою последнюю реализацию - буду благодарен .

Это сообщение отредактировал(а) SelenIT - 29.9.2007, 21:20

лучше так: отображаем всё в одну колонку, смотрим, какая высота получилась, делим её на количество колонок, смотрим у параграфов offsetTop и перевалившие за отметку - переносим на следующую колонку. или дизигнерам ещё и параграфы нужно резать посередине?

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


Имхо, именно так. Самая первая мысль была отталкиваться от блочных элементов, но из-за этого очень уж безобразная рваная нижняя граница получается, если на зону переноса попадает блок строчек на 8-10...

SelenIT, сейчас сохранил страничку и поэкспериментировал. 
Обрадовать нечем. С ходу "повесил" IE следующим образом. 
1. Установил размер шрифта "Самый крупный".
2. Установил размер страницы body.offsetWidth = 852||documentElement = 892 (это я быстренько вычислил "уязвимую" ширину).
3. Нажал на кнопку "разбить".
В таких условиях мой IE "виснет" сразу и без исключений.
Попробовал то же самое в  Avant Browser. Он, в отличие от IE, сразу не зависает. Но это легко происходит, если свернуть окно наполовину. То же самое и в AOL Explorer'е.
Сначала подумал, что может быть надо увеличить время таймаута. Но это не помогло.
Закомментировал вот эти строки:

 - тут уж, конечно же, "зависания" прекратились...

AKS, огромное спасибо! Обнаружение и локализация бага - уже радость. Фиксю, обновляю пример и ставлю плюс!

И все-таки, как ни стараюсь, не могу обойтись совсем без точной подгонки. Страшно туплю, но в упор не понимаю: почему такой 
и такой 
дают разный результат - во втором случае выделение упорно обрывается на одно слово раньше, чем надо? Почему второй вариант бинарного поиска не останавливается в нужном месте? Чувствую, что где-то я попросту влепил абсолютно детскую, тупейшую и позорную ошибку в логике... И вообще, как надежнее всего проконтролировать, что мое textRange не "вывернулось наизнанку" (начало не перескочило конец) и не покинуло границ размечаемой колонки?

А Вы не пробовали создать дубликат текстового диапазона, и манипулировать им?
Я об этом подумал, прочитав "начало не перескочило конец". Имея два диапазона, Вы как-раз могли бы сравнивать эти "начало/конец" при помощи метода compareEndPoints. Метод имеет "шикарный" набор параметров - наверняка с его помощью можно получить более широкий контроль за фрагментами текста...