s0rr0w

Переводы строки являются пробелами. Решить можно путем превращения этих элементов в плавающие (float) блоки. Только не забыть контейнеру overflow: hidden поставить. Подробности ищите на этом форуме.

Откуда такие гениальные выводы?

Никогда не слушайте советчиков. Думайте своей головой. Приведенный код является списком.

Стоп стоп стоп, при чем тут агрегатор? Элементы в DOM-дереве имеют строгую очередность вне зависимости от того, список это, или набор абзацев. Результат работы некой сторонней программы нас мало интересует. Колспаны - визуальное форматирование. Данных приходит либо больше, либо меньше. Значит, его надо делать <OL> или <UL> Ведь тут советуют все делать все списковые данные списками! Тут согласен. Если удалить контекстное предложение, то смысл перечисления теряется. Что вам скажет следующее перечисление <ul> <li><a href="www.news.com">Новости</a></li> <li><a href="www.politics.com">Политика</a></li> <li><a href="www.catalogue.com">Каталог компаний</a></li> </ul>

Набор LI - это поток. Как идут, так и прочитаются... Почему не достаточно? Принять, что TR = LI->UL, и вуаля... Таблица состоит из списков элементов. Трехмерный список. <ul> <!-- table--> <li> <!-- tbody --> <ul> <li> <!-- tr --> <ul> <li>Cell</li> <!-- td --> </ul> </li> </ul> </li> </ul> Как не являются? childNodes является списком нод, с их позицией, отношениями и прочим. Чистейший список! Подразумеваться может только в том случае, если там написано "магазин". Если написать "склад" или "ломбард", то вся прозрачность теряется.

CSS "zoom: 1" Вот мой поисковый запрос. P.S. На этом форуме данная тема обсуждалась миллион раз. Форма поиска находится в правом верхнем углу.

Спека HTML 4.01 DIR and MENU are deprecated. Добавили в HTML 5 раздел навигации nav. Структура в этом блоке может быть любой, в том числе и любимые многими списки. О да, это мне про многое сказало! Про что речь? Это бессмысленный набор слов без указания контекста. Нет оглавляющего предложения - нет контекста. Почему плохо? Это гибкость языка. Мое мнение - списки применимы только для контента. Для неконтента (оформление, общая структура страницы, меню и прочее) - лучше использовать универсальные теги с указанием классов. Другими словами - HTML-мышление для контента, XML-мышление для оформления. Если впадать в маразм, и по любому поводу лепить UL, OL, то это не делает документ прозрачнее и чище, а только отвлекает.

А самому поискать мозгов не хватает?

zoom: 1 поможет

Набор абзацев - однородны и равнозначны. Жесткого порядка у них нет. Поэтому абзацы с текстом тоже лучше делать в списках. По вашей же логике. И по смыслу будет подходить, ведь что есть статья? Набор абзацев! Мало того, футер, хедер, контен страницы - тоже подпадают под вашу сверх-логичную логику. Ведь это тоже жесткая структура, которая имеет порядок, однородна и равнозначна. Структура самого HTML уже является структурой. Добавляя дополнительную структуру для подчеркивания структуры, вы создаете масло масляное. Это называется одним словом - маразм. Люди очень часто любят в него впадать. Придумайте самодостаточный список в русском языке, который бы не требовал заголовка. Для меню раньше сделали специальный тег. Непонятно, почему от него отказались. Другой вопрос, является ли набор TD списком? Являются ли все чайлды ноды списком?

Вот это вы гоните... Ваш психоз со списками скоро достигнет максимума. Это банальный набор ссылок, а не перечисление. Набор. Ссылок. Если бы перед этим набором стоял бы текст, например "Ниже перечислены марки автомобилей, которые представлены на нашем сайте:" то в данном случае было бы семантично делать список, но с одной оговоркой - не надо убирать буллеты и флоатить элементы. Список должен быть списком, с точечками спереди и в вертикальном виде. Да, кстати, подыгрывая вашему психозу, все перечисления в предложениях нужно делать (по вашей мега-логике) списками! И вот это предложение "На сайте были онлайн: Саша, Маша, Даша" "правильно" нужно делать вот так <p>На сайте были онлайн:</p> <ul> <li>Саша,</li> <li>Маша,</li> <li>Даша</li> </ul>

Типа великий Гуру?

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

А для чего данная задача?

Лентяй!

Ну и отлично, мне от этого только лучше.

Итак, есть два конкурента. Вышли на рынок одновременно. Для работы клиентов решено сделать по некой системе. Первый конкурент заказал систему без требований к ИЕ6 и получил продукт через пол года. Второй получил через 7 месяцев. Кто выиграет конкурентную борьбу? Первый будет иметь 85% рынка, второй - 15. Разделение будет по таргет группе - по пользователям с ИЕ6. Мало того, конкурент номер два будет в роли догоняющего, потому что его супер-лояльный к браузерам продукт выйдет на рынок вторым. Вторую версию продукта первый конкурент выпустит через пол года, а второй будет до своей смерти править баги в первой версии в ИЕ6, которые будут лезть как тараканы из всех щелей.

Переходят на новые версии аж бегом. Потом еще спасибо говорят

Вы хоть раз делали интерфейы на IE6? Динамические интерфейсы, с кучей динамики, подгружаемыми данными, коллапсируемыми блоками? Я поставлю условие, что за разработку под ИЕ6 они заплатять на 40% больше, чем за разработку под ИЕ7. Если это будет только FF, то они получат скидку в 10%. Что выберет заказчик? Что лично вы бы выбрали?

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

Я уже застал смерть одного браузера. Это был NN. Я был как раз в лагере сторонников NN, что надо поддерживать отсталый браузер, ведь есть еще люди, которые им пользуются! Что я увидел в итоге? В заказах еще год или больше фигурировали строчки, что требуется поддержка NN. Как только избавились от лишней обузы в виде NN, сайты начали все больше и больше набирать динамики, становиться все более удобными, быть более легковесными. Общая скорость разработок возрасла. От этого выиграли все те, кто обновил свой браузер. И они за собой потащили весь остальной веб. Сейчас мы видим аналогичную смерть старикашки. И я теперь уже на другой стороне баррикад. Можно смело сказать, что умерла 9я версия Оперы, 3.0 FF, первые пару релизов Хрома, три версии сафари. Только вот почему-то IE6 никто не собирается хоронить. Откуда такая любовь к геморрою?

Абсурд для тех, что не видит экономической подоплеки во всем. Поддержка IE6 экономически невыгодна рынку. Разработчик будет тратить больше времени на отладку багов и приведение своего кода к адекватному виду. Соответственно продукт будет выпущен позже. Соответственно потребители получат продукт позже, и позже его начнут использовать, а некоторые не выдержат и перейдут на продукты конкурентов. А если потребители продукта перейдут на него позже, то они потеряют часть денег. Итог: потребители хотят получать продукт уже сейчас, им не интересно его получать позже. Разработчики хотят продавать продукт сейчас, а не позже, так как время=деньги. Сентиментам нет места в бизнесе. Все, что изжило себя, должно умереть. Чем раньше - тем лучше.

Я думаю, что я бы не стал делать работу для таких заказчиков. Если они отстали от жизни, то это пусть будет их проблемы, а не мои. Почему не повод? Очень даже повод. Давайте все обращаться друг к другу на Вы, по имени отчеству, чтобы как в старые времена все было. Правила вежливого обращения не стоит игнорировать! Еще давайте будем пользоваться телеграфом, телеграммами, почтовыми открытками, бумажными письмами! Может не стоит тянуть не самое лучшее за собой в будущее? А может это своременные люди, которые отказываются поддерживать атавизмы? За верстку под IE6 платит отдельно. Вернее никогда не платит. Проще поступиться принципам, чем больше денег непонятно за что платить.

Да, для людей. И что? Если пользователь не в состоянии обновить свой браузер до адекватной версии, то это его проблема. Сама MS уже не поддерживает это барахло. Это значит, что люди сами себе злобные буратины, если пользуются хламом, и требуют от других, чтобы этот хлам поддерживали. Сейчас у всех на слуху новые браузеры. Про них пишут в литературе, в интернете. Не обновляются только совсем дремучие. Обратная ситуация, софт обновился, а в корпоративном секторе стоит старье.

http://www.positioniseverything.net/articl..._future_perfect