SelenIT

Флексы, к сожалению, не умеют объединять элементы из разных строк:(. Так что тут или делать на гридах с фолбэком, например, на флоаты (возможно, даже пожертвовав симметрией и центральным положением высокой картинки в старых браузерах), или сразу сдаться и подключить скрипт типа Masonry/Isotope. Можно, конечно, выкрутиться, нагородив кучу вложенных контейнеров, но поддерживать такое, если потребуется поменять порядок отображения картинок, будет ох как невесело. Кстати, в чем здесь должна состоять адаптивность? Картинки должны перестраиваться в меньшее кол-во колонок при сужении окна?

Поставьте oveflow:hidden обрезке. И уберите все пиксельные margin-ы отовсюду и width у .povorot, а взамен отцентрируйте его флексбоксами (display:flex; justify-content:center для обрезки) — так он будет центрироваться даже при меньшей ширине окна, выступающие углы обрежутся — и добавьте обрезке же padding сверху и снизу по 60em, чтобы дать место для верхнего и нижнего углов (ведь transform не меняет геометрических размеров блока, с точки зрения раскладки блок формально занимает то же место, какое занимал бы без трансформации, поэтому его родителя надо расширить явно). А почему ограничение именно для Firefox? Ведь трансформации все браузеры, даже дремучий IE10, давно понимают без префикса. Достаточно поменять -moz-transform на обычный transform, и страница станет кроссбраузерной...

Фоны за границу блока выступать не могут. Но туда могут выступать border-image тени (box-shadow, text-shadow, filter:drop-shadow) псевдоэлементы ::before/::after Ну и расширить границу блока отрицательным margin-ом тоже можно, конечно

Даже не столько в разных браузерах, сколько в разных шрифтах. С поправкой на особенности отрисовки/сглаживания в той или иной платформе.

У меня и на сайте по ссылке меню появляется достаточно резко. Подозреваю, что визуальный «рывок» в примере связан с появлением/исчезновением горизонтального скроллинга — в неприжатом виде меню не помещается в экран и распирает страницу, т.к. к 100% ширины body приплюсовались 5px внутреннего отступа и 5px смещения самого меню, да еще 8px внешнего отступа самого body (надо убирать лишние отступы и/или переходить на box-sizing:border-box).

Универсально убрать это расстояние, к сожалению, нельзя. Это внутреннее расстояние резервируется для выносных элементов букв (всевозможные хвостики-завитушки у f, например) и диакритических знаков (немецкие «умляуты», французские «аксаны» и прочие родственники наших точек над Ё и «улыбки» над Й), а его точный размер зависит от конкретного шрифта и значения line-height. Для небольшого размера шрифта можно лишь «методом тыка» подобрать необходимую поправку с приемлемой точностью. Подробнее про это расстояние и откуда оно берется — в этой статье.

Когда я впервые столкнулся с HTML, меня он привлек ощущением какой-то «волшебности»: пишешь вроде обычный текст, добавляешь к нему пару каких-то странных «заклинаний» — и текст тут же по волшебству превращается в заголовок, таблицу, «обрастает» картинками, связывается ссылками с информацией на другом конце земного — и не только! — шара, и т.д. Захотелось овладеть этой «магией» получше. Так и втянулся. А потом внезапно выяснилось, что за это еще и платят существенно больше, чем за мою специальность по диплому...

Я вам больше скажу по секрету — сами редакторы этой спецификации далеко не всё в ней понимают :). Например, что в CSS2.1 не два контекста форматирования (блочный и строчный), а три (есть еще табличный), они поняли только на 14-й год (!) работы над ней — через год после того, как эта спецификация была «окончательно утверждена» . Так что нормально открывать в ней что-то новое снова и снова и спустя годы

Так зачем делать выравнивание, которое смотрится криво и убого, а потом пытаться исправить его костылями? Когда можно изначально и надежно выровнять как надо?

Я так понимаю, что по центру выравнивается весь контейнер формы, а в нем подписи выравниваются по его левому краю, а инпуты — по правому. Разве нет?

Довольно странно использовать табличную разметку для данных, табличность которых под большим вопросом, и при этом отказываться от возможностей выравнивания, «автоматом» предоставляемых таблицами. Прямо по поговорке «взять билет и выйти из трамвая, назло кондуктору»:). Если уж всё равно менять display, то что мешало сделать 2 <tr>-ки, а на большом разрешении объединить их в одну строку через display:flex для неявного <tbody>, например? Но на мой взгляд, таблица тут вообще притянута за уши. И совершенно зря не используется полезный для доступности элемент <label>. Как вариант — обернуть каждый <input> вместе с подписью в <label> и задать этому <label> display:flex, а <input>-у — margin-left:auto. И он автоматически «прибьется» к правому краю контейнера. При этом клик по любому месту всей строки будет ставить курсор в поле (удобно для юзеров с тачпадом вместо мышки и т.п.).

По-простому — в элемент можно вкладывать всё, что можно вкладывать в его родителя. Например, если <a> лежит непосредственно внутри <div>, то в нее можно вкладывать другие дивы, абзацы, списки и т.п. (всё, что можно вкладывать в сам <div>). Но если <a> внутри <span>, то ничего этого нельзя (потому что в <span> этого нельзя) — можно только «Phrasing content» (голый текст и то, что в прошлой жизни называлось «строчными элементами»). Кроме <a>, такая же модель у <ins> и <del>. Помимо этого, у <a> еще своё дополнительное ограничение на интерактивные элементы (напр. кнопки, инпуты и саму <a>). Но это уже отдельная история:)

Float сам по себе ужимается до ширины контента, inline-block в этом раскладе кажется лишним.

Потому что картинка — строчный элемент, и выравнивается нижним краем по базовой линии текста (как будто это очень большая буква текста). Поскольку она выше букв, она «выталкивает» собой эту базовую линию вниз, а вместе с ней и текст. Чтобы это отключить, надо задать ей обтекание (float). А чтобы ограничить это обтекание текущим пунктом списка, надо добавить ему самому (чтобы он не цеплялся за предыдущие float-ы) и его псевдоэлементу ::after (чтобы картинка из него не вываливалась) сброс обтекания (clear). Примерно так.

На MDN еще неплохая табличка с браузерной поддержкой на странице справки по каждому свойству или технологии, с детализацией, когда начало поддерживаться то или иное значение, формат и т.п. Но иногда и она отстает от жизни (ее тоже вручную обновляют люди, которые не успевают уследить за всем). В целом, can I use — можно сказать, отраслевой стандарт.

IE4-8 включительно. Которые давно 1) составляют мизерные проценты, 2) работают на таком древнем железе, что лучше не грузить его никакими необязательными красивостями. Потому что та древняя технология не умеет в разные варианты одного font-family. Там было тупо 1 font-family — 1 файл. Было дело. Но опять же, очень давно, сама Apple давно не поддерживает те версии iOS и то железо, на котором с нее нельзя обновиться, да и не живут обычно столько даже эпловские девайсы:). Сейчас woff и woff2 достаточно каждому (с). Даже ttf уже не особо нужен.

eot — очень древняя реализация веб-шрифтов (чуть ли не из IE4!). Они очень многого не умеют. В частности, не умеют объединять разные комбинации font-weight и font-style под общим font-family. И, ЕМНИП, поддерживали всего 4 варианта вообще (normal/italic/bold/bold italic). Сейчас eot не нужны. IE9+ понимают современный синтакис с woff-шрифтами, а ископаемому старью лучше довольствоваться системными фолбэками.

Читайте 2.2 плюс модули. Лучше в редакторских черновиках.

CSS2.2 — та же CSS2, но с исправленными ошибками, найденным после выхода CSS2.1 (напр. в нем не забыт табличный контекст форматирования). Некоторые ошибки еще в процессе исправления/уточнения. В какой-то момент заменит CSS2.1. CSS3 — неофициальное собирательное название для всего, что вышло после CSS2, независимо от уровня. Модули начинаются либо с 3 уровня (если дополняют то, что было в CSS2), либо с 1 уровня (если вводят что-то принципиально новое). Так что модули 4, 5 и т.д. уровней формально относятся к CSS3 (хотя это звучит дико, поэтому сейчас лучше говорить просто о "языке CSS", без цифр). "Версий" как таковых у CSS сейчас нет.

О предыдущей версии вообще особо думать не надо, она сыграла свою историческую роль. Текущее состояние HTML как технологии - это редакторский черновик W3C (на сегодня HTML5.3, но эти цифры — условность) и живой стандарт WHATWG. От предыдущих версий нам есть смысл смотреть, пожалуй, разве что implementation report-ы (и то canIUse подробнее и полезнее).

В принципе, можно-то и на инлайн-блоках: кроме упомянутого обнуления размера шрифта, можно сделать симметричные отриц. отступы по 2.5-3px с обеих сторон, можно вместо отриц. отступов использовать такой же отрицательный `letter-spacing` или `word-spacing`, можно честно убрать или «закомментарить» пробелы между тегами в разметке, можно не использовать закрывающие теги для `li` (они опциональны, и при их отсутствии тег закрывается автоматом прямо перед следующим открывающим), можно использовать для родителя кастомный шрифт, в котором у символа пробела нулевая ширина... Но практическая ценность этого на сегодня, имхо — разве что пройти задание «сделать без флексов». Скриптами можно всё, но для этой задачи скрипт — явно перебор

Увы, никак (если только ширина не фиксирована и кол-во элементов в строке константа — тогда можно через :nth-child). А насколько критично сделать это именно на инлайн-блоках? Нельзя для 90% браузеров (включая IE11+, всякие UC Browser'ы и даже Оперу Мини) сделать через display:inline-flex; flex-flow: row wrap; justify-content: center; (просто дописав это для .box__list), тогда отрицательный margin будет вообще не нужен — а решение на инлайн-блоках, пусть и со злополучными пробелами, оставить как фолбэк для оставшихся ископаемых 10%?

Implementors — именно «реализаторы». CSS реализуется в браузерах. Авторы самого CSS (спецификаций) — это specifiers. В принципе, всё относится ко всем, просто в разной мере. Например, описания алгоритмов, как и в каком порядке что должно рисоваться, какие координаты откуда и как рассчитываются и т.п., важнее для разработчиков браузеров — им надо перевести эти описания в реальный код рендеринга, наделав в этом как можно меньше ошибок. Поэтому им приходится разбирать эти алгоритмы в мельчайших деталях, порой уточняя спецификацию по мере необходимости. Но авторам стилей (нам) желательно иметь представление об этих алгоритмах хотя бы в общих чертах — чтобы знать, в каких ситуациях чего от них ждать, и что в какой ситуации эффективнее решит конкретную задачу в верстке.

Да, и поэтому ее еще можно считать относительно не устаревшей — как отражение браузерной реальности вчерашнего-сегодняшнего дня. Но HTML5.2 (предложенная рекомендация со 2 ноября) уже наступает ей на пятки и вот-вот ее заменит, пора к этому готовиться. У W3C тоже есть постоянно обновляемая версия — https://w3c.github.io/html/. Есть мнение, лучше ориентироваться на нее (что есть вообще на сегодняшний день) и canIUse (что реально есть в браузерах), а не на то, включена или нет фича в ту или иную версию с цифрой (что не более чем формальная условность).

В данном случае Implementers — это разработчики реализаций, т.е. браузеров. А авторы — да, те, кто пишет CSS-код, т.е. мы, верстальщики/фронтендеры.