Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 141
Есть подозрение, что парсер пожрал что-то важное при публикации html-кодов 5 и 7 вариантов.
Там не парсер, а автор по ошибке в 7-м варианте оставил закрывающие теги <li>, хотя рассказал об этом и до, и после, и не ошибся в демо-примере :).
А зачем? Точнее так, статья хорошая — но действительно ли так критично это расстояние? Я использую inline-block только в горизонтальных меню с ul и li. Там эти расстояния, по моему, наоборот полезны.
Чтобы быть уверенным на 100%, что при вычислении ширины элементов, вы не ошибётесь на пару пикселей, из-за неучтённых пробелов.
Сам использую {srtip}, в Smarty, для этих целей.
Но в любом случае спасибо автору за эксперименты и информацию.
Сам использую {srtip}, в Smarty, для этих целей.
Но в любом случае спасибо автору за эксперименты и информацию.
Поверьте моему опыту. Порой это расстояние доставляет массу неудобств, что собственно и натолкнуло меня на изучение данной проблемы.
Плюс ко всему, администрируя один из известных форумовов, мною лично (далеко не один раз) было замечено, что многих так же беспокоят эти ненавистные пробелы.
Плюс ко всему, администрируя один из известных форумовов, мною лично (далеко не один раз) было замечено, что многих так же беспокоят эти ненавистные пробелы.
Я сойду с ума, если прочитаю весь этот текст?
За материал спасибо, но уж больно тернист путь к результату. Неужели нельзя было несколько короче?
За материал спасибо, но уж больно тернист путь к результату. Неужели нельзя было несколько короче?
ВАЖНО! Если вы используете трюки типа display: table-cell/table, учтите, что их поддержка весьма кривая, во-первых у вас могут теряться маргины (правильно, какие могут быть маргины у ячеек таблицы), вы-вторых, браузеры автоматом для блока с table-cell могут добавить родительские анонимные блоки table-row и table, и как-то этим сломать верстку.
По мне так, лучший способ — HTML комментарии, так как кроссбраузерно и сразу понятно, зачем они сделаны. Или, если не нужно вертикальное выравнивание, проще использовать флоаты и не париться.
По мне так, лучший способ — HTML комментарии, так как кроссбраузерно и сразу понятно, зачем они сделаны. Или, если не нужно вертикальное выравнивание, проще использовать флоаты и не париться.
Статья хороша. Все подробно описано. Спасибо!
Статья плохая, на 90% состоит из воды.
К чему это, дружище? К данной статье я приложил кучу сил и времени, подробнейше изложив и разжевав всё до мелочей.
Возможно для вас это и вода, кто бы спорил. Я вообще не знаю, что могло бы вас удивить, после чего вы воскликнули бы «Вау!». При всём моём уважении к вам, попрошу, не равняйте всех под свою гребёнку плз.
Возможно для вас это и вода, кто бы спорил. Я вообще не знаю, что могло бы вас удивить, после чего вы воскликнули бы «Вау!». При всём моём уважении к вам, попрошу, не равняйте всех под свою гребёнку плз.
Зря ты так, homm ;) Таких глубоких и исчерпывающих статей по CSS очень мало.
Если даже на главной странице Студии Лебедева для поставленной целей втыкают жуткую заскриптованную таблицу, которая вообще не отображается с отключенным JS, то эта статья очень актуальна.
Если даже на главной странице Студии Лебедева для поставленной целей втыкают жуткую заскриптованную таблицу, которая вообще не отображается с отключенным JS, то эта статья очень актуальна.
>>> Зря ты так, homm ;) Таких глубоких и исчерпывающих статей по CSS очень мало.
В том-то и дело, спасибо, что вы это понимаете и цените труд.
В том-то и дело, спасибо, что вы это понимаете и цените труд.
Очень актуальна. Но на 90% состоит из воды.
> Таких глубоких и исчерпывающих статей по CSS очень мало.
Похоже на сарказм. Статья вообще-то об одной особенности одного конкретного свойства.
Похоже на сарказм. Статья вообще-то об одной особенности одного конкретного свойства.
А при чем тут мое «вау»? Я указал на конкретны недостаток. Если бы статья был написана более сжато, она не потеряла бы полезности, но сил вы бы положили на нее меньше.
Да, полезности она бы не потеряла, возможно, не спорю, но и понятливости со стороны сообщества было бы в разы меньше. Вы очень опытный, а вот Вася с Петей — нет, для них наоборот нужно всё поподробнее разжёвывать, чтобы донести как надо.
А потом, я и сам люблю копаться и рыться в материале досконально, а материала накопилось очень много, поэтому и выложил всё сразу.
А потом, я и сам люблю копаться и рыться в материале досконально, а материала накопилось очень много, поэтому и выложил всё сразу.
Усваиваемость (понятливость со сторону сообщества) не улучшается при увеличении усваиваемого материала, а часто наоборот. Вот у вас в каждом способе есть скриншот, на котором все ок. Это же каждый раз приходится его смотреть, выяснять, все ли на нем ок, или вы хотите этим скриншотом показать что что-то отличается. А вот писали бы вы всегда «При таком способе проблемы появляются только в webkit: <скриншот>», и все сразу понятно.
Извиняюсь, не туда воткнул каммент.
habrahabr.ru/blogs/css/137582/#comment_4584132
habrahabr.ru/blogs/css/137582/#comment_4584132
Рад был помочь. Изучайте!
Я всегда лечу через «заворот кишок»:
<ul
><li>Item 1</li
><li>Item 2</li
><li>Item 3</li
></ul>
Спасибо за статью! Я же всегда пользуюсь 5 способом и проблем не знаю. Очень люблю применять inline-block для верстки, особенно для вывода каталога товаров. Правда я чаще пишу так:
Пробелы внутри блоков уже схлопываются, а между ними их нет.
- Item1
- Item2
Пробелы внутри блоков уже схлопываются, а между ними их нет.
Ещё есть вариант с «float: left», правда у него тоже свои недостатки.
Приветствую тебя на Хабре, «дружище»! Хорошая первая статья для начинающих, так держать!
З.Ы. Лично для себя обычно использую комбинацию этого всего:
При этом если вдруг захочется выравнивать элементы с помощью text-align:justify; то тут могут быть неприятные сюрпризы в Chrome, Opera и Safari. Впрочем, играя с размером шрифта их можно обойти.
З.Ы. Лично для себя обычно использую комбинацию этого всего:
UL {
font:0/0 a;
letter-spacing:-1em;
word-spacing:-1em;
}
UL LI {
font:12/16px Arial, sans-serif;
letter-spacing:0;
word-spacing:0;
}
При этом если вдруг захочется выравнивать элементы с помощью text-align:justify; то тут могут быть неприятные сюрпризы в Chrome, Opera и Safari. Впрочем, играя с размером шрифта их можно обойти.
С комментариями решение самое оптимальное — не нужно гадать, какой шрифт в меню и какой есть у пользователя, подстраиваться под браузеры и самое важное — в меню могут быть вложенные элементы (подменю например) — им не нужно выставлять обнуленные у родителя значения (в случае font-size=0 у родителя, потомку придется задавать font-size только в пикселях)
Лично для меня статья оказалась очень интересна и полезна. Спасибо!
Небольшое предложение автору для будущих исследований: было бы интересно развить эту тему и узнать о построении кроссбраузерного горизонтального меню, которое находится в резиновой верстке и при этом выровнено по центру блока. И как вариант равномерно растягивается по ширине. Я в сети видел много различных решений, сам придумывал свои велосипеды, однако глубоко и полно этот вопрос так и не разобрал.
Небольшое предложение автору для будущих исследований: было бы интересно развить эту тему и узнать о построении кроссбраузерного горизонтального меню, которое находится в резиновой верстке и при этом выровнено по центру блока. И как вариант равномерно растягивается по ширине. Я в сети видел много различных решений, сам придумывал свои велосипеды, однако глубоко и полно этот вопрос так и не разобрал.
Рад, что труды оказались не напрасны. Рад был поделиться знаниями.
По поводу вашего предложения:
Если не сложно, то скиньте мне в ЛС пример того, что вы имеете ввиду, возможно я уже роюсь в этом направлении.
Единственное, не факт, что публиковаться я буду именно на Хабре, я недавно открыл свой личный блог, где и буду разбирать все вопросы в своих постах. Так что, если что, добро пожаловать, буду рад помочь!
По поводу вашего предложения:
Если не сложно, то скиньте мне в ЛС пример того, что вы имеете ввиду, возможно я уже роюсь в этом направлении.
Единственное, не факт, что публиковаться я буду именно на Хабре, я недавно открыл свой личный блог, где и буду разбирать все вопросы в своих постах. Так что, если что, добро пожаловать, буду рад помочь!
Спасибо, статьяна очень интересна и актуальна, буквально вчера как раз верстал с помощью inline-block, для себя решил отрицательными значениями margin, но сейчас исправлю на комментарий, симпатичнее выглядит.
Спасибо большое за статью.
Но, всё таки, самый практичный вариант это 5й, тем более, что полезно удалять [\n, \t, комментарии, двойные пробелы] перед выдачей html-файла клиенту.
Но, всё таки, самый практичный вариант это 5й, тем более, что полезно удалять [\n, \t, комментарии, двойные пробелы] перед выдачей html-файла клиенту.
Серебренная пуля:
Стех пор как подсмотрел в YUI CSS Grids, оно меня еще ниразу не подводило
ul {
letter-spacing: -0.31em; /* webkit: collapse white-space between units */
*letter-spacing: normal; /* reset IE < 8 */
word-spacing: -0.43em; /* IE < 8 && gecko: collapse white-space between units */
}
li {
display: inline-block;
zoom: 1; *display: inline; /* IE < 8: fake inline-block */
letter-spacing: normal;
word-spacing: normal;
}
Стех пор как подсмотрел в YUI CSS Grids, оно меня еще ниразу не подводило
Свойство zoom не канонично, хорошо бы спрятать.
Чем же оно не канонично, и можно ссылку на «каноны»?
Разумеется, наслаждайтесь.
Тогда все браузерные проприетарные перфиксы — против «канонов», text-overflow — против «канонов», text-shadow — против «канонов», анимации, трансформации — всё против «канонов»?
А ведь zoom — это не только MSIE only свойство, webkit его тоже поддерживает.
А ведь zoom — это не только MSIE only свойство, webkit его тоже поддерживает.
Проприетарные префиксы этично использовать для совместимости с предыдущими версиями, причем с поправкой на ограниченную видимость для остальных библиотек. Добавлять в код нестандартные и некомментируемые элементы — значит рисковать работоспособностью написанного в дальнейшем. Вы же не можете быть уверены, что в следующей спецификации не введут определение zoom с совершенно другими свойствами, чем те, которые вы ожидаете увидеть на каких-то отдельных движках сегодня.
Поэтому говорить что «ну ведь сейчас-то работает» непрофессионально. О чем я вам и постарался аккуратно намекнуть.
Поэтому говорить что «ну ведь сейчас-то работает» непрофессионально. О чем я вам и постарался аккуратно намекнуть.
> А ведь zoom — это не только MSIE only свойство, webkit его тоже поддерживает.
Пруф?
Пруф?
Для статьи делать это совершенно ни к чему, читатели должны видеть весь код, а ни держать всякие zoom-ы в уме*, а уже в своих проектах вы вольны делать так, как хотите. Конечно же, правильно было бы отправить это свойство в условные комментарии, но в статье это необязательно.
Читатели должны видеть прежде всего корректный синтаксис в соответствии с действующими спецификациями. Свойство 'zoom' таковым не является.
Пишите это к каждой статье про CSS3 и HTML5.
Хорошо ещё, что я не применял префиксы, иначе вы бы меня съели вообще)
В данном случае overflow-wrap будет алиасом word-wrap, что, в принципе, логично, т.к. подразумевается перенос не в рамках слова, а в рамках элемента. Отменять устаревшее значение пока никто не собирается.
А вот каких свойств можно ожидать от zoom — непонятно.
А вот каких свойств можно ожидать от zoom — непонятно.
Перенос в рам-
ках слова ниче-
го общего не име-
ет с word-wrap.
От недокументированного свойства можно ждать чего угодно, в качестве примера: даже если вы интуитивно предугадали действие, в каких единицах по умолчанию будет считаться свойство? Проценты? Пункты? Пиксели? Не рискуете ли автор наделить меню с 'zoom:1' размером в 1% от родительского элемента?
Валидация — процесс проверки на соответствие стандартам. Когда, скажем, человек пишет в резюме о знании стандартов CSS2 и HTML4 — это значит что он умеет пользоваться ими без ошибок. Туалетный валидатор — примитивное средство проверки на ошибки. Что с результатами проверки делать, каждый решает для себя сам.
А в целом я очень не хочу развивать полемику о достоинствах и недостатках таблиц стилей и предлагаю вернуться к изначальному предложению писать грамотно. Всего-навсего.
ках слова ниче-
го общего не име-
ет с word-wrap.
От недокументированного свойства можно ждать чего угодно, в качестве примера: даже если вы интуитивно предугадали действие, в каких единицах по умолчанию будет считаться свойство? Проценты? Пункты? Пиксели? Не рискуете ли автор наделить меню с 'zoom:1' размером в 1% от родительского элемента?
Валидация — процесс проверки на соответствие стандартам. Когда, скажем, человек пишет в резюме о знании стандартов CSS2 и HTML4 — это значит что он умеет пользоваться ими без ошибок. Туалетный валидатор — примитивное средство проверки на ошибки. Что с результатами проверки делать, каждый решает для себя сам.
А в целом я очень не хочу развивать полемику о достоинствах и недостатках таблиц стилей и предлагаю вернуться к изначальному предложению писать грамотно. Всего-навсего.
Свойство zoom не канонично, хорошо бы спрятать.
Вы — большой молодец. Продолжайте в том же духе.
Спасибо за слова, но, к сожалению, у меня всегда очень мало времени даже на себя, а про написании статей я уже вообще молчу(((. Здесь мне удалось удивительным образом выкроить время и поделиться своими знаниями с сообществом. Воспользовался так сказать, возможностью. Да, и, опять же, у меня ещё сырой блог, поэтому для начала желательно заполнить статейками именно его.
Спасибо за статью! Эх, часика на три бы пораньше ))…
Как раз около полуночи с этими невесть откуда взявшимися 6 пикселами страдал ( ну да, в вёрстке новичок… ). В итоге пришёл к варианту 5. Но всё равно, прочитал статью с интересом ;)…
Как раз около полуночи с этими невесть откуда взявшимися 6 пикселами страдал ( ну да, в вёрстке новичок… ). В итоге пришёл к варианту 5. Но всё равно, прочитал статью с интересом ;)…
С почином, Макс! Молодец!
Хм. Всё замечательно, но я бы верстал такое «меню» через display: block и float: left
Или есть какая-то определенная потребность в inline-block, кроме демонстрации решения?
Или есть какая-то определенная потребность в inline-block, кроме демонстрации решения?
1) float: left уже делает элемент блочным.
2) Прочитайте внимательно, о чём статья.
2) Прочитайте внимательно, о чём статья.
inline-block, как видно из названия, умудряется сочетать свойства инлайнового (внутристрочного) и блочного элементов: внутри он блочный (может содержать другие блоки
Что Вы хотели этим сказать? Запрет на вложение блочных элементов в строчные определён в HTML, он безразличен к тому, что написано в CSS-стилях. То есть вот так неправильно:
<span style="display: inline-block;"><div></div></span>Вывод такой, что этот метод не подходит «фанатикам валидности ради валидности», выбирающим XHTML-доктайп
Вы зря изображаете каких-то идиотов. Не ради валидности — с валидностью-то (по HTML5) тут всё в порядке, как Вы правильно отметили,— а ради XML-конформности, а оная нужна для упрощения парсинга, например.
Где тупые браузеры не умеют получать странички в mime-type отличном от text/html… Список тупых браузеров, думаю известен всем…
Во-первых, не «в HTML больше нет», а в HTML5 больше нет. Если даже Вы полагаете, что более новый стандарт отменяет более старый (что, строго говоря, неверно, но с чем я соглашусь как с допустимым упрощением), HTML5 не стандарт, а проект и это, увы, ещё надолго.
Во-вторых, если Вы рассуждали относительно HTML5, то Ваше утверждение также неверно, поскольку, хотя в HTML5 и другие модели содержимого, но и там CSS-стили на них не влияют. Элемент может вкладываться в другой или нет независимо от того, какой им прописывать стиль [
Во-вторых, если Вы рассуждали относительно HTML5, то Ваше утверждение также неверно, поскольку, хотя в HTML5 и другие модели содержимого, но и там CSS-стили на них не влияют. Элемент может вкладываться в другой или нет независимо от того, какой им прописывать стиль [
display].Ну. Тогда как следует понимать Ваше утверждение, что, де, элемент с
В общем, ситуация, по моему, совершенно ясна: Вы неудачно выразились в этом моменте.
display: inline-block «может содержать другие блоки», если способность элементов содержать что-либо никак не зависит от задаваемых им стилей?В общем, ситуация, по моему, совершенно ясна: Вы неудачно выразились в этом моменте.
Запреты на вложенность блочных элементов в строчные определён в HTML4. Поэтому я и пытаюсь перевести разговор на модели содержимого в HTML. А если речь идёт о визуальных боксах, определённых в CSS, то там нет запрета на вложенность. С чего Вы взяли, что инлайновые боксы не могут содержать блочные боксы? Легко!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ru" lang="ru">
<head>
<title>Пример</title>
</head>
<body>
<p style="display: inline;"><span style="display: block;"></span></p>
</body>
</html>
Те, кому нужен XML-парсинг собственных страниц (зачем, кстати?)
Почему обязательно собственных? А о других людях подумать?
слегка отрезвить и вернуть «из страны иксэмэльфов» в реальный мир, где браузеры получают странички как text/html…
Вы опрометчивы, полагая, что реальный мир сводится к Вашей практике. В области моей разработки страницы испокон веку отдаются как
application/xhtml+xml или даже application/vnd.mozilla.xul+xml.О других людях подумали разработчики современного алгоритма HTML-парсинга
Угу-угу, и алгоритм сей настолько прост, что отладить его намечено уже к 2022 году.
разве в области *.mozilla.xul проблема выстраивания блочных боксов по горизонтали не решается более специализированными инструментами, чем инлайн-блоки?..
На XUL там пока только небольшой фрагмент и неизвестно, будет ли сильно больше. Остальное — честный XHTML 1.1. Буду переводить на XHTML5, конечно. Занялся бы этим раньше, но в проекте был двухлетний перерыв в связи с кризисом, да и делался он прежде под очень старую версию браузера.
И где
PHP-метод для разбора HTML в DOM-дерево?С
XHTML, однако, у PHP никаких проблем нету. Ну, почти никаких. Так что не вижу смысла отказываться от XML-синтаксиса при использовании HTML5. Ну, разве что кто-то так и не приучился к нему в прежние времена. Ну так есть люди, не приучившиеся деепричастные обороты обособлять запятыми,— почему я должен брать с них пример и радоваться упрощению жизни?На практике этот метод засыпал меня уорнингами, пока я не
XHTML делает тэг-суп с неожиданными порой последствиями невозможным и приучает его не допускать, в чём его великая историческая заслуга. А в этом HTML поди вспомни, какой тэг можно не закрывать, а какой нельзя. Лучше уж закрывать все и спать спокойно.
libxml_use_internal_errors(true)XHTML делает тэг-суп с неожиданными порой последствиями невозможным и приучает его не допускать, в чём его великая историческая заслуга. А в этом HTML поди вспомни, какой тэг можно не закрывать, а какой нельзя. Лучше уж закрывать все и спать спокойно.
Какие-то странные и витиеватые у вас обоснования для этих пробелов.
Из которых нечайно даже можно сделать неверный вывод, что inline-block элементы интерпретируются как слова, а между словами автоматически вставляются междусловные интервалы.
По всем мыслимым стандартам, разрыв строки — это пробел, whitespace.
Если любой пробел стоит, то он отображается как пробел.
Если никакого пробела не стоит, пробел не отображается.
(в текстовом контексте, для которого не указано всякое 'pre').
Вот и всё. И так было всегда.
Из которых нечайно даже можно сделать неверный вывод, что inline-block элементы интерпретируются как слова, а между словами автоматически вставляются междусловные интервалы.
По всем мыслимым стандартам, разрыв строки — это пробел, whitespace.
Если любой пробел стоит, то он отображается как пробел.
Если никакого пробела не стоит, пробел не отображается.
(в текстовом контексте, для которого не указано всякое 'pre').
Вот и всё. И так было всегда.
inline-block смело можно рассматривать, как одну большую букву, причём неразрывную. Так же как и буквы могут иметь пробелы между собой, так и инлайн-блоки тоже не обделены этой особенностью.
Про «автоматизм» я вроде нигде не упоминал, а как раз таки наоборот, описал ситуацию с пробелами в случае разрыва строки в структуре. Перевод строки — который преобразуется в пробел. Всё верно, поэтому я не понимаю, что вам могло показаться не так.
Про «автоматизм» я вроде нигде не упоминал, а как раз таки наоборот, описал ситуацию с пробелами в случае разрыва строки в структуре. Перевод строки — который преобразуется в пробел. Всё верно, поэтому я не понимаю, что вам могло показаться не так.
Не всегда. Пробел убирается в конце line-box'а, игнорируется между блочными элементами, и еще много-много вариантов, когда пробел не пробел.
Чем «работающее» решение отличается от «рабочего»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Загадочные отступы» между инлайн-элементами