Comments 147
Вы простите, но вот ваша секция с шрифтами по 8-9px улетает сразу в мусорку, потому как в браузерах есть минималка, например у меня она 10px. Перебить ее вроде как никак.
И 1920px браузера это слишком вы хорошо взяли. Где полоса прокрутки? Где рамки окна?
Не наезд, не подумайте, просто вопросы.
И 1920px браузера это слишком вы хорошо взяли. Где полоса прокрутки? Где рамки окна?
Не наезд, не подумайте, просто вопросы.
Про минимальный шрифт не подумала. Мне самой не совсем нравится эта часть с html, но к самой сетке это имеет косвенное значение.
Вопрос про полосу прокрутки и рамку не поняла…
Вопрос про полосу прокрутки и рамку не поняла…
Прежде хочу прощения просит за тон, писал на работе, сейчас сообщение перечитал и оно выглядит… грубоватым.
По поводу рамок:
>Это означает, что на ширине браузера 1920рх (которую я принимаю как отправную точку, поскольку для этой ширины чаще всего создается дизайн сайта) отступ блока с одной стороны будет 15рх.
Не берите отправной точкой ширину браузера. Ширина браузера = ширине монитора (если человек развернул его на весь экран), однако, в зависимости от системы (а на линуксе еще и DE) мы имеем различные декораторы окон системы. Например на Windows это 2-3 пикселя. На Linux 0-4. Эти области будут заняты рамкой самого окна, развернутого на весь экран, и уберутся только при полноэкранном режиме (F11).
Далее из кракозябр идет полоса прокрутки. На виндоузе ширина рабочей области, в которую помещается контент, равняется 1903 пикселя. На моем стареньком ноутбуке с убунтой под мате — 1910.
Для более точной работы берите через javascript размер области viewport и расчитывайте с него. Лично мне хватает простого document.documentElement.clientWidth
Про минимальный шрифт вы не правы. Ваш минимальный шрифт дает разрядку блокам. Если минималка будет больше чем вы ожидаете — блок уползет на следующую строку, а вы будете искать где у вас косяк в margin (я неделю искал в чем проблема по незнанию). Выход простой — блок комментария начинающийся сразу после элемента и идущий ровно до следующего. Он немного дубовый. но всеже.
По поводу рамок:
>Это означает, что на ширине браузера 1920рх (которую я принимаю как отправную точку, поскольку для этой ширины чаще всего создается дизайн сайта) отступ блока с одной стороны будет 15рх.
Не берите отправной точкой ширину браузера. Ширина браузера = ширине монитора (если человек развернул его на весь экран), однако, в зависимости от системы (а на линуксе еще и DE) мы имеем различные декораторы окон системы. Например на Windows это 2-3 пикселя. На Linux 0-4. Эти области будут заняты рамкой самого окна, развернутого на весь экран, и уберутся только при полноэкранном режиме (F11).
Далее из кракозябр идет полоса прокрутки. На виндоузе ширина рабочей области, в которую помещается контент, равняется 1903 пикселя. На моем стареньком ноутбуке с убунтой под мате — 1910.
Для более точной работы берите через javascript размер области viewport и расчитывайте с него. Лично мне хватает простого document.documentElement.clientWidth
Про минимальный шрифт вы не правы. Ваш минимальный шрифт дает разрядку блокам. Если минималка будет больше чем вы ожидаете — блок уползет на следующую строку, а вы будете искать где у вас косяк в margin (я неделю искал в чем проблема по незнанию). Выход простой — блок комментария начинающийся сразу после элемента и идущий ровно до следующего. Он немного дубовый. но всеже.
UFO just landed and posted this here
Блоки никуда не уйдут.
В блоке с классом .box размер шрифта обнуляется. По этому, кстати, и размер шрифта в rem))
P.S. Сам так делаю. Ибо
В блоке с классом .box размер шрифта обнуляется. По этому, кстати, и размер шрифта в rem))
P.S. Сам так делаю. Ибо
блок комментария начинающийся сразу после элемента и идущий ровно до следующегоне даёт выровнять блоки по ширине, используя text-align: justify;
Полоса прокрутки — да, но рамок окон нет в Ubuntu, MacOS
И вообще размеры в пикселях — прошлый век. Без html { font-size: 62.5% } и layout в rem в 2017 году писать нельзя!
Про html согласна. А почему в rem нельзя писать?
:D Следует читать
Без ( html { font-size: 62.5% } и layout в rem )
В rem писать нужно!
И em в тех местах где без него нельзя.
Пиксели остаются только в пределах media деклараций.
Вопрос к тем кто меня заминусовал, вы серьезно так отстали от жизни?
Если вам нужен fallback для пикселей, есть же инструменты автоматизации!
И em в тех местах где без него нельзя.
Пиксели остаются только в пределах media деклараций.
Вопрос к тем кто меня заминусовал, вы серьезно так отстали от жизни?
Если вам нужен fallback для пикселей, есть же инструменты автоматизации!
Угу, объясните это дизайн-команде, вымучивающей каждый пиксель.
Пусть они свои пиксели в фотошопах мучают, а в верстке пикселям места нет!
Вы не подумайте, что я тут против rem задвигаю, ни в коем случае. Просто если вам нужна страница с контентом, это прекрасный выбор, а если массивная торговая платформа, где зашкаливает количество всяких крутилок на квадратный сантиметр, то это просто пустая трата времени, ибо никогда у вас пиксель-перфект на выходе не сойдется при смене размеров/зума. А если еще и респонсив не нужен, то и автоматизироваться смысла нет.
Не все верстают текстовый и/или легко тянущийся контент, а вы слишком категоричны в суждениях, вот и схватили минусов, а не из-за того, что кто-то «отстал от жизни».
Не все верстают текстовый и/или легко тянущийся контент, а вы слишком категоричны в суждениях, вот и схватили минусов, а не из-за того, что кто-то «отстал от жизни».
Если вы задали 1 rem === 10px то ничего у вас никуда никогда не поплывет, зато media по объёму кода похудеют раз в 5 как минимум.
А теперь пользователь ставит 11px. Мой поинт не в том, что rem — плохо, а в том, что это не серебряная пуля, и не стоит так категорично утверждать обратное.
Пожалуйста объясните мне как пользователь поменяет размер rem? он же задается в CSS вами, как html { font-size: 62.5%; } // 1 rem === 10px и дальше масштабируется media screen and (max-width: ...px) { html { font-size: ...% }} // 1rem === ...px
Как пользователь задаст 1rem === 11px? если он полезет ручками в CSS то он сам себе злой буратино
Как пользователь задаст 1rem === 11px? если он полезет ручками в CSS то он сам себе злой буратино
UFO just landed and posted this here
Если у вас БЭМ, тогда:
reset.css использовать не нужно
* {} — очень плохо, он вам не нужен
normalize.css — он вам тоже не нужен, пропишите дефолтные свойства, только тем тегам, что вы реально используете в проекте и то, как вам нужно, чтоб потом не переопределять.
Следующий момент, инлайн-блоки плохо годятся на роль сетки. Настоящая сетка — это разделение по горизонтали И по вертикали.
На текущий момент делить по вертикали могут только display: flex;
(ну и таблицы, привет old school)
reset.css использовать не нужно
* {} — очень плохо, он вам не нужен
normalize.css — он вам тоже не нужен, пропишите дефолтные свойства, только тем тегам, что вы реально используете в проекте и то, как вам нужно, чтоб потом не переопределять.
Следующий момент, инлайн-блоки плохо годятся на роль сетки. Настоящая сетка — это разделение по горизонтали И по вертикали.
На текущий момент делить по вертикали могут только display: flex;
(ну и таблицы, привет old school)
На работе мы используем normalize.css, а я бывает использую * {}. Но я повторюсь, это косвенно относится к сетке. Можно вообще не нормализовать теги.
По поводу того, что инлайн-блоки плохо годятся на роль сетки, не могу с вами согласится. Инлайн-блоки выравниваются и по-горизонтали, и по-вертикали. По крайней мере лучше выравниваются, чем флоаты, на которых работают почти все html-фреймвоки.
По поводу того, что инлайн-блоки плохо годятся на роль сетки, не могу с вами согласится. Инлайн-блоки выравниваются и по-горизонтали, и по-вертикали. По крайней мере лучше выравниваются, чем флоаты, на которых работают почти все html-фреймвоки.
>>инлайн-блоки плохо годятся на роль сетки, не могу с вами согласится
сделайте реальную сетку:
1) header
2) main (тут section & aside)
3) footer
шапка должна быть сверху.
в самом низу окна браузера подвал.
между шапкой и подвалом блок main, в котором справа расположен aside, который располагается по всей высоте экрана.
сделайте реальную сетку:
1) header
2) main (тут section & aside)
3) footer
шапка должна быть сверху.
в самом низу окна браузера подвал.
между шапкой и подвалом блок main, в котором справа расположен aside, который располагается по всей высоте экрана.
* {} — очень плохо
Почему?
Это очень ресурсоемкий селектор.
UFO just landed and posted this here
Да чушь это. Легенда, 1000 раз переданная из уст в уста. И каждый участник цепочки думает «ну если так много об этом говорят, значит наверное правда».
Ну то есть это действительно не самый быстрый селектор на свете, но в общем ряду пожирателей ресурсов и врагов перфоманса он стоит где-то на сороковом месте.
Ну то есть это действительно не самый быстрый селектор на свете, но в общем ряду пожирателей ресурсов и врагов перфоманса он стоит где-то на сороковом месте.
Есть best practices, есть worst practices. Если вы постоянно используете best practices и избегаете worst practices то вы становитесь лучше как профессионал и вам больше платят. А если тяп ляп и в продакшен, то больше 20$ в час вам платить никогда не будут и ваши прямые конкуренты — индусы.
Никакая это не worst практика, а самая обычная.
У нее есть и достоинство — надежность. Завтра появится новый тег и он точно ничего не поломает.
По производительности там разница настолько копеечная, что видна разве что только в микроскоп. Хотя можно искусственно сгенерировать такой пример, где это станет заметно, но к реальной практике он не будет иметь никакого отношения.
Обычно люди, которые громче всех возмущаются медленностью звездочки, почему-то игнорируют кучу других, гораздо более серьезных, неоптимальностей.
У нее есть и достоинство — надежность. Завтра появится новый тег и он точно ничего не поломает.
По производительности там разница настолько копеечная, что видна разве что только в микроскоп. Хотя можно искусственно сгенерировать такой пример, где это станет заметно, но к реальной практике он не будет иметь никакого отношения.
Обычно люди, которые громче всех возмущаются медленностью звездочки, почему-то игнорируют кучу других, гораздо более серьезных, неоптимальностей.
Селектор звездочка применяется КО ВСЕМ без исключения элементам документа.
Вот сколько у вас в документе тегов — он применится ко всем. И это ресурсоемко, в отличие от конкретно заданного класса.
Вопрос — зачем к элементам a, span, b, div применять margin:0;padding:0 когда у них итак это дефолтные значения.
Вот сколько у вас в документе тегов — он применится ко всем. И это ресурсоемко, в отличие от конкретно заданного класса.
Вопрос — зачем к элементам a, span, b, div применять margin:0;padding:0 когда у них итак это дефолтные значения.
Чего только не придумают, лишь бы table не использовать
Вы умеет делать на таблицах responsive-верстку с перестройкой блоков?
Разве имитация таблицы на css не позволяет сделать перестройку блоков?
.block {display: table;}
@media all and (max-width: 1000px) {
.block {display: block;}
}
Можно, но на практике потом больше проблем получаешь с этой кучей плохо управляемых блоков (за исключением очень простых случаев).
Да, поэтому лучше таблицу использовать только когда это действительно таблица. В других случаях как по мне намного лучше flexbox.
Не так уж плохо они управляемы. Главная проблема — если внутри что-то слишком широкое, что может распереть всю конструкцию. Но это в любом случае проблема).
Зато выравнивать произвольное содержимое по вертикали таблицы пока умеют даже лучше флексбоксов:)
Зато выравнивать произвольное содержимое по вертикали таблицы пока умеют даже лучше флексбоксов:)
Баг легко фиксится оборотом текста в див :)
Во-первых, это не баг, а стандартная особенность инструмента. А во-вторых — зачем брать инструмент, которому для решения задачи нужны подпорки в виде допразметки, когда другой инструмент в лёт решает задачу без них? :)
Ну ок, пускай фича. Если ячейки таблицы необходимо будет на другой ширине экрана перестроить, что тогда будете делать с таблицей? :) Все зависит от задачи. И в нашим руках решить как удобнее справится с задачей.
Сменю для этой другой ширины display, в чем проблема. Это ж не разметку менять;)
Это то понятно, но тогда все равно придется решать проблему «прыганья» текста.
Можно сменить как раз на инлайн-блоки, например, тогда не придётся (но придется решать проблему пробелов). Или на флоаты (но придётся их «клирить»). В общем, согласен, что всё зависит от задачи — и именно поэтому полезно знать много разных вариантов и уметь выбирать между ними, не ограничивая себя искусственно.
А кто не умеет? tr, td { display:block } или tr { display:flex; flex-flow: row-wrap } (благо мобильные браузеры сейчас поголовно круче десктопных, никаких IE9- среди них нет:) — и дальше насколько фантазии хватит. А что до смены визуального порядка элементов (особенно вертикального), так в этом таблицам не было равных еще тогда, когда это не было мейнстримом (по старой спеке tfoot в коде писался перед tbody, а выводился после:).
Это на флексах, а не на таблицах. На таблицах — это display: table. А вообще согласная с вами: те кто верстают — все это знают. Поэтому я ничего нового не открываю, а просто привожу пример сетки на inline-block, поскольку подобных готовых решений не нашла.
Прошу прощения, в спешке пытался запихнуть в один коммент два тезиса: 1) даже HTML-таблицу можно адаптировать, 2) и в display:table-* есть свои скрытые резервы типа смены порядка ячеек через direction, перестановки блоков местами через table-header-group/table-footer-group и т.п.
Кстати, вот не тестировал таблицы при writing-mode: tb-* (или как он теперь называется) — наверное, так можно и флексы с flex-direction:column зафолбэчить?
Кстати, вот не тестировал таблицы при writing-mode: tb-* (или как он теперь называется) — наверное, так можно и флексы с flex-direction:column зафолбэчить?
А что на счет проблемы с отступами(пробелами) между инлайн элементами?
Для этого предусмотрены модификаторы grid--g10, grid--v10, grid--gv10. В статье о них написано.
проблем никаких нет, font-size:0 и нет никаких пробелов…
Browser Minimal Font Size и нет никаких font-size: 0. Ниже этого значения перейти нельзя, браузер просто не даст.
в задаче речь не про шрифт, который браузер отобразит или нет,
речь про отступы между инлайн-блоками.
чтобы их не было — ставится font-size:0 родительскому блоку и нет никаких отступов.
речь про отступы между инлайн-блоками.
чтобы их не было — ставится font-size:0 родительскому блоку и нет никаких отступов.
Еще раз: font-size: 0 не сработает, потому что браузер не даст поставить такое свойство и у вас оно будет font-size: 10-12. Есть у вас там символ или нету — побоку, отступ зависит от размера шрифта, который имеет нижнюю границу в браузерах. Эта проблема появилась сразу за появлением сетки на inline-block и ее решили десятками разных хаков.
Уточните, пожалуйста, где вы столкнулись с подобным поведением? Просто font-size: 0 это очень известный и используемый хак. Если бы всё работало именно так, как вы говорите, у таких людей треть сайтов бы кривились. Я пот полез даже поискал где и как такое можно задать в Chrome. Так вот, по дефолту там стоит 6px. И это не мешает использованию font-size: 0. Правда возможно мешает использованию числе >0 но <6
UFO just landed and posted this here
Проверил в Firefox. font-size: 0 работает. Установил ограничение в настройках в 10px, и правда 1-9px не работают. А 0 работает. Текст пропадает. Приведите, пожалуйста, реальные примеры.
UFO just landed and posted this here
Стало быть Firefox вы просто так привели? Ну спасибо. По сабжу:
- Firefox 52
- Safari 10
- Opera 12
Везде font-size: 0 убирает текст. Качать свежую оперу для теста лень.
UFO just landed and posted this here
Настройку то я задал правильную (Preferences — Advanced — Fonts — Minimum font size (pixels). По дефолту стояла 1px. Но вот повторно воспроизвести уже не получается. Более того, в прошлый раз у меня стрекозу не перекосило (незабываемое зрелище), а сейчас перекосило. Вероятно я что-то сделал не так. Так что с аргументом в пользу древней оперы соглашусь.
Chrome, Safari. Последний хром выправлял позавчера.
Вы точно проверяете font-size: 0? У меня и в Safari, и в Chrome всё работает. Ставлю 0 — надпись пропадает. Ставлю >0, но <лимита, надпись размером с лимит.
Да. Это точно font size 0 !important примененный к ul элементу, в котором расположен li-список. Может у вас генерация списка идет без отступов? Или li-тег не закрывается? Или применен какой-либо хак из статьи https://habrahabr.ru/post/137582/? Они часто вмонтированы в всякие движки/ситилзаторы/стандартизаторы.
Вы знаете, я кажется понял о чём вы. Вы несколько раз столкнулись с тем, что font-size: 0 (как и line-height: 0) не привёл к нужному результату в каких то условиях (браузер, ос, устройство и пр.). Я охотно в это верю. Вёрстка на этих двух костылях изначально очень шаткая, даже более шаткая, чем на float-ах. А учитывая, что мобильные браузеры в целом любят издеваться над размером шрифта, пытаясь сделать текст доступнее для пользователя… В общем верю.
НО! Скорее всего, всё это не имеет ни малейшего отношения к настройке минимального размера шрифта в браузере. Просто какая-либо мелочь из рендер движка сыграла на 1px больше-меньше и всё поехало.
> Скорее всего, всё это не имеет ни малейшего отношения к настройке минимального размера шрифта в браузере.
Поверьте это была именно опция минимального шрифта. Для полной радости я ее понизил до нуля и у меня успешно убрались отступы.
Не спорю, я может быть преувеличиваю значимость данного косяка, но если верстаешь под кучу устройств — надо держать такое в голове. Например последнее такое я лечил именно потому что оно всплыло на ведроиде 4.
Поверьте это была именно опция минимального шрифта. Для полной радости я ее понизил до нуля и у меня успешно убрались отступы.
Не спорю, я может быть преувеличиваю значимость данного косяка, но если верстаешь под кучу устройств — надо держать такое в голове. Например последнее такое я лечил именно потому что оно всплыло на ведроиде 4.
Я сталкивался с подобными проблемами когда использовал встроенный в браузер zoom страницы. Немного в другую стороны погрешности вычислений layout-а страницы сыграют и все тонкоподстроенные inline-блоки разлетелись.
Еще раз.
Мы не будем гадать, сколько у этого браузера минималка, мы скажем 0 и он сам нужное применит.
Мы не будем гадать, сколько у этого браузера минималка, мы скажем 0 и он сам нужное применит.
Еще раз: Он вам скажет что ему плевать на ваш выставленный 0, у него стоит «менее 10 нельзя».
Буквально два дня назад переделал верстку присланную дизайнером где был перенос между li-строк и стоял хак с font-size:0. Хром на компе блок сдвигал на 2 пикселя, руководствуясь своим правилам, хром на андроиде (вроде там хром?) сдвигал блок на следующую строку.
Буквально два дня назад переделал верстку присланную дизайнером где был перенос между li-строк и стоял хак с font-size:0. Хром на компе блок сдвигал на 2 пикселя, руководствуясь своим правилам, хром на андроиде (вроде там хром?) сдвигал блок на следующую строку.
и что,
вы им (андроид 4) задали 10px и ваши 2px пропали?
вы им (андроид 4) задали 10px и ваши 2px пропали?
Нет, я применил старый трюк с комментарием между элементами li
ну может дело там ни в font-size, а в чем-то другом, не думали?
Удалил ul {font-size: 0} — ничего не поменялось. Добавил блоки комментария между li тегами — пробелы исчезли. Это уже не первый шаблон, который правлю таким образом, за эти пару лет. Если знаете другую причину — я очень буду рад ее услышать. Пока еще гуглеж на тему font-size: 0 выводит на страницы с жалобами что не все браузеры дают такое.
так вы инспектом проверьте, может что наследуется выше или жестко прописано.
мне тут на днях попадалось «чудо»
.className1.className2.className3.className4 .ul {}
ужас.
мне тут на днях попадалось «чудо»
.className1.className2.className3.className4 .ul {}
ужас.
Подскажите пожалуйста, в каких браузерах вы заметили минимальный размер шрифта > 0?
В лисе и хроме font-size: 0; срабатывает нормально.
В лисе и хроме font-size: 0; срабатывает нормально.
UFO just landed and posted this here
Всё же все эти сетки, по сути, всё тот же table — читай, верстка от того, что на выходе, а не семантика…
вот есть http://colourgarden.net/avalanche/ я не использовал, но думаю в проектах использовать можно если нужнен grid с bem и inline-block
Меня сетка через
Проще на flexbox перейти.
display:inline-block раздражаеи именно из-за надобности делать нулевой размер шрифта у контейнера. Проще на flexbox перейти.
UFO just landed and posted this here
Вы не в курсе проблем с лишними отступами из-за пробелов между элементами?
UFO just landed and posted this here
Все до единого способы костыльные, потому что зависят от каких-то добавочных обстоятельств. Верстка поэтому получается ненадежная.
Даже во времена расцвета inline-block'ов старался избегать этих методов в реальных проектах (применял наверное раза 2, когда совсем деваться некуда было), а уж сегодня-то вообще нет никаких здравых причин это использовать :)
Даже во времена расцвета inline-block'ов старался избегать этих методов в реальных проектах (применял наверное раза 2, когда совсем деваться некуда было), а уж сегодня-то вообще нет никаких здравых причин это использовать :)
А насколько реальна нужна верстка, которая перестраивается в зависимости от размера экрана? Не проще ли сделать дизайн и верстку под 2 (computer & mobile) или под 3 шаблона (computer & pad & mobile)? На практике обычно перестроение всей информации основного сайта в гигантский столбик на мобильном оказывается не нужным
Хочу привести пример применения сетки на float из bootstrap и моей сетки. Например, есть 6 блоков разной высоты (товары в каталоге). На десктопе они должны быть по 6 в ряд, а на мобильной версии по 3.
Решение примера на bootstrap: https://jsfiddle.net/babenkoma/soz98d87/2/
Решение примера на моей сетке: https://jsfiddle.net/babenkoma/a3un7vzw/
Решение примера на bootstrap: https://jsfiddle.net/babenkoma/soz98d87/2/
Решение примера на моей сетке: https://jsfiddle.net/babenkoma/a3un7vzw/
И вот пример на flex: https://jsfiddle.net/babenkoma/rgt42bwf/
Отличается от моей сетки только тем, что аналогичные классы содержат чуть меньше свойств и отсутствием box. Хотя если нужны отступы между элементами, то не всегда без box можно обойтись.
Отличается от моей сетки только тем, что аналогичные классы содержат чуть меньше свойств и отсутствием box. Хотя если нужны отступы между элементами, то не всегда без box можно обойтись.
У вас в коде есть момент который вы никак не описали в статье: inline-block учитывает пробельные симоволы между элементами (в даном случае между .cell). И это влияет на геометрию. Поэтому когда вы задаете ширину в 20% — на самом деле это 20% + пробел. И пять элементов в ряд не станут. Для этого нужно обнулять размер шрифта родителю (что вы и сделали в коде). Этот момент очень критичен для инлайновых сеток, его стоило бы пояснить детально.
Одновременно это хак еще и самый большой минус таких сеток. Потому что никак нельзя использовать наследование размера шрифта и em для колонок.
Если вам нужно поддерживать древние браузеры, то в сетке на инлайнах есть смысл, скорее всего em и rem там тоже не поддерживаются, поэтому минус хака с font-size не критичен.
UFO just landed and posted this here
Костыли, которые завязаны на разметке даже не рассматриваю. Это хрупко и ненадужно
Это неудобно. Но гораздо надёжнее (именно в данном случае), чем font-size. Серьёзно. Увы.
Удалить пробелы надежнее??? Или может не закрыть тег надежнее? Вы серьезно?
Именно удалить пробелы ― надёжнее. Да, я серьёзно. Когда HTML токенайзером разбирается на кусочки в AST он не находит text-ой Node-ы между тегами, и соответственно никакие настройки браузера, никакие тонкости ОС, никакие особенности браузера, пустую область тут уже не породят. Как там было у классиков? "Нет человека — нет проблемы". Так и тут "нет space-а, нет поехавших блоков".
А что вам в этом так удивляет? Вы когда-нибудь писали парсер для HTML? Или ковырялись в результате работы какого-нибудь cherio или whacko? Мне приходилось и то и другое делать. По сути есть 3 вида нод: теги, комментарии и тексты. И тексты обрабатываются очень по разному в зависимости от display-я окружения.
Парсеры не писал и в AST деревьях не ковырялся. Это не мешает мне понимать, почему данный подход работает и почему он существует.
Но сетка, которая зависит от закрытого/незакрытого тега — априори прохой варинт.
А если мне по семантике не подходит использовать li. Что тогда?
@ROBsoer, я рассуждал не о незакрытых <li/>, а о промежутках. Да и с тем, что вёрстка на inline-блоках весьма склизкая, я не могу не согласиться.
Скорее сама сетка для блоков, основанная на том контексте форматирования, в котором форматирование исходника (наличие/отсутствие пробелов) внезапно оказывается значимым — априори плохой вариант.
При малейшей возможности лучше использовать что-то менее костыльное, а такое оставлять разве что на самый крайний фолбэк.
При малейшей возможности лучше использовать что-то менее костыльное, а такое оставлять разве что на самый крайний фолбэк.
UFO just landed and posted this here
UFO just landed and posted this here
можно, а еще можно отрицательны margin. Но я сознательно упустил эти способы, так как они зависят от окружающих условий
Старый — не старый, а до сих пор многие верстают не на флексах. А значит на чем? Или на флоатах или на инлайн-блоках. Я выбираю второе. Честно сказать постепенно перехожу на флексы. Но они не всегда спасают.
А что можно не сверстать на флексах? Как по мне намного гибче и флоатов, и инлайн-блоков.
Например, такое https://jsfiddle.net/babenkoma/a3un7vzw/1/. В одном блоке 4 таба и контейнер для загрузки содержимого. На десктопе табы по средине с отступами, а на мобильном — они по всей ширине и прижаты к бокам. На моей сетке такие манипуляции легко делать. А вот на флексах нужно создавать 2 флекс-контейнера и для каждого на разной ширине задавать разные свойства. А если что поменяется, то придется стили переписывать. А в моем случае просто другой класс пропишется и все.
А что мешает на флексах блоку контейнера добавить необходимые отступы или сделать его какой-то ширины и разместить посередине?
Можно. Я же говорю или писать куча стилей на разных ширинах разные или просто прописать пару классов.
https://jsfiddle.net/cezyjzum/ где тут сложность то? Можно оставить сетку в стороне просто добавив контенту необходимый класс.
Выглядит не так как у меня
http://joxi.ru/E2p17VGh946MGA
http://joxi.ru/YmEal8Xu0Bozwm
Нужно повозится, что бы настроить. А я свой вариант за 3 мин сделала
http://joxi.ru/E2p17VGh946MGA
http://joxi.ru/YmEal8Xu0Bozwm
Нужно повозится, что бы настроить. А я свой вариант за 3 мин сделала
А вообще это вопрос привычки. Простые случаи каждый делает кто как привык. Часто бывает, что и без флексов не обойдешься.
С отрицательным чем-либо нужно точно попасть в размер пробельного символа, до субпикселей. Потому что за эти сто лет хромята исправили один старый баг, научились скукоживать пробелы меньше нуля (с перекрытием блоков) и могут сплющить строку сильнее чем надо, с некрасивым рваным правым краем в результате.
Раз опять наткнулся на эту статью, отпишу тут про находку.
Есть ещё такие способы: https://css-tricks.com/fighting-the-space-between-inline-block-elements/ но каждый из них несёт свои проблемы.
Я нашёл вроде бы безпроблемный:
Есть ещё такие способы: https://css-tricks.com/fighting-the-space-between-inline-block-elements/ но каждый из них несёт свои проблемы.
Я нашёл вроде бы безпроблемный:
ul {
letter-spacing: -1em;
}
ul li {
letter-spacing: 0;
}
Есть еще более обстоятельная статья на русском: http://css-live.ru/articles/zagadochnye-otstupy-mezhdu-inlajn-blokami.html.
Совсем беспроблемных способов "обнуления" пробелов через CSS нет. Вариант с word-spacing: -0.43em, некогда чуть ли не канонический и включенный в кучу уважаемых проектов типа YUI-фреймворка, тоже был беспроблемным… до обновления Хрома до 26-й версии, когда пофиксили баг, на котором он держался. А то, что сейчас пробельные символы при очень большом по модулю отрицательных letter-spacing по-разному «скукоживаются» в зависимости от того, между обычными буквами они или между инлайн-блоками — на чем (пока) держится предложенный хак — как по мне, очень уж смахивает на баг...
Но зачем все эти страдания в 2018 году, когда задача действительно беспроблемно и куда более гибко повсеместно решается флексбоксами?
Нет ничего хуже вот этой каши, уж извините
cell cell--none cell--md8 cell--sm24 cell--center
В названиях классов в вёрстке не должно быть никаких размеров и расположений.
cell cell--none cell--md8 cell--sm24 cell--center
В названиях классов в вёрстке не должно быть никаких размеров и расположений.
Почему?
Мы долго уходили в разделение контента (html) и его оформления (css) для того чтоб не писать a color=#FAA margin=0, но пришли к тому что наш html-код опять стал напичкан всякой ерундой вроде class=«col-right col-w200px col-h100p col-blue ...». Получается что у нас в содержимом зачем-то в очередной раз оформление. Особенно это хорошо видно в БЭМ, где каскадность каскадных таблиц стилей почти послана в далекие дебри.
Потому что в классах наименование должно быть без привязки к размерам, положению и цветам.
Ну вот назовёте вы класс cell-color-blue, пропишите его в двадцати разных файлах, а потом приходит дизайнер и говорит — ребяты, нужно красный. Тут то и начнётся.
Клссс нужно именовать вида cell-date, то есть, по содержимому. Тогда сменить цвет — это один раз изменить в css.
Про размеры и расположение вообще ужас.
И препроцессоры тут не причём. Они используются для другого.
Ну вот назовёте вы класс cell-color-blue, пропишите его в двадцати разных файлах, а потом приходит дизайнер и говорит — ребяты, нужно красный. Тут то и начнётся.
Клссс нужно именовать вида cell-date, то есть, по содержимому. Тогда сменить цвет — это один раз изменить в css.
Про размеры и расположение вообще ужас.
И препроцессоры тут не причём. Они используются для другого.
Меня с самого первого момента появления сеток удручала во float необходимость пользоваться clearfix.
Сетка на inline-block действительно хороша. Большинство тут восклицает о том, что пробельный символ будет мешать и фиксы с размером шрифта не идеальны. Так и есть. Но ведь достаточно просто сжимать html? Если сейчас ещё кто-то не пользуется препроцессорами для html, то уж минификаторы то смогут освоить. И пробельные символы больше никогда не помешают. На фрилансе, конечно, приходится объяснять заказчику, что минификация обязательна. Но из моей практики — никто не возражал и даже радовался тому, что html-ка весит на один-два килобайта меньше.
Единственное, что меня коробит — почему все до сих пор пользуются фиксированным количеством колонок? Один небольшой mixin и можно организовать сетку на дробях. С классами вида: .col-1-2, .col-2-10. Несомненно, классов будет чуть больше, но в целях универсальности и расширяемости это круто, когда ты можешь задать любые пропорции. Частенько радовали ребята, которые брали бутстраповскую сетку на 16 колонок и пытались через неё организовать три равных блока по ширине после того, как в дизайне неожиданно они появились. Извращения с вложениями колонок друг в друга или дополнительные классы с паддингами. Сплошное веселье.
Я пользуюсь чем-то подобным:
Сетка на inline-block действительно хороша. Большинство тут восклицает о том, что пробельный символ будет мешать и фиксы с размером шрифта не идеальны. Так и есть. Но ведь достаточно просто сжимать html? Если сейчас ещё кто-то не пользуется препроцессорами для html, то уж минификаторы то смогут освоить. И пробельные символы больше никогда не помешают. На фрилансе, конечно, приходится объяснять заказчику, что минификация обязательна. Но из моей практики — никто не возражал и даже радовался тому, что html-ка весит на один-два килобайта меньше.
Единственное, что меня коробит — почему все до сих пор пользуются фиксированным количеством колонок? Один небольшой mixin и можно организовать сетку на дробях. С классами вида: .col-1-2, .col-2-10. Несомненно, классов будет чуть больше, но в целях универсальности и расширяемости это круто, когда ты можешь задать любые пропорции. Частенько радовали ребята, которые брали бутстраповскую сетку на 16 колонок и пытались через неё организовать три равных блока по ширине после того, как в дизайне неожиданно они появились. Извращения с вложениями колонок друг в друга или дополнительные классы с паддингами. Сплошное веселье.
Я пользуюсь чем-то подобным:
.row-el
display: block
> [class^='col-']
display: inline-block
vertical-align: top
&.row-middle
> [class^='col-']
vertical-align: middle
.row-el
@for $a from 1 through $column-count
@for $b from 1 through $a
@if $a != $b or ($a == 1 and $b == 1)
$result: 100% / $a * $b
> .col-#{$b}-#{$a}
width: $result
Можно и на дробях сделать. Но я разницы не вижу. Потому как все равно под каждую дробь должен быть класс, также, как и под каждую колонку. Или у вас будет класс col-3-4 или coll-12 (в случае 24-колоночной сетки) — какая разница? Вот если бы можно было как-то брать цифру из названия класса и что бы из нее вычислять ширину… Но на css так не сделаешь.
Но зачем создавать проблемы, где их нет и потом их пытаться решить… Где фиксированное число колонок, возьмите тот же Бутстрап, никто же не обязывает пользоваться 12 колонками, сделайте 15, 23 да сколько угодно, все легко модифицируется
Зачем в который раз изобретать велосипед, не нравятся (не устраивают) готовые сетки фреймворков, возьмите гибкое решение susy ( не реклама) и крутите как хотите… И не совсем понятна логика — нужно знать количество элемtнтов в row, ЗАЧЕМ? Просто у последнего очистите обтекание и все, элементы новой строки, не за что не зацепятся.
Зачем изобретать велосипед? По двум причинам:
1. При этом глубже разбираешься в проблеме, больше узнаешь, короче, полезно для работы и саморазвития
2. Мне лично удобнее использовать то, что сама написала, поскольку я знаю как оно работает и знаю где нужно изменить в случае чего, чем чужой код, который как правило нужно использовать именно так, как написано в документации
1. При этом глубже разбираешься в проблеме, больше узнаешь, короче, полезно для работы и саморазвития
2. Мне лично удобнее использовать то, что сама написала, поскольку я знаю как оно работает и знаю где нужно изменить в случае чего, чем чужой код, который как правило нужно использовать именно так, как написано в документации
1. Совершенно верно, но в таком случае это не должно утекать за границы этого саморазвития.
2. Но тогда вы обрекаете себя на поддержку, а, публикуя такую библиотеку, обрекаете еще и ее потенциальных пользователей на большой геморрой, когда вы поддерживать ее перестанете.
Лучший велосипед — несуществующий.
2. Но тогда вы обрекаете себя на поддержку, а, публикуя такую библиотеку, обрекаете еще и ее потенциальных пользователей на большой геморрой, когда вы поддерживать ее перестанете.
Лучший велосипед — несуществующий.
del
Sign up to leave a comment.
Новая сетка на inline-block: описание, пример использования, плюсы и минусы