SelenIT

Судя по всему, дело в дефолтном вертикальном выравнивании по базовой лини текста (vertical-align: baseline), для инлайн-блоков эта линия — низ последней строки текста. Можно исправить, изменив vertical-align на top или bottom. Но вообще на инлайн-блоках (а до них на флоатах, а еще раньше на таблицах) такое раньше делали вынужденно, «от бедности» — из-за отсутствия нормальных кроссбраузерных инструментов именно для горизонтальной раскладки блоков. Сейчас эта задача гораздо проще и надежнее решается флексбоксами (а то и гридами), а браузерами, не понимающими флексбоксов, смело можно пренебречь.

Сейчас мало кто проверяет сырую разметку, потому что она бывает мало связана с итоговой DOM, всё самое интересное рендерится на клиенте хитрыми скриптами и фреймворками:). Но если проверять, то лучше вот этим (его автор еще давно объяснял, почему).

Зачем для этого скрипт? Просто заменить height на min-height – не решение?

Это задача не для флексов, флексы не умеют объеднять строки/столбцы. А вот на гридах она решается элементарно (даже с поддержкой IE11 через Autoprefixer проблем возникнуть не должно, ничего из неподдерживаемого там тут вроде не требуется).

Может, я чего-то не понимаю, но... overflow-y: auto – не то?

В задаче требуется вертикальная связь между элементами в колонках. Гриды дают ее «из коробки». Флексбоксы (в т.ч. псевдосетки на них а-ля Бутстрап) могут до некоторой степени *имитировать* ее, но цена этого — потеря гибкости (в которой главная сила флексбоксов). Вот если вертикальные связи не нужны, а нужно наоборот гибкое заполнение места по горизонтали независимо от соседних рядов (что «из коробки» делают флексбоксы) — вот туда пихать гриды было бы глупо, тут я бы согласился. Флексбоксы и гриды дополняют друг друга, где у одних слабость — у других сила, и наоборот:)

Грид — это и есть сетка. Гибкая и универсальная. «Сетки» а-ля бутстрапные .col-* и т.п. — на самом деле только имитация сетки для одного-двух частных случаев (а-ля 12 колонок фиксированной ширины), по сути костыли. Имхо, глупо скорее прикручивать костыли там, где задача просто и естественно решается без них...

Грибы предназначены для выстраивания элементов по сетке:). Каркас сайта часто представляет собой сетку, поэтому гриды подходят для него лучше всего остального. Но это не значит, что они предназначены *только* для каркаса и не годятся для других сеток (а тут — именно сетка, хоть и гибкая).

Это только так кажется;) Никогда не доверяйте разметке, всегда смотрите, что показывает DOM-инспектор.

Как минимум, таблице table-layout:fixed надо бы задать. Если не поможет, стоит вдобавок к нему попробовать width вместо max-width для ячеек. Другой путь — задавать эти стили не ячейке, а вложенному в нее диву.

С проблемой не связано (скорее всего), но сходу возник вопрос по коду: зачем display: inline; рядом с float: left;? Единственное осмысленное применение такому сочетанию, которое приходит на ум — борьба с «удвоением margin-ов» в IE6-, но неужели кто-то еще на это оглядывается?..

Флексбоксы — первый способ именно раскладки блоков в CSS, который не хак. Гриды — второй. Остальное — хаки. Флоаты изначально предназначены для врезки иллюстраций в текст, на безрыбье их можно использовать для размещения блоков, но нужны «клирфиксы» или хаки для отдельного блочного контекста. Инлайн-блоки изначально для вставки чего-то «кнопкоподобного» в текст же, на безрыбье ими тоже можно размещать блоки, но приходится следить за форматированием исходника или «скукоживать» пробелы между тегами хаками же. Таблицы изначально для табличных данных, табличными стилями в принципе можно размещать блоки, но иногда это сбивает с толку скринридеры (впрочем, насколько я в курсе, этот баг браузеры в основном поправили) и в их реализации часто слишком много неочевидной и не всегда хорошо документированной магии. Знать полезно их все. Иногда попадаются очень специфические задачи, в которых преимущества чего-то одного перевешивает его издержки (например, той же самой "магией таблиц" можно сделать "призрачную" обертку-ячейку для нескольких соседних элементов сразу, если менять разметку нельзя). Но по умолчанию всегда рациональнее использовать инструменты по основному назначению, а не «героически преодолевать» самому себе созданные трудности.

Упс, имел в виду 2-й блок, а написал 3-й (смотрел на сетку на флоатах, а думал про сетку на колонках, видимо). Приношу извинения! Второй блок (плавающий) накладывается на 4-й и выталкивает его контент вниз (под себя), поэтому общая высота 4-го блока складывается из высоты 2-го + высота контента 4-го + его отступы. 1-й и 3-й плавающие блоки накладываются на padding 4-го и не пересекаются с его контентом, поэтому на его высоту не влияют.

Высота берется из особенностей работы блочного контекста форматирования. Блочные боксы без clear идут друг за другом, разделенные лишь «схлопнутыми» margin-ами, а float-ы проходят сквозь них, расталкивая их содержимое. Поэтому 2-й плавающий блок не выталкивает сам 4-й блок вниз, а накладывается на него. Но если добавить 4-му блоку clear: right, то он перестанет включать в себя высоту 2-го блока (и 2-й блок не будет накладываться на его вложенный блок, так что можно будет убрать у последнего display:inline-block и width).

Это так. Но браузеры, которые не поддерживают гридов сейчас — это в основном или старые мобильные, или IE на старых windows-машинах. Для таких браузеров может быть оправдана деградация до чего-то попроще. Кстати, если можно зафиксировать высоту карточек, то для такой раскладки вполне можно сделать фолбэк на старых добрых флоатах.

На CSS Grid делается тривиально.

Полагаю, Switch74 показывал пример, что ваш код скрывает меню при ширине окна 600px и менее, и показывает его при ширине свыше 600px, как и ожидается (в «песочнице» по ссылке это можно увидеть, перетягивая разделитель между секторами). И если этого не показывает «программа для Chrome» — возможно, дело в этой «программе»... Поэтому я и спросил, что показывает встроенный инструмент для этой же задачи.

CSS-гриды так умеют.

А встроенный эмулятор устройств из отладчика Chrome (F12 и кликнуть по второй слева иконке, «планшет и телефон», в меню) что показывает?

Предполагаю, что должно адекватно поддерживаться начиная с IE8 (который хвалился «полной поддержкой CSS2.1»), проверить прямо сейчас не могу, но о каких-либо проблемах с этим способом в IE10 и выше я не слыхал. IE6 не умел растягивать контент через пары left/right и top/bottom, это да, но он ведь уже много лет как неактуален...

Есть еще вариация первого способа, на абс. позиционировании. Имхо, чуть интуитивнее, и гориз. центрирование не зависит от пробела в коде между <img> и </div>:). Но основная суть та же.

Строка для картинки (вызывающая отступ под ней, а для очень низких картинок — и над ней) появилась в HTML4 (точнее, в CSS эпохи HTML4), Эрик Мейер писал об этом в 2003-м. Стандартный режим (один и тот же) во всех браузерах новее 2000 г. включает любой из доктайпов HTML 4.x Strict, XHTML1.x Strict и HTML5, но HTML5 из них самый короткий (как говорилось в старой рекламе, «если не видно разницы, зачем платить писать больше»:). Поэтому его и сделали стандартом. В самой спецификации написано, что доктайп обязателен лишь «по историческим причинам», т.к. без него в браузерах бывает разброд. Был еще «почти стандартный» режим, включался при Transitional-доктайпах HTML4 и XHTML1.0 и отличался в основном как раз поведением изолированных картинок, но он был нужен лишь для совместимости с ископаемым контентом и интересен лишь веб-археологам.

document.querySelectorAll('ul > li:nth-child(7)') возвращает коллекцию всех элементов li, являющихся седьмыми потомками своих родительских ul. Вам нужно обновить свойство innerHTML одного из таких элементов (вероятно, единственного... пока). Присваивать строку результату querySelectorAll (самой коллекции элементов) смысла нет. Закешировать коллекцию в переменную и взять ее первый элемент — правильная мысль, но надо было довести ее до конца: присваивать обновленное значение самому menu_upgrade[0].innerHTML, а не коллекции. Я бы воспользовался не querySelectorAll, а просто querySelector — он сразу возвращает один элемент (а не коллекцию). А заодно подстраховался бы более точным селектором, чтобы случайно не зацепить другие списки. Итого что-то типа var menu_upgrade = document.querySelectorAll('nav > ul > li:nth-child(7)'); // получили элемент menu_upgrade.innerHTML += '<p>TEST</p>'; // и обновили его innerHTML

Так задумывалось исторически, но де-факто последних лет 10 он действительно нужен для включения стандартного режима в браузере, т.е. «чтобы не было неразберихи» ? Но корень проблемы, да, в том, что элементы с display:inline/inline-что-то всегда резервируют под себя целую строку высотой как минимум с line-height родительского элемента (тут чуть подробнее с примером), а у img по умолчанию display как раз inline.

Добавить flex: 1 1 auto; для .radio-group__label (ну и саму width: 280px для .radio-group не забыть)?