overflow:hidden

kvant · March 16, 2011

Есть некоторый код (для примера)


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title></title>
</head>
<style>
div {
}
ul {
	list-style-type:none;
    margin: 0;
	padding: 0;
}
li {
	float: left;
	margin: 3px;
}
</style>
<body>
<ul>
<li>1</li>
<li>2</li>
<li>3</li>
<li>4</li>
<li>5</li>
</ul>
<div>
bla-bla-bla
</div>
<ul>
<li>1</li>
<li>2</li>
<li>3</li>
<li>4</li>
<li>5</li>
</ul>
</body>
</html>

Посмотреть как работает можно здесь

В этом примере все криво и не так как нужно.

Проблему исправляет overflow: hidden для элемента ul. См. Посмотреть как работает можно здесь

Хотелось бы понять как все это работает. Почему без overflow все криво, а с ним нормально?

Насколько вообще корректен этот код, может можно сделать проще?

psywalker · March 17, 2011

и жирным минусом в виде значащих пробелов между тегами.

Хорошо, а как ты смотришь на такой выход?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Inline-block</title>
<style type="text/css">
	* { margin: 0; padding: 0;}
	.vegetables {
		letter-spacing: -3px;
		font-size: 0;

	}
		.vegetables li { 
			display: inline-block;
			vertical-align: top;
			background: red;
			letter-spacing: 0;
			font-size: 12px;

		}
</style>
</head>

<body>

	<ul class="vegetables">
		<li><a href="#">и жирным минусом в виде значащих пробелов между тегами. </a></li>
		<li><a href="#">и жирным минусом в виде значащих пробелов между тегами. </a></li>
		<li><a href="#">и жирным минусом в виде значащих пробелов между тегами. </a></li>
		<li><a href="#">и жирным минусом в виде значащих пробелов между тегами. </a></li>
		<li><a href="#">и жирным минусом в виде значащих пробелов между тегами. </a></li>
	</ul>

</body>
</html>

ПРоблема будет в ИЕ6-7, надо дисплей инлайн и зум дописать.

Это не проблема. Показывать, как пишется?

sigma77 · March 17, 2011

Где проблема?

Даже при таком количестве текста проблема есть

psywalker · March 17, 2011

Даже при таком количестве текста проблема есть

Выше постом я предлагаю решение этой проблемы.

sigma77 · March 17, 2011

Хорошо, а как ты смотришь на такой выход?

Это не выход, т.к. ширина пробела и расстояние между символами может отличаться в разных браузерах даже под одной ОС. Например в сафари под виндами точка съедается. В той же убунте, данный пример не проверяла, но эти расстояния обычно больше.

psywalker · March 17, 2011

Это не выход, т.к. ширина пробела и расстояние между символами может отличаться в разных браузерах даже под одной ОС. Например в сафари под виндами точка съедается. В той же убунте, данный пример не проверяла, но эти расстояния обычно больше.

Для этого всегда есть отличное средство. Масштабируемые единицы, такие например как em

sigma77 · March 17, 2011

Выше постом я предлагаю решение этой проблемы.

Там про пробелы, я же про размещение блоков друг под другом.

psywalker · March 17, 2011

Там про пробелы, я же про размещение блоков друг под другом.

В смысле, а в чё проблема?

sigma77 · March 17, 2011

В смысле, а в чё проблема?

При небольшом контенте или маленькой ширине блоки встают в ряд, а не друг под другом как в нормальном потоке

Justnewone · March 17, 2011

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

psywalker · March 17, 2011

При небольшом контенте или маленькой ширине блоки встают в ряд, а не друг под другом как в нормальном потоке

Извини, тогда я не очень понял задачу. Ведь ты же сама написала:

Блоки должны быть друг под другом. Но при небольшом контенте блоки могут встать на одну строку.

sigma77 · March 17, 2011

Извини, тогда я не очень понял задачу. Ведь ты же сама написала:

Да, наверное, я неточно сформулировала. Имелось ввиду, что это минус inline-block, то что блоки могут встать в один ряд тогда, когда это совсем не нужно

psywalker · March 17, 2011

Да, наверное, я неточно сформулировала. Имелось ввиду, что это минус inline-block, то что блоки могут встать в один ряд тогда, когда это совсем не нужно

А с float разве не аналогично?

sigma77 · March 17, 2011

А с float разве не аналогично?

Похоже, но не идентично. Обтекание можно отменить, а вот поведение inline-block нельзя

SelenIT · March 17, 2011

как ты смотришь на такой выход?

Лично я — отрицательно (по тем же причинам, что озвучила sigma77 — никогда не скажешь наверняка, что у конкретного пользователя пробел будет точно 5px или точно .333em). Как и на обнуление font-size контейнеру с последующим выставлением его потомкам (в каких-то браузерах, не помню точно в каких, при этом оставались однопиксельные разрывы), хотя при фиксированном шрифте это чуть ближе к делу. На мой взгляд, единственное реальное решение — честно убрать эти пробелы, остальное — костыли. Но тогда приходится идти на компромиссы в плане читаемости кода.

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

А с float разве не аналогично?

Почти аналогично в плане поведения самих блоков, не аналогично в плане влияния на внешний контейнер этих блоков (inline-блоки хотя бы сами не требуют clear-ить контейнер). Поэтому, сугубо имхо, inline-block всё-таки чуточку лучше. Но лишь самую чуточку

psywalker · March 17, 2011

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

Покажи пример плиз

Justnewone · March 17, 2011

Хочеца написать пример

SelenIT · March 17, 2011

Да чего там показывать? Просто не закрывать <li> явно...

<ul>
	<li>
		<h3>Inline-block</h3>
		<p>Удобная вещь, но с нюансами.</p>
	<li>
		<h3>Float</h3>
		<p>Старый проверенный метод, но требует подпорок.</p>
	<li>
		<h3>Table/table-cell</h3>
		<p>Блок никуда не убежит, но ширина тоже может скукожиться.</p>
</ul>

psywalker · March 17, 2011

Да чего там показывать? Просто не закрывать <li> явно...

<ul>
	<li>
		<h3>Inline-block</h3>
		<p>Удобная вещь, но с нюансами.</p>
	<li>
		<h3>Float</h3>
		<p>Старый проверенный метод, но требует подпорок.</p>
	<li>
		<h3>Table/table-cell</h3>
		<p>Блок никуда не убежит, но ширина тоже может скукожиться.</p>
</ul>

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

SelenIT · March 17, 2011

Неправильно только с точки зрения синтаксиса XML, поэтому неприменимо в XHTML (настоящем). Семантике пофигу (в чем-то даже чуточку лучше — меньше незначащей разметки), браузерам, при типе контента text/html, тоже. Плюс единообразие с IE7- (он закрывающие </li> в любом случае игнорирует). Практических минусов, честно говоря, не вижу...

Justnewone · March 17, 2011

Если в документе правильный доктай, который это допускает - то почему бы и нет?

Хотя я, конечно, осторожно и с опаской, какгрица...

psywalker · March 17, 2011

Неправильно только с точки зрения синтаксиса XML, поэтому неприменимо в XHTML (настоящем). Семантике пофигу (в чем-то даже чуточку лучше — меньше незначащей разметки), браузерам, при типе контента text/html, тоже. Плюс единообразие с IE7- (он закрывающие </li> в любом случае игнорирует). Практических минусов, честно говоря, не вижу...

Да, но например цмс гинерит код, он же всегда с закрывающими тегами.

Хотя я, конечно, осторожно и с опаской, какгрица...

И я)

SelenIT · March 17, 2011

цмс гинерит код, он же всегда с закрывающими тегами

У уважающих себя ЦМС, по-моему, бывает опция "выдавать генерируемый код в одну строку для экономии трафика и вообще". Если речь о собственном шаблоне, его тоже всегда можно подправить, чтобы элементы шли подряд без зазоров. При автоматической генерации, имхо, проблема как раз менее актуальна.

А насчет опаски, после знакомства с вышеупомянутым багом IE7-, я как раз стал с опаской относиться к закрывающим тегам (где они опциональны) — как к источнику потенциальной неоднозначности (на практике, в теории-то должно быть наоборот)...

psywalker · March 17, 2011

У уважающих себя ЦМС, по-моему, бывает опция "выдавать генерируемый код в одну строку для экономии трафика и вообще". Если речь о собственном шаблоне, его тоже всегда можно подправить, чтобы элементы шли подряд без зазоров. При автоматической генерации, имхо, проблема как раз менее актуальна.
А насчет опаски, после знакомства с вышеупомянутым багом IE7-, я как раз стал с опаской относиться к закрывающим тегам (где они опциональны) — как к источнику потенциальной неоднозначности (на практике, в теории-то должно быть наоборот)...

Согласен. Тогда выходит всё упирается в доктайп?

Justnewone · March 17, 2011

У уважающих себя ЦМС, по-моему, бывает опция "выдавать генерируемый код в одну строку для экономии трафика и вообще". Если речь о собственном шаблоне, его тоже всегда можно подправить, чтобы элементы шли подряд без зазоров. При автоматической генерации, имхо, проблема как раз менее актуальна.
А насчет опаски, после знакомства с вышеупомянутым багом IE7-, я как раз стал с опаской относиться к закрывающим тегам (где они опциональны) — как к источнику потенциальной неоднозначности (на практике, в теории-то должно быть наоборот)...

Можно подробней?

Как это проявилось? Типа после инлайна не было пробела или чеаще?

SelenIT · March 17, 2011

выходит всё упирается в доктайп?

С точки зрения валидации — да. С точки зрения браузеров — скорее, в mime-тип. Это же закреплено в новом "живом стандарте": при text/html любой доктайп должен парситься по правилам HTML5 с опциональными тегами, при что-то/что-то+xml — любой доктайп, хоть никакого, парсится как XML.

Как это проявилось?

Меня ткнули носом на Хабре. Я долго не верил...

Sign In

overflow:hidden

Question

Link to comment

Share on other sites

Top Posters For This Question

Popular Days

Top Posters For This Question

Popular Days

51 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information