Как стать автором
Обновить

Комментарии 52

Не хватает объяснения, почему так сделано. Все объяснения, что приведены в статье, сводятся к «потому что так написано в спецификации». Но почему там написано именно так?

Потому что стандарт складывался стихийно. Никто из тех, кто внёс в него вклад, не давал себе труда сесть и подумать, какие сценарии чаще всего стоят перед большинством разработчиков и как их закрыть наиболее простым и оптимальным способом.
Эти люди просто решали свои мелкие частные проблемки наиболее простым костыльным способом. Вот потребовалось кому-то в недрах Google, работая над их сервисами, вычислять какое-либо расстояние в пикселях — и в стандарт добавляется соответствующий костыль.
В итоге весь набор стандартов HTML/CSS представляет собой лютейшее нагромождение костылей, в котором даже простые способы разместить DIV по центру экрана появились только с внедрением Flex, и то грабли неочевидного поведения торчат во все стороны. Притом что все форумы, а потом и весь Stack Overflow были забиты вопросами вида "а как мне отцентрировать DIV, оно не работает!". Но никто из разработчиков стандарта никогда и не пытался сделать хоть что-то удобное для массового верстальщика. Всё это делалось для собственных же внутренних фронтэндеров, причём без системного подхода, а путём одномоментного затыкания костылями особо крупных дыр.

Я бы с вами согласился, веди мы эту дискуссию в 2000-х, ну хорошо, в 2010-х. Но сегодня уже 2023 год на дворе. grid'ы и flex'ы — остриё прогресса, призванное как раз решить все эти проблемы без добавления костылей (я хорошо помню дифирамбы этим технологиям, когда они только появлялись — «ух, теперь-то заживём» при появлении flex'а и «ух, теперь-то в меду кататься будем» при появлении следом за ним grid'а). Откуда опять всё это безобразие с неочевидными поведениями повылезало?!

А как сейчас в 2023 отцентрировать див в котором есть переносы, чтобы его не растянуло на всю ширину контейнера?

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

Переносы происходят там, где контент не влезает. Но это не повод прижимать контент к левому краю, вместо центрирования.

эм... задать ему ширину, не?)) какое вам вообще дело до переносов - этим занимаются другие css-свойства (и да, вопросы с переносами тоже решаемы)

более того, даже абсолютно пустой див растянется на всю ширину родителя))

Ширина зависит от объёма контента, введённого пользователем.

нет.

если быть совсем точным - далеко не всегда.

а если говорить о современном css, то ваши претензии вообще не выдерживают никакой критики:

https://developer.mozilla.org/en-US/docs/Web/CSS/min-content

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

Есть базовая дизайнерская задача: расположить текстовый блок по центру. Произвольный контент и размер контейнера. При переносе выключка влево.

Пока переносов нет, всё хорошо. Как только появляются переносы, центрирование пропадает и всё прижимается к левому краю.

И подобных детских болезней в CSS вагон, а лечить их никто даже не собирается. Странно, что за 12 лет вы с ними не столкнулись.

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

Вы бы не гнули пальцы перед более опытными товарищами (давайте хотя бы даты регистрации сравним), а научились нормально формулировать задачи!

Я до сих пор не понимаю с чем у вас проблема... Вернее я даже вашу задачу пока в голове представить не могу (это талант надо иметь, описать простейшую задачу таким витиеватым и непонятным образом - дизайнер?). Если вы отключите переносы - у вас блок превратится в одну длинную строку. У вас проблема с центрированием этой строки?))

И что вот это такое "При переносе выключка влево."? Как вы эту дичь себе представляете? text-align-last?))

Если вы включите переносы, то браузер расставит переносы в тех местах где текст... не вписывается в ширину блока. А напомнить чему у нас равна ширина? Произвольный контент и размер контейнера.

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

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

И подобных детских болезней в CSS вагон, а лечить их никто даже не собирается.

Ложь! Не только собираются, но и давно лечат. Иначе бы вы до сих пор центрировали блоки по высоте через vertical-align. Или что, для кого-то сейчас вертикальное выравнивание в CSS является проблемой?))

А что за $mol? Никогда такой жести в продакшене не видел. Почему вы решили продемонстрировать поведение голого HTML+CSS, обмазав его лишней прослойкой? (o)_(O)

Это самая легковесная песочница просто.

text-align: center;

Мда, более опытный товарищ не знает про text-align. Бывает.

Если добавить `text-align: center;` напрямую в DOM через DevTools, то вполне себе центруется. Всё-таки HTML/CSS/JS - это базовые технологии для веба. Остальное, включая Tree - преобразовывается к этим трём. Наверное где-то преобразование споткнулось.

н
н

У вас выключка сломалась.

Мы знаем что такое выключка (как трогательно видеть полиграфические термины в 2023 применительно к вебу). Мы до сих пор не можем понять, что вы хотите получить в итоге???

Вы либо выравниваете текст по центру, либо по левому краю. Как вы это хотите совместить? Или я реально попал в точку с text-align-last?))

Ну или нарисуйте что ли...

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

Ваш текст изначально был "выключен" по левому краю. Размер родительского элемента в вашем примере 300px. Слова "отцентрирован", "распидарасило", "обескураживает" и "иррациональная" просто длиннее, чем свободное место на предыдущей строке. Я изменил размер родительского элемента, поставив 325px, и стало вот так:

Поставьте word-break: break-all; и будем вам и центровка, и выключка, и полное обалдевание пользователей от переносов:

А зачем вы

margin: auto;

прописали?))

Это вы типа так выравниваете, а "болезный css" не хочет как надо работать?))

Так это и не должно работать)) Читайте почему - прямо в этом же блоге)) https://habr.com/ru/companies/ruvds/articles/494716/

Что-то у вас матчасть совсем гуляет - подтянуть бы надо, прежде чем технологии обвинять))

Забавно, что в той статье как раз и объясняется, почему это работает.

Разве внутренним фронтендерам никогда не требовалось центрировать div?

Это слишком просто!

Не может фронтендер, попавший в Гугл, заниматься такой банальщиной!

Ну вот кто это плюсует? И где! Мать твою, на Хабре... "Пропал Калабуховский дом..."(с)

Стандарт складывался не стихийно, а максимально продуманно и системно, насколько вообще можно было в таких условиях (когда у вас в "одной эпохе стандарта" браузеры с разницей в возрасте в 10 лет!)...

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

Во-вторых, причём здесь Гугл? Ну т.е. он причём, конечно. Но он далеко не один был. И в те времена о которых вы ведёте речь - он был далеко не самым главным участником этого "кружка по интересам".

В-третьих, да - в CSS была куча проблем. Вот это бесячее вертикальное центрирование. Inline-block для адекватного отображения требовал форматировать html-код. Masonry-лэйаут не реализован до сих пор, а Columns до сих пор слишком глючный.

Но в итоге то, во что вырос CSS - это эталон того, как должен развиваться годный ЯП. Из него выбросили весь мусор, ему упростили синтаксис, по итогу добавили такое количество фич и возможностей... Актуальный CSS3 и CSS2.1 даже 10-летней давности - это небо и земля. Большая часть того, для чего 10 лет назад требовалось подключать jQuery, сейчас реализуется несколькими строчками в CSS.

Современный CSS - это самый мощный инструмент управления представлением, какой только можно представить! Я немного в курсе того, как обстоят дела с интерфейсами в каком-нибудь Android или десктопах... И меня интересует лишь один вопрос - как скоро CSS интегрируют во все информационные технологии, как дефолтный инструмент для построения интерфейсов. У него для этого уже есть всё необходимое! Рядом просто не лежит даже ничего...

И вообще, я как специалист, который постоянно использовал CSS последние лет 12, хочу только выразить огромную благодарность всем причастным к созданию современного CSS. Это однозначный вин!

Во-первых, ...

Просто громкие ничем не подкреплённые слова.

Во-вторых, ...

Вы сами ответили причём. Про то что Google был один ничего не говорилось. Подмена тезиса.

В-третьих, да - в CSS была куча проблем...

Но они никуда и не делись, как вы сами и пишите.

CSS - это эталон того, как должен развиваться годный ЯП.

Тоже громкие ничем не подкреплённые слова. Я могу смело предложить парочку других языков в роли эталона.

Из него выбросили весь мусор

Куда выбросили? Обратной совместимости нет?

ему упростили синтаксис, по итогу добавили такое количество фич и возможностей...

Вот это и пугает. Награмождение костылей на все случаи жизни != эталон ЯП.

Современный CSS - это самый мощный инструмент управления представлением, какой только можно представить!

Смотри про костыли выше.

как скоро CSS интегрируют во все информационные технологии, как дефолтный инструмент для построения интерфейсов

Спасибо, не надо.

Пфф...

Просто громкие ничем не подкреплённые слова.

Ничуть не менее подкрепленные и более громкие, чем тезисы из исходного коммента.

И чтобы сразу вопрос закрыть - а какую фактологию вы подразумеваете для подкрепления моих слов? Ну вот CSS, например, живее всех живых, как технология. Это разве не показатель успешной работы W3C?

 Про то что Google был один ничего не говорилось. Подмена тезиса.

Ничего и не говорилось про то, что он был не один. В любом случае, единственное на что мы можем опираться - там точно был Гугл))

Ну раз уж из всех участников по имени назван именно Гугл - мне показалось вполне логичным немного уточнить факты (а то человеку не в теме может показаться что во всем "виноват" именно Гугл). Так что подменой тезисов занимаетесь скорее вы ;)

Но они никуда и не делись, как вы сами и пишите.

Ещё как делись! Вертикальное выравнивание работает)) 3-пиксельный баг в IE/Edge пропал)) Что вам ещё надо?

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

Тоже громкие ничем не подкреплённые слова. Я могу смело предложить парочку других языков в роли эталона.

Вы пока не сказали вообще ничего конкретного, а просто занимаетесь демагогией и душниловом ;) Это к вопросу о подкрепленных словах))

И не надо пугать заранее - предлагайте)) Только в более подходящем треде - у нас тут всё-таки о CSS речь.

Куда выбросили? Обратной совместимости нет?

На свалку истории. Есть.

Вот это и пугает. Награмождение костылей на все случаи жизни != эталон ЯП.

Ложь и передёргивание!

ему упростили синтаксис, по итогу добавили такое количество фич и возможностей != Нагромождение костылей на все случаи жизни

Смотри про костыли выше.

И чё? Вбросили про костыли (причём как будто бы приписав эти слова мне - жирновато). Куда смотреть?

Спасибо, не надо.

Боюсь вашим мнением на этот счёт никто не поинтересуется.

Не у всех было 12 лет на изучение CSS, вот в чем проблема.

не плохое объяснение.

помойму так в CSS накрутили всякого, слишком много чего не надо было бы. из стилей превратили его в чуть ли в недоязык программирования, в итоге есть какие-то разрозненые свойства которые выполяют точечно какую-то задача и имеют кучу оговорок.

если для элемента указано свойство transform со значением отличного от none, то все его дочерние элементы с position: fixed будут использовать его, как containing block. Таким образом — они перестают быть „зафиксированными“.

вообще убило.

"Это не правильно, мы должны разработать стандарт, который подойдёт всем!" :)

Классика уже.

Побуду адвокатом дьявола и скажу, что CSS - это очень логичный язык. Главное - это идти от основ и смотреть на него как обычный человек с житейской логикой.

У нас есть блоки и инлайны. Блоки - с контролируемым размером, инлайны - с размером, который получается по остаточному принципу. Какой получился, такой и есть. Появляется новый инструмент - flex, который контролирует детей. Вопрос - дети должны быть с контролируемым размером, или нет? Очевидно, что они должны должны быть с контролируемым размером, чтобы его контролировать. Иначе ничего не получится.

Дальше. Calc. Сколько будет 1кг + 2кг? Будет 3кг. Мы можем складывать значения в одних единицах измерения. Сколько будет 1кг + 10? Будет 1кг + 10. Комплексное значение, которое не может быть использовано как мера веса. Мы можем сложить углы в градусах и радианах, потому что эти единицы конвертируются друг в друга. И результат сможем конвертировать или в градусы или в радианы. Но сложим градусы и килограммы - и получим комплексное значение, которое не конвертируется обратно ни в одно, ни в другое. Почему бы нам от CSS ожидать умения конвертировать неконвертируемое? Почему CSS должен делить градусы на килограммы и складывать мили с литрами?

Дальше. Ширина. Есть все те же блоки и инлайны. Если там нет контента, то и ширины может не быть. И минимальной ширины тоже. Ничего не будет. Все схлопнется. А auto - это "на усмотрение браузера". Браузер должен определиться, во что разрешить это auto. Если у элементов может не быть ширины - то пусть будет минимальная ширина в 0px. Довольно топорная логика. Дальше у нас появляется новый инструмент - гриды. А гриды это про что? Правильно, про то, чтобы контролировать детей и задавать им размеры по всякому вне зависимости от контента. Они не должны схлопываться в 0, даже если пустые. В этом смысл гридов. Если все размеры рассчитываются на лету, и в 0 схлопнуть нельзя, то браузер не может их изначально определить. Остается auto до тех пор, пока страница не будет рендериться и не станет понятно, какого на самом деле размера там все делать.

Дальше. Position fixed. Когда-то давно у нас вроде как был один контейнер - окно браузера. Но потом появились инструменты вроде transform или contain, которые создают новые контейнеры для независимого от остальной страницы рендеринга элементов. Но если какая-то часть страницы вырвана из нее, существует независимо, в своем контейнере, и ничего не знает об окружении, то как можно что-то расположить относительно окружения? Никак. Так что fixed все еще работает относительно контейнера, но мы можем иметь много этих самых контейнеров.

смотреть на него как обычный человек с житейской логикой.

может в этом тогда и проблема, потому что

Дальше. Ширина. Есть все те же блоки и инлайны. Если там нет контента, то и ширины может не быть. И минимальной ширины тоже.

вообще не вижу связи между наличием или отсуствием контента внутри блока и наличием или отсуствием ширины у блока. абсолютно несвязанные сущности в моëм понимание.

p.s. кажется мне только что пришло понимание почему существуют шутки про фронтенд и бэкэнд.

Возможно автор поста привык, что в препроцессоре сложение выполняется с указанием единицы измерения лишь у одного суммируемого, и ждёт подобного от css.

На счёт последнего пункта про transition transform + fixed. Наконец-то, спустя 2 года, я узнал почему та боковая менюшка таким образом "глючила". Воистину CSS is awesome.

Что-то как-то крайне сумбурно и вырвано из контекста. Тут разговор надо начинать с самых азов css. Начинать не с transform, а с понятий нормального потока, позиционирования и т.п.

По поводу единиц измерения. Даже если их проставлять - есть шансы нарваться на "нежданчик")) Никогда не сталкивались с непонятным поведением "0%"?

Хорошо когда есть bootstrap или аналоги со своей удобной grid системой.

Тот кто верстал HTML/CSS еще в конце 90х -- не читают стандартов. Все равно стандарты никто не соблюдает. Так что пробуем, смотрим что получается и вырабатываем свои эвристические методы... ну и, как результат, не можем пройти такие собеседования, несмотря на 25-летний опыт в веб... :)) :(

В HTML5 нужно было добавить не семантические тэги, а контейнеры компоновки border-layout, grid-layout, stack-layout. Вот тогда бы зажили.

Это не в HTML5 должны были добавить, а в CSS, чтобы он имел полноценные механизмы формирования дерева рендеринга. У него уже есть зачатки этого в виде псевдоэлементов. Дальнейшим развитием этого был XSL-FO, но его закопали и откатились к прогрессивному CSS

про "CSS сбил вас с толку" - так и не понял, почему position: sticky (в случае, когда хочется вертикально заклеить элемент), зачем-то связано с overflow-x у родителей.

К моему удивлению — этот код не работал. Открыв стандарт CSS Values and Units Module Level 3, я нашёл уточнение. При использовании математической функции calc() для свойства со значением типа <length>0 без единицы измерения не поддерживается.

Поддерживается. Если использовать его как множитель, а не как слагаемое.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий