Комментарии 11
margin-left: calc(5px + (-1 * (39px — 1.5em)) / 2);
Вышеприведённые вычисления приводят к получению значения -4px. Почему бы не задать просто -4px? Не лучше ли это в данном случае, чем применение функции calc()?
Тут вы упускаете, что em размер относительный поэтому и сам отступ в таком случае потенциально динамический.
Не знаю, почему команда разработчиков не воспользовалась CSS-свойством object-fit: cover для предотвращения искажений.
У background-size: cover поддержка значительно выше тут и думать не о чем. Решение с невидимыми изображениями интересное, надо взять на заметку. Интересно как к этому поисковики относятся.
Техника сохранения соотношения сторон элемента работает благодаря тому, что, когда у элемента есть вертикальный внутренний отступ (свойство padding-bottom или padding-top), отступ зависит от ширины элемента.
Эта древняя техника наверное появилась одновременно с padding, но встречается редко
Зачем передавать функции calc() единственное значение?
Возможно там будет или было, какое-то вычисляемое значение из нескольких переменных, но сейчас компилится только одно так как не требует динамики.
Я заметил использование свойства position: sticky в правой боковой панели Twitter
Вот это смущает, поддержка ужасная, как по мне решения на js более стабильные, но наверно они что-то знают.
ХаХ. Только сейчас понял, что это перевод и отвечаю я не автору))) Но все равно спасибо, интересные наблюдения.
Вот это смущает, поддержка ужасная, как по мне решения на js более стабильные, но наверно они что-то знают.они знают что поддержка есть во всех современных браузерах. а для 1.47% пользователей можно и через js сделать
Может вы не заметили, но даже у Chrome, которым пользуется подавляющее большинство, поддержка частичная (~ Partial support). Полная поддержка с учетом префиксов только 26.22%. У вас не возникает диссонанса, когда применяется position: sticky в то время как отказываются от object-fit: cover у которого действительно есть поддержка?
Может вы не заметили
Я не заметил. Там же указано в каком имено случае не работает.
homm правильно указал. поддержка не 26.22%, а все 94.41%
а object-fit: cover не применяют скорее всего потому что руки еще не дошли выпилить весь говнокод и заменить на современные методы
а object-fit: cover не применяют скорее всего потому что руки еще не дошли выпилить весь говнокод и заменить на современные методы
Полная поддержка с учетом префиксов только 26.22%.+68.19% частичной поддержки
а object-fit: cover не применяют скорее всего потому что руки еще не дошли выпилить весь говнокод и заменить на современные методыЭто новый дизайн и новая верстка, то есть они подумали и решили напишем-ка мы говнокод, а потом заменим на «современные методы»? Ок…
Вероятно, многие вещи типа img с нулевой прозрачностью — для совместимости со старыми или урезанными мобильными броузерами. Для них такой вот graceful degradation fallback имел бы смысл.
О, как кстати. Просто оставлю это здесь:
Вот с этим calc() есть забавный баг. Картинки лайков, реплаев и ретвитов рисуются svg в квадрате со стороной в 1.25em = 17.5px.
А при их активации и появлении цифры счётчика его высота уже вычисляется
, что округляется до 18px, из-за чего происходит смещение ленты на эти полпикселя, а там ещё и анимация, поэтому переход прям заметно. Уже несколько месяцев это наблюдаю, до сих пор не исправили, написать им что ли.
.r-1hdv0qi {
width: 1.25em;
}
А при их активации и появлении цифры счётчика его высота уже вычисляется
.r-1o9f8vr {
line-height: calc(18.375px);
}
, что округляется до 18px, из-за чего происходит смещение ленты на эти полпикселя, а там ещё и анимация, поэтому переход прям заметно. Уже несколько месяцев это наблюдаю, до сих пор не исправили, написать им что ли.
А какой параметр задали в итоге для навигационных ссылок? Могли бы вы поделиться вашим CSS исходником?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интересные CSS-находки в дизайне Twitter