Ненужные отступы в списках

[Q2W]

Я так ещё с img делаю, IE после него тоже пробел ставит.

[NukerF]

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

[hannimed]

Почему «тоже»? Тут то как раз проблема не IE.

[tenshi]

и давно мозилла стала поддерживать haslayout? =)

[kaa]

а можно ссылку на описание проблемы вертикальных отсупов?
у них похоже общие корни.

[tenshi]

ul+li — это список текстовых блоков. если тебе нужно выстроить их в одну строку — зачем применять список блоков, а потом избавляться от маркера и нежелательных отступов?

[tenshi]

а я о чём?

[pepelsbey]

Не обращайте внимания, у этого человека собственный путь ©

[VolCh]

а в спецификации сказано что это вертикальный список?

[tenshi]

1. там есть куча примеров вертикальных списков и нет ни одного горизонтального.
2. в соответствии с дтд в li может быть любой flow элемент, а значит сам li — блочный.
3. также там написано, что «элемент menu был предназначен для задания вертикального меню, но был упразднён ввиду такой же внутренней структуры, что и у ul».

[homm]

> просто непостижимо, как MS жили столько лет с таким дичайшим багом.
я вам больше скажу:
<dl>
<dt>Qwe</dt>
<dd>Qwe</dd>
<h2>Qwe</h2>
<dt>Qwe</dt>
<dd>Qwe</dd>
</dl>
Угадайте, кто станет предком для h2?

[kaa]

dd судя по всему :) круто

[homm]

Эксплорер знает что такое DTD? Т.е. я могу прописать DTD, согласно которому это возможно и оно заработает? Мне почему-то кажется что это, и еще много чего, прописано тупо кучкой ифов в исходниках индусских друзей.

[homm]

> Но это проблема рендеринга CSS, а не парсинга HTML.
Разрешите оспорить ваше предположение.

Код из статьи:
<style>
ul, li {
list-style: none;
display: inline;
padding: 0;
margin: 0;}
li {
border: 1px solid black;}
</style>
<UL>
<LI>Qwe</LI>
<LI>Asd</LI>
<LI>Zxc</LI>
</UL>

Смотрим в дебагере содержимое тегом LI: «Qwe ». Именно так, с пробелом. Так что это не CSS. Ошибка в доме.

[no_smoking]

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

[malyshev]

getElementsByTagName('li') — куда уж проще…

[DibrovLALALA]

вот критин, я про ие

[ArtemS]

А можно сделать так
li {
float: left;
}


[chestah]

а по центру выровнять

[Methos]

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

дарю

function cb_for_trim($m){
return ("> ".trim($m[1])." <");
}
function ob_start_callback($s) {
$s = str_replace("\t", "", $s);
$s = preg_replace_callback("/>\s(.*?)\s</i", «cb_for_trim», $s);
$s = preg_replace("/>\s+</i", "><", $s);
return $s;
}

…
ob_start(«ob_start_callback»);

[TiGR]

А как ваш замечательный код отнесётся к такому коду:

Как <a href="...">писал</a> <a href="...">вася пупкин</a>

И мне здесь совсем не нужен & nbsp;.

[Methos]

он вырезает пробелы между_тегами

поэтому будет так

писалвася пупкин

попробуйте, потом судите…

[TiGR]

Я этого и ожидал. И кому-нибудь нужна такая обработка? Когда в статье начнут склеиваться слова, клиент вряд ли будет рад. ИМХО, если уж и использовать подобые штучки, то вырезать пробелы нужно только между блочными элементами.

[Methos]

((-: я повторяю ещё раз — код вырезает всё лишнее только МЕЖДУ ТЕГАМИ.

между тегами, смею вас уверить, пробелов и переводов строк, табуляции может быть миллион символов — это на вёрстку никак не скажется.

[homm]

Вы на пример смотрели? Если нет, заклинение «повторяю еще раз» НЕ ПОМОЖЕТ.

[Methos]

вероятно, вы невнимательно посмотрели на код. и вероятно, не понимаете регулярку?

обратите внимание, если между тегами будет {тег} петя мыл раму {тег}

то это код уберёт пробелы только около тегов, между словами они останутся (-:
попробуйте

[TiGR]

Попробовал. По-вашему в строчной вёрстке не может быть ситуаций, как я описал? Я понял, что ваш скрипт тупо удаляет все пробельные символы между < и >. Есть много ситуаций, когда строчные тэги, такие как span, em, strong, a и тому подобные разделены пробелом. И этот пробел там совсем не лишний, и удалять его оттуда не нужно. Однако ваш код об этом не задумывается.

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

Равно как и в textarea, например в форме правки того же комментария не должен быть помят такой оптимизацией.

И да, я уже писал подобные вещи. Только мой код не имел цели удалить все пробелы, а лишь утоптать код. Выглядело это (упрощённо) примерно так:

$search  = array(
    "/((<!--\[if.*if]-->|"
        . "<script.*<\/script>|"
        . "<style.*<\/style>|"
        . "<pre.*<\/pre>|"
        . "<textarea.*<\/textarea>|"
        . "<td id='CODE'>.*<\/td>)|"
        . "(<!--.*-->|[\r\n\s]+?)+)/Uis");
$replace = array("\\2 ");
$buffer = preg_replace($search, $replace, $buffer);
return $buffer;

Цели удалить пробелы между блочными тегами не было. Была бы — код был бы иным.

[Methos]

спасибо, задумался (-:

[pepelsbey]

Человеку, который ТАК пишет код, хочется плюнуть в лицо.
Постпроцессинг (выпрямление кода) подарит вам счастье ;)

[kaa]

Не обязательно писать ТАК вручную, можно настроить ТАК постпроцессинг.
Тут описано понимание кода броузером а не формат исходников.

В глаза себе наплюй.

[chestah]

да, похоже у тебя действительно «собственный путь» ©

:>

[pepelsbey]

Статья, которая заканчивается рецептом «это можно исправить так» и призывом форматировать код с мусором или вообще разрушая целостность тега может вызвать только недоумение. Да — вы молодец, добавили апдейт, который поясняет вашу позицию.

А плевать в лицо я предлагал умникам, которые ТАК форматируют исходники.
Вы этого, как выяснилось, не предлагаете, хотя уязвлённое «сами плюньте» рождает сомнения.

Спокойнее, я ничего против вас лично не имею.
Просто выражаться нужно точнее.

[vithar]

А чем тебе не нравится третий вариант форматирования? Я тоже так делаю

[pepelsbey]

Это просто невозможно читать.

[homm]

«Так верстают только мудаки» ©

[chestah]

спасибо поржал спросонья :)

[dfitiskin]

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

Хотя изложить суть проблемы — сделать половину решения.

[kaa]

на счёт пальца слишком категорично.
я понимаю, что правильнее выпустить сервис пак к ie, но это не в моих силах.

суть проблемы: ie в отличие от остальных всё, что содердится между двумя li приписывает к сожержимому первого li.

суть решения: сделать так, чтобы между li ничего не было, тогда все броузеры будут вести себя одинаково.

[dfitiskin]

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

[tenshi]

а вариант записать ссылки подряд без всяких ul и li — не решение?

[tenshi]

ты всё ещё веришь, что в хтмл есть логика? =)

вот смотри, что бы имеем при использовании ul+li:
1. ужасный дефолтный стиль, который приходится обнулять кучей правил.
2. проблемы с ие разной степени тяжести.
3. внутренняя уверенность, что делаем всё по заветам мифической «семантической вёрстки»

а что имеем при использовании более подходящих средств:
1. адэкватный дефолтный стиль
2. нет специфичных проблем
3. твоя карма ползёт вниз

а по логике, меню — это такая штука, которая в общем случае состоит из [пунктов меню], [подменю], [формы поиска по меню] и которая ну совершенно не укладывается в концепцию «список однородных блоков».

[tenshi]

лучше всего браузеры рисуют те тэги, которые не понимают. точнее те, для которых у них не забито каких-то особых рендереров. поэтому я использую тэги my:menu и my:menu-item, которые куда более семантичны и предсказуемы нежели ul и li.

[dfitiskin]

Я прекрасно понял суть статьи, но все равно спасибо за разъяснения. Я же имел ввиду вот это:

Как избавиться от этой неоднозначности?
Ответов неколько: 1. 2. 3.

Не один из них не является хорошим решением, хотя и решает задачу. Я в этом согласен с pepelsbey. Хотя ход мыслей верный. Нужно было просто сказать что решение — избавиться от переносов строк между тегами LI. А приведенные примеры кода оставить с пометкой — так делать не рекомендуется.

[dfitiskin]

не закрывать теги — это не решение, уж простите

[TiGR]

А кто-нибудь пробовал скормить IE такое:

<ul>
<li>lorem</li></li>
<li>ipsum</li></li>
</ul>

В данный момент IE под рукой нет, так что проверить не могу. Будет крайне прикольно, если к такому коду IE отнесётся по-другому :)

[homm]

Инвариантно.

[almalexa]

Эх, жаль мой вариант не работает :(

ul {
word-spacing:5pt;
}

li {
margin-left:-5pt;
}

li:first-child {
margin-left:0;
}