У CSS много моментов, которые сбивают с толку. Разработчики плюются от него. А мне нравится CSS, несмотря на мои потраченные нервы. Подумав, как помочь другим меньше мучаться, я собрал ряд неочевидных моментов. Они сбивали с толку меня и моих знакомых. Надеюсь, вам будет полезно.
▍ Свойство display
Однажды на собеседовании мне задали вопрос: «Какое значение свойства display у элемента с классом child будет во вкладке Computed в DevTools?»
<div class="parent">
<span class="child">Я дочерний элемент внутри родителя с display: flex</span>
</div>
.parent {
display: flex;
}
.child {
display: inline-grid; /* какое итоговое значение свойства display будет здесь? */
}
Если вы думаете, что inline-grid, то вы попались на удочку, как и я. Нет, это не правильный ответ. Правильный ответ — grid.
Данный ответ обоснован тем, что после добавления display: flex к элементу, браузеры сделают проверку значения для свойства display у его дочерних элементов.
Если используются значения inline, inline-block, inline-flex, inline-grid или inline-table, то они трансформируются. Значение inline и inline-block в block, inline-flex в flex, inline-grid в grid и inline-table в table.
По этой причине мы увидим grid во вкладке Computed в DevTools.
.parent {
display: flex;
}
.child {
display: inline-grid; /* Здесь будет значение grid, а не inline-grid */
}
Также мне сказали, что точно такое же поведение есть при использовании значений grid, inline-grid и inline-flex:
<div class="parent-grid">
<span class="child">Я дочерний элемент внутри родителя с display: grid</span>
</div>
<div class="parent-inline-grid">
<span class="child">Я дочерний элемент внутри родителя с display: inline-grid</span>
</div>
<div class="parent-inline-flex">
<span class="child">Я дочерний элемент внутри родителя с display: inline-flex</span>
</div>
.parent-grid {
display: grid;
}
.parent-inline-grid {
display: inline-grid;
}
.parent-inline-flex {
display: inline-flex;
}
.child {
display: inline-flex; /* Во всех случаях здесь будет значение flex, а не inline-flex */
}
После собеседования, я попытался найти объяснение этому процессу. Ответ был в стандартах CSS Flexible Box Layout Module Level 1 и CSS Grid Layout Module Level 1.
В них говорится, что значение свойства display у дочерних элементов внутри флекс-контейнера и грид-контейнера становится blockified, т.е inline-* значение трансформируется, как мне сказали на собеседовании.
Получается, я долгое время делал ошибку, определяв display: block для псевдо-элемента ::before или ::after, находящегося внутри элемента с display: flex:
.parent {
display: flex
}
.parent::before {
content: "";
display: block;
width: 1rem;
height: 1rem;
background-color: mediumspringgreen;
}
По умолчанию для псевдо-элементов ::before и ::after значение свойства display установлено, как inline. Для таких элементов браузеры не могут задать размеры с помощью свойств width и height, поэтому я объявлял display: block.
Во вкладке Computed в DevTools я видел display: block, но это не тот display: block, которые я устанавливал. Браузеры сами добавили display: block.
Удалив его из кода, я убедился, что изменений нет.
.parent {
display: flex
}
.parent::before {
content: "";
width: 1rem;
height: 1rem;
background-color: mediumspringgreen;
}
На этом я не остановился. Начав гуглить про свойство display, я увидел, что есть ещё ситуация, когда браузеры мухлюют с ним. Давайте рассмотрим следующий фрагмент кода:
.parent::before {
content: "";
display: block;
background-color: mediumspringgreen;
position: absolute;
inset: 0;
}
Догадались, какое свойство можно удалить? Конечно, свойство display. Браузеры делают проверку значения свойства display у элемента, если при объявлении свойства position используется значение absolute или fixed.
Согласно таблице описанной в стандарте значение inline,inline-block или любое из table-*трансформируется в значение block, а inline-table в table. Значений inline-flex и inline-grid нет в стандарте, но я проверил их вручную. Результат — они изменяются на flex и grid.
Вернусь к коду и удалю display: block.
.parent::before {
content: "";
background-color: mediumspringgreen;
position: absolute;
inset: 0;
}
▍ Математическая функция calc()
У меня есть привычка не писать единицы измерения вместе с 0. Однажды мне нужно было использовать математическую функцию calc() для вычисления ширины элемента следующим образом:
:root {
--default-gap: 1rem;
}
.container {
width: calc(0 + var(--default-gap));
}
К моему удивлению — этот код не работал. Открыв стандарт CSS Values and Units Module Level 3, я нашёл уточнение. При использовании математической функции calc() для свойства со значением типа <length>, 0 без единицы измерения не поддерживается.
Здесь, как мне кажется, нужно пояснить. В функции можно использовать несколько типов значений:
-
<integer>— число, состоящие из одной или несколько цифр в диапазоне от 0 до 9. Перед первой цифрой может быть установлен знак — или +; -
<number>— число как<integer>, но может быть записано с помощью экспоненциальной формы записи; -
<length>— тип для измерения дистанции, который является числом с единицей измерения.
Вернусь к примеру. Браузеры не могут понять, что 0 без единицы измерения используется как тип <length>. Нужно исправить:
:root {
--default-gap: 1rem;
}
.container {
width: calc(0px + var(--default-gap));
}
Ещё в стандарте есть неочевидные требования, которые следует помнить при работе с calc(). Так, при сложении и вычитании оба аргумента должны быть либо одного типа, либо один из аргументов должен быть типом <number>, а другой <integer>.
Соответственно, если используется один аргумент типом <length>, а другой <integer> или <number>, то будет ошибка.
/* правильный пример */
.container {
width: calc(1000px + 3rem);
opacity: calc(0.5 + 0.35);
z-index: calc(1E2 + 1);
}
.container {
width: calc(1000px - 3rem);
opacity: calc(0.5 - 0.35);
z-index: calc(1E2 - 1);
}
/* неправильный пример */
.container {
width: calc(1000px + 32);
height: calc(1000px + 1E1);
}
.container {
width: calc(1000px - 32);
height: calc(1000px - 1E1);
}
При умножении и делении один из аргументов обязательно должен быть типом <integer> или <number>. Если оба аргумента являются типом <length>, то будет ошибка. При делении, если правый аргумент является типом <integer>, то браузеры трансформируют его в тип <number>.
/* правильный пример */
.container {
width: calc(10px * 1E1);
height: calc(100px * 2);
opacity: calc(0.25 * 2);
z-index: calc(1E2 * 1E1);
}
.container {
width: calc(900px / 3E1);
height: calc(100px / 2);
opacity: calc(1 / 2);
z-index: calc(1E2 / 1E1);
}
/* неправильный пример */
.container {
width: calc(1000px * 10px);
}
.container {
width: calc(60000px / 6px);
}
▍ Свойство min-width
Однажды мой ученик сделал демку и задал мне вопрос: «Почему в devTools у элемента с классом container у свойства min-width установлено значение 0, а у элемента с классом content — auto?
<body>
<div class="container">
<div class="content">здесь какой-то контент</div>
</div>
</body>
.container {
display: grid;
}
.content {
box-sizing: border-box;
max-width: 100rem;
padding-inline: 1rem;
}
В стандарте CSS Box Sizing Module Level 3 сказано, что у свойства min-width есть значение по умолчанию auto. Так почему мы видим 0? В разделе описания допустимых значений для свойства есть пояснение.
Браузеры преобразуют значение auto в 0, если для родительского элемента определено свойство display со значениями block, inline, inline-block, table или со всеми table-* значениями.
В примере элемент div с классом container находится внутри элемента body, у которого по умолчанию установлено display: block. По этой причине браузеры неявно устанавливают значение 0 для свойства min-width. А элемент с классом content находится внутри элемента container c display: grid, поэтому в devTools мы увидим уже min-width: auto.
▍ Свойство position и значение fixed
Вы знали, что есть несколько случаев, когда элемент с position: fixed не будет зафиксированным на экране, а его размеры не будут рассчитаны от вьюпорта? Например, как в следующем коде:
.demo {
width: 300px;
height: 200px;
background-color: mediumspringgreen;
transform: translate3d(0, 0, 0);
}
.demo::before {
content: "";
width: 50%;
height: 50%;
background-color: lightgoldenrodyellow;
position: fixed;
top: 1rem;
right: 1rem;
}
Для понимания причины такого поведения нужно вспомнить, что у каждого элемента есть родительская область относительно, которой рассчитываются размеры и позиция дочернего элемента. В стандарте CSS Display Module Level 3 ей дали название containing block. У элемента с position: fixed такой областью обычно является вьюпорт.
А теперь самое интересное. Существует ряд свойств, которые влияют на определение такой области. В частности свойство transform. В стандарте CSS Transforms Module Level 1 сказано, что если для элемента указано свойство transform со значением отличного от none, то все его дочерние элементы с position: fixed будут использовать его, как containing block. Таким образом — они перестают быть „зафиксированными“.
Именно это произошло в моём примере. Определив transform: translate3d(0, 0, 0) для элемента .demo, я изменил область расчётов позиции и размеров у псевдо-элемента .demo::before.
.demo {
width: 300px;
height: 200px;
background-color: mediumspringgreen;
transform: translate3d(0, 0, 0);
}
.demo::before {
content: "";
width: 50%; /* здесь итоговое значение будет 150px, а не половина ширины вьюпорта */
height: 50%; /* здесь итоговое значение будет 100px, а не половина высоты вьюпорта */
background-color: lightgoldenrodyellow;
position: fixed;
top: 1rem;
right: 1rem;
}
Кроме свойства transform также влияют:
- свойства
perspective,backdrop-filterиfilterсо всеми значениями, кромеnone; - свойство
containсо значениямиlayout,paint,strictиcontent; - свойство
will-changeсо значениямиtransform,filterиbackdrop-filter.
▍ Вместо заключения
А какие у вас были случаи, когда CSS сбил вас с толку? Делитесь в комментариях. Наберём на новую статью! Спасибо.
Выиграй телескоп и другие призы в космическом квизе от RUVDS. Поехали? ????
Комментарии (51)
sfi0zy
18.07.2023 14:34+21Побуду адвокатом дьявола и скажу, что CSS - это очень логичный язык. Главное - это идти от основ и смотреть на него как обычный человек с житейской логикой.
У нас есть блоки и инлайны. Блоки - с контролируемым размером, инлайны - с размером, который получается по остаточному принципу. Какой получился, такой и есть. Появляется новый инструмент - flex, который контролирует детей. Вопрос - дети должны быть с контролируемым размером, или нет? Очевидно, что они должны должны быть с контролируемым размером, чтобы его контролировать. Иначе ничего не получится.
Дальше. Calc. Сколько будет 1кг + 2кг? Будет 3кг. Мы можем складывать значения в одних единицах измерения. Сколько будет 1кг + 10? Будет 1кг + 10. Комплексное значение, которое не может быть использовано как мера веса. Мы можем сложить углы в градусах и радианах, потому что эти единицы конвертируются друг в друга. И результат сможем конвертировать или в градусы или в радианы. Но сложим градусы и килограммы - и получим комплексное значение, которое не конвертируется обратно ни в одно, ни в другое. Почему бы нам от CSS ожидать умения конвертировать неконвертируемое? Почему CSS должен делить градусы на килограммы и складывать мили с литрами?
Дальше. Ширина. Есть все те же блоки и инлайны. Если там нет контента, то и ширины может не быть. И минимальной ширины тоже. Ничего не будет. Все схлопнется. А auto - это "на усмотрение браузера". Браузер должен определиться, во что разрешить это auto. Если у элементов может не быть ширины - то пусть будет минимальная ширина в 0px. Довольно топорная логика. Дальше у нас появляется новый инструмент - гриды. А гриды это про что? Правильно, про то, чтобы контролировать детей и задавать им размеры по всякому вне зависимости от контента. Они не должны схлопываться в 0, даже если пустые. В этом смысл гридов. Если все размеры рассчитываются на лету, и в 0 схлопнуть нельзя, то браузер не может их изначально определить. Остается auto до тех пор, пока страница не будет рендериться и не станет понятно, какого на самом деле размера там все делать.
Дальше. Position fixed. Когда-то давно у нас вроде как был один контейнер - окно браузера. Но потом появились инструменты вроде transform или contain, которые создают новые контейнеры для независимого от остальной страницы рендеринга элементов. Но если какая-то часть страницы вырвана из нее, существует независимо, в своем контейнере, и ничего не знает об окружении, то как можно что-то расположить относительно окружения? Никак. Так что fixed все еще работает относительно контейнера, но мы можем иметь много этих самых контейнеров.
FoxWMulder
18.07.2023 14:34+1смотреть на него как обычный человек с житейской логикой.
может в этом тогда и проблема, потому что
Дальше. Ширина. Есть все те же блоки и инлайны. Если там нет контента, то и ширины может не быть. И минимальной ширины тоже.
вообще не вижу связи между наличием или отсуствием контента внутри блока и наличием или отсуствием ширины у блока. абсолютно несвязанные сущности в моëм понимание.
p.s. кажется мне только что пришло понимание почему существуют шутки про фронтенд и бэкэнд.
wadowad
18.07.2023 14:34Возможно автор поста привык, что в препроцессоре сложение выполняется с указанием единицы измерения лишь у одного суммируемого, и ждёт подобного от css.
orekh
18.07.2023 14:34+2На счёт последнего пункта про transition transform + fixed. Наконец-то, спустя 2 года, я узнал почему та боковая менюшка таким образом "глючила". Воистину CSS is awesome.
Spaceoddity
18.07.2023 14:34+2Что-то как-то крайне сумбурно и вырвано из контекста. Тут разговор надо начинать с самых азов css. Начинать не с transform, а с понятий нормального потока, позиционирования и т.п.
По поводу единиц измерения. Даже если их проставлять - есть шансы нарваться на "нежданчик")) Никогда не сталкивались с непонятным поведением "0%"?
Sergei_Erjemin
18.07.2023 14:34+10Тот кто верстал HTML/CSS еще в конце 90х -- не читают стандартов. Все равно стандарты никто не соблюдает. Так что пробуем, смотрим что получается и вырабатываем свои эвристические методы... ну и, как результат, не можем пройти такие собеседования, несмотря на 25-летний опыт в веб... :)) :(
SWATOPLUS
18.07.2023 14:34+4В HTML5 нужно было добавить не семантические тэги, а контейнеры компоновки border-layout, grid-layout, stack-layout. Вот тогда бы зажили.
Mingun
Не хватает объяснения, почему так сделано. Все объяснения, что приведены в статье, сводятся к «потому что так написано в спецификации». Но почему там написано именно так?
Alexey2005
Потому что стандарт складывался стихийно. Никто из тех, кто внёс в него вклад, не давал себе труда сесть и подумать, какие сценарии чаще всего стоят перед большинством разработчиков и как их закрыть наиболее простым и оптимальным способом.
Эти люди просто решали свои мелкие частные проблемки наиболее простым костыльным способом. Вот потребовалось кому-то в недрах Google, работая над их сервисами, вычислять какое-либо расстояние в пикселях — и в стандарт добавляется соответствующий костыль.
В итоге весь набор стандартов HTML/CSS представляет собой лютейшее нагромождение костылей, в котором даже простые способы разместить DIV по центру экрана появились только с внедрением Flex, и то грабли неочевидного поведения торчат во все стороны. Притом что все форумы, а потом и весь Stack Overflow были забиты вопросами вида "а как мне отцентрировать DIV, оно не работает!". Но никто из разработчиков стандарта никогда и не пытался сделать хоть что-то удобное для массового верстальщика. Всё это делалось для собственных же внутренних фронтэндеров, причём без системного подхода, а путём одномоментного затыкания костылями особо крупных дыр.
Mingun
Я бы с вами согласился, веди мы эту дискуссию в 2000-х, ну хорошо, в 2010-х. Но сегодня уже 2023 год на дворе. grid'ы и flex'ы — остриё прогресса, призванное как раз решить все эти проблемы без добавления костылей (я хорошо помню дифирамбы этим технологиям, когда они только появлялись — «ух, теперь-то заживём» при появлении flex'а и «ух, теперь-то в меду кататься будем» при появлении следом за ним grid'а). Откуда опять всё это безобразие с неочевидными поведениями повылезало?!
nin-jin
А как сейчас в 2023 отцентрировать див в котором есть переносы, чтобы его не растянуло на всю ширину контейнера?
Format-X22
Переносы ведь ставятся там где предполагается конец и переход на следующую строку? Получается конец заранее известен, иначе там не было бы переноса. Значит нужно просто указать ширину этому диву по размеру конца, если я правильно вас понял.
nin-jin
Переносы происходят там, где контент не влезает. Но это не повод прижимать контент к левому краю, вместо центрирования.
Spaceoddity
эм... задать ему ширину, не?)) какое вам вообще дело до переносов - этим занимаются другие css-свойства (и да, вопросы с переносами тоже решаемы)
более того, даже абсолютно пустой див растянется на всю ширину родителя))
nin-jin
Ширина зависит от объёма контента, введённого пользователем.
Spaceoddity
нет.
если быть совсем точным - далеко не всегда.
а если говорить о современном css, то ваши претензии вообще не выдерживают никакой критики:
https://developer.mozilla.org/en-US/docs/Web/CSS/min-content
nin-jin
Вы бы не выпендривались неуместными ссылками на документацию, а послушали, что вам говорят более опытные товарищи.
Есть базовая дизайнерская задача: расположить текстовый блок по центру. Произвольный контент и размер контейнера. При переносе выключка влево.
Пока переносов нет, всё хорошо. Как только появляются переносы, центрирование пропадает и всё прижимается к левому краю.
И подобных детских болезней в CSS вагон, а лечить их никто даже не собирается. Странно, что за 12 лет вы с ними не столкнулись.
Spaceoddity
Вы бы не гнули пальцы перед более опытными товарищами (давайте хотя бы даты регистрации сравним), а научились нормально формулировать задачи!
Я до сих пор не понимаю с чем у вас проблема... Вернее я даже вашу задачу пока в голове представить не могу (это талант надо иметь, описать простейшую задачу таким витиеватым и непонятным образом - дизайнер?). Если вы отключите переносы - у вас блок превратится в одну длинную строку. У вас проблема с центрированием этой строки?))
И что вот это такое "При переносе выключка влево."? Как вы эту дичь себе представляете? text-align-last?))
Если вы включите переносы, то браузер расставит переносы в тех местах где текст... не вписывается в ширину блока. А напомнить чему у нас равна ширина? Произвольный контент и размер контейнера.
У вас там не должно быть переносов в принципе, поскольку вы ширину блока не ограничили.
Так что простите, но я уж посомневаюсь в вашей компетенции. Вы даже не понимаете что вы собрались реализовывать)) Какое визуальное представление может иметь ваша задача. А уже технологию (которую вы, очевидно, применяете не по назначению) успели грязью облить))
Ложь! Не только собираются, но и давно лечат. Иначе бы вы до сих пор центрировали блоки по высоте через vertical-align. Или что, для кого-то сейчас вертикальное выравнивание в CSS является проблемой?))
nin-jin
Вы только полюбуйтесь на CSS центрирование:
Newbilius
А что за $mol? Никогда такой жести в продакшене не видел. Почему вы решили продемонстрировать поведение голого HTML+CSS, обмазав его лишней прослойкой? (o)_(O)
nin-jin
Это самая легковесная песочница просто.
EvilFox
text-align: center;Sayonji
Мда, более опытный товарищ не знает про text-align. Бывает.
flancer
Если добавить `text-align: center;` напрямую в DOM через DevTools, то вполне себе центруется. Всё-таки HTML/CSS/JS - это базовые технологии для веба. Остальное, включая Tree - преобразовывается к этим трём. Наверное где-то преобразование споткнулось.
nin-jin
У вас выключка сломалась.
Spaceoddity
Мы знаем что такое выключка (как трогательно видеть полиграфические термины в 2023 применительно к вебу). Мы до сих пор не можем понять, что вы хотите получить в итоге???
Вы либо выравниваете текст по центру, либо по левому краю. Как вы это хотите совместить? Или я реально попал в точку с text-align-last?))
Ну или нарисуйте что ли...
nin-jin
Если у вас совсем плохо с фантазией, можете попросить любого вашего знакомого дизайнера нарисовать для вас центрированный текстовый блок с выключкой влево.
flancer
Ваш текст изначально был "выключен" по левому краю. Размер родительского элемента в вашем примере 300px. Слова "отцентрирован", "распидарасило", "обескураживает" и "иррациональная" просто длиннее, чем свободное место на предыдущей строке. Я изменил размер родительского элемента, поставив 325px, и стало вот так:
Поставьте
word-break: break-all;и будем вам и центровка, и выключка, и полное обалдевание пользователей от переносов:nin-jin
Поздравляю, вы заняли первое место в спец олимпиаде среди инвалидов умственного труда.
flancer
"Нее, друг, с таким настроением ты слона не продашь!" (с)
У вас исключительно скромные навыки социального взаимодействия и в силу этого вы весьма забавный персонаж. Так факапиться, как вы - тут определённо нужен талант!
flancer
Спасибо добрым людям (конкретно - Артёму), объяснили, что вы, возможно, имеете в виду под "выключен и отцентрирован" - текст в блоке выровнен по левой границе, ширина блока определяется самым длинным словом текста, сам блок отцентрирован относительно родительского блока (в красной рамке).
Вполне достижимо средствами CSS, как видно в примере. Возможно, $mol просто не очень подходящий инструмент для изысканной вёрстки. Пока через тернии Tree продерёшься до основ...
mobi
А можно, чтобы ширина блока с текстом была не минимально возможная, а максимально возможная в пределах родительского блока, но с тем же эффектом центрирования?
flancer
Это и было сделано в изначальном примере. Только там из-за длинных слов создавалось впечатление, что блок сдвинут влево, а так-то он был вписан в родителя:
mobi
Так в этом-то и проблема. У меня один знакомый лет 15 назад принимал участие в разработке сайта со стихотворениями, там как раз нужно было каждое стихотворение разместить по центру, но при этом выравнивание должно быть по левому краю. Если не ошибаюсь, там в итоге каждую строку обернули в span и на JS рассчитывали максимальную длину строки и задавали размер родителю.
flancer
Вот пример верстки от того же Артёма для стихов:
mobi
Спасибо, возьму на заметку.
flancer
ещё один пример от Артёма, без промежуточного блока:
Spaceoddity
А зачем вы
прописали?))
Это вы типа так выравниваете, а "болезный css" не хочет как надо работать?))
Так это и не должно работать)) Читайте почему - прямо в этом же блоге)) https://habr.com/ru/companies/ruvds/articles/494716/
Что-то у вас матчасть совсем гуляет - подтянуть бы надо, прежде чем технологии обвинять))
nin-jin
Забавно, что в той статье как раз и объясняется, почему это работает.
Hardcoin
Разве внутренним фронтендерам никогда не требовалось центрировать div?
Areso
Это слишком просто!
Не может фронтендер, попавший в Гугл, заниматься такой банальщиной!
Spaceoddity
Ну вот кто это плюсует? И где! Мать твою, на Хабре... "Пропал Калабуховский дом..."(с)
Стандарт складывался не стихийно, а максимально продуманно и системно, насколько вообще можно было в таких условиях (когда у вас в "одной эпохе стандарта" браузеры с разницей в возрасте в 10 лет!)...
Во-первых, за всем строго следил консорциум. Вы можете сейчас накидывать что угодно, но W3C показал себя с самой лучшей стороны.
Во-вторых, причём здесь Гугл? Ну т.е. он причём, конечно. Но он далеко не один был. И в те времена о которых вы ведёте речь - он был далеко не самым главным участником этого "кружка по интересам".
В-третьих, да - в CSS была куча проблем. Вот это бесячее вертикальное центрирование. Inline-block для адекватного отображения требовал форматировать html-код. Masonry-лэйаут не реализован до сих пор, а Columns до сих пор слишком глючный.
Но в итоге то, во что вырос CSS - это эталон того, как должен развиваться годный ЯП. Из него выбросили весь мусор, ему упростили синтаксис, по итогу добавили такое количество фич и возможностей... Актуальный CSS3 и CSS2.1 даже 10-летней давности - это небо и земля. Большая часть того, для чего 10 лет назад требовалось подключать jQuery, сейчас реализуется несколькими строчками в CSS.
Современный CSS - это самый мощный инструмент управления представлением, какой только можно представить! Я немного в курсе того, как обстоят дела с интерфейсами в каком-нибудь Android или десктопах... И меня интересует лишь один вопрос - как скоро CSS интегрируют во все информационные технологии, как дефолтный инструмент для построения интерфейсов. У него для этого уже есть всё необходимое! Рядом просто не лежит даже ничего...
И вообще, я как специалист, который постоянно использовал CSS последние лет 12, хочу только выразить огромную благодарность всем причастным к созданию современного CSS. Это однозначный вин!
ris58h
Просто громкие ничем не подкреплённые слова.
Вы сами ответили причём. Про то что Google был один ничего не говорилось. Подмена тезиса.
Но они никуда и не делись, как вы сами и пишите.
Тоже громкие ничем не подкреплённые слова. Я могу смело предложить парочку других языков в роли эталона.
Куда выбросили? Обратной совместимости нет?
Вот это и пугает. Награмождение костылей на все случаи жизни != эталон ЯП.
Смотри про костыли выше.
Спасибо, не надо.
Spaceoddity
Пфф...
Ничуть не менее подкрепленные и более громкие, чем тезисы из исходного коммента.
И чтобы сразу вопрос закрыть - а какую фактологию вы подразумеваете для подкрепления моих слов? Ну вот CSS, например, живее всех живых, как технология. Это разве не показатель успешной работы W3C?
Ничего и не говорилось про то, что он был не один. В любом случае, единственное на что мы можем опираться - там точно был Гугл))
Ну раз уж из всех участников по имени назван именно Гугл - мне показалось вполне логичным немного уточнить факты (а то человеку не в теме может показаться что во всем "виноват" именно Гугл). Так что подменой тезисов занимаетесь скорее вы ;)
Ещё как делись! Вертикальное выравнивание работает)) 3-пиксельный баг в IE/Edge пропал)) Что вам ещё надо?
Вот сейчас вы самым наглым образом занимаетесь подменой тезисов;) Проблем почти не осталось! Вот этот мой тезис в следующий раз будьте добры цитировать, а не перекрученную отсебятину ;)
Вы пока не сказали вообще ничего конкретного, а просто занимаетесь демагогией и душниловом ;) Это к вопросу о подкрепленных словах))
И не надо пугать заранее - предлагайте)) Только в более подходящем треде - у нас тут всё-таки о CSS речь.
На свалку истории. Есть.
Ложь и передёргивание!
ему упростили синтаксис, по итогу добавили такое количество фич и возможностей != Нагромождение костылей на все случаи жизни
И чё? Вбросили про костыли (причём как будто бы приписав эти слова мне - жирновато). Куда смотреть?
Боюсь вашим мнением на этот счёт никто не поинтересуется.
kemsky
Не у всех было 12 лет на изучение CSS, вот в чем проблема.
FoxWMulder
не плохое объяснение.
помойму так в CSS накрутили всякого, слишком много чего не надо было бы. из стилей превратили его в чуть ли в недоязык программирования, в итоге есть какие-то разрозненые свойства которые выполяют точечно какую-то задача и имеют кучу оговорок.
вообще убило.
pda0
"Это не правильно, мы должны разработать стандарт, который подойдёт всем!" :)