Width height не работает

Проблемы CSS. Часть 2

Продолжение перевода статьи «Проблемы CSS. Часть 1».

Когда использовать width / height равный 100%?

Height: 100%

Пожалуй, начнем с того, что попроще. Когда использовать height: 100%? На самом же деле, вопрос часто звучит немного по-другому: «Как мне сделать так, чтобы моя страница заняла всю высоту экрана?». Ведь правда?

Для ответа на него нужно понять, что height: 100% равен высоте родительского элемента. Это не магическое «высота всего окна». Так что, если вы захотите, чтобы ваш элемент занял все 100% от высоты окна, то установить height: 100% будет недостаточно.

Почему? А потому, что родителем вашего контейнера является элемент body, а у него свойство height установлено в auto по умолчанию; а значит — его высота равна высоте контента. Конечно, вы можете попробовать добавить height: 100% к body, но этого тоже будет недостаточно.

Почему? А все потому же, родителем элемента body является элемент html, у которого также свойство height равно auto и он также растягивается под размер контента. А вот теперь, если добавить height: 100% и к элементу html, то все заработает.

Стало понятнее? Корневой элемент html на самом деле не самый верхней уровень на странице — им является «viewport». Для простоты, будем считать, что это окно браузера. Так вот, если установить height: 100% элементу html, то это то же самое, что сказать — стань такой же высоты, как окно браузера.

Суммируем полученную информацию в небольшом кусочке кода:

Готово. Если вам интересно углубится в тему, как устроен viewport, я настоятельно рекомендую статью от PPK.

А что если у родительского элемента установлено свойство min-height, а не height?

Недавно, Роджер Йохансен (Roger Johansson) описал проблему с height: 100%, проявляющуюся, когда у родительского элемента не установлен height, но указан min-height. Я не хочу углубляться в сказанное в статье, а перейду сразу к выводам. Вам необходимо установить height: 1px для родителя, чтобы дочерний элемент смог занять всю высоту указанную в min-height.

Более подробно, с этим вопросом, вы можете ознакомится в статье Роджера Йохансена (Roger Johansson).

Width: 100%

Теперь давайте разберемся с width: 100%. Для начала, небольшое уточнение: устанавливая свойство width: 100%, мы хотим, чтобы наш элемент занял всю ширину родительского элемента. Все стандартно.

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

Если добавить padding и/или border к элементу с width: 100%, то он перестанет помещаться в родительский элемент. Потому что появились padding и border и вот почему width должен был называться content-width. А теперь, пожалуйста, посмотрите на пример демонстрирующий вышесказанное.

Допустим, ширина родителя 25em, а дочернего элемента — 100% (от ширины родителя) и он также имеет padding равный 1em (1em справа и1emслева, всумме2em по горизонтали) и border размером в 0.5em (0.5 em справа и 0.5 emслева, всумме1em по горизонтали), что в итоге нам дает 25em (100%) + 2em + 1em = 28em.

Есть 4 возможных пути решения этой проблемы. Первый и, наверное, лучший способ — избегать свойства width: 100%, тем более что в данном случае оно абсолютно бесполезно. Если дочерний элемент блочный, то он и так займет всю ширину родителя автоматически (без проблем с padding`ами и border`ами). Но если мы работаем с inline-block элементом, то нам не удастся так просто решить эту проблему.

Мы можем заменить width: 100% на статичный размер. В нашем случае 25 — (2 + 1) = 22em. Само собой — это плохое решение, потому что нам нужно вычислять ширину вручную. Пойдем другим путем!

Третий способ — использовать calc() для расчета ширины: width: calc(100% — 3em). Но оно тоже не подходит. Во-первых, нам все еще нужно вычислять размеры padding + border. Во-вторых, calc() плохо поддерживается браузерами (не работает в IE 8, Safari 5, Opera 12, родном браузере Android).

Идея номер четыре — использовать свойство box-sizing: border-box. Оно изменяет алгоритм расчета ширины и высоты элемента так, чтобы в них учитывались свойства padding и border. Отличная новость, заключается в том, что у box-sizing хорошая поддержка браузерами (IE8+, Opera 7+). А для всех остальных браузеров можно использовать polyfill.

Вывод: не используйте width: 100% без box-sizing: border-box.

Как не облажаться с z-index.

Все элементы на страницы позиционируются в трех плоскостях: кроме вертикальной и горизонтальной оси, существует дополнительная ось Z (глубина). Поначалу все выглядит очень просто — элементы с большим z-index находятся выше элементов с меньшим z-index. К несчастью, все гораздо сложнее. Я уверен, что z-index самое сложное css свойство за всю его историю. А также уверен, что проблемы связанные с z-index встречаются чаще других при работе с css. Надеюсь, что мы просветим возможные пути их решения.

Для начала. Свойство z-index не имеет эффекта на статических элементах. Чтобы иметь возможность перемещать элемент по оси Z, нам нужно изменить его позиционирование на relative, absolute или fixed.

Важно понимать в z-index то, что не все элементы в DOM дереве размещены на одном уровне. Это значит, что изменение z-index у элемента до очень большого значения, не гарантирует того, что он будет помещен на передний план. Это называется контекстом наложения.

Простыми словами, контекст наложения является, своего рода, группой на основе одного html элемента, у которого все дочерние элементы получают ту же позицию в контексте и такой же z-index. Изменения z-index у элемента может привести к перекрыванию им других элементов, так как вам необходимо. Вот как располагаются элементы в одном контексте наложения (снизу вверх):

1. Фон и границы элемента, формирующего контекст
2. Дочерние контексты наложения с негативным z-index (самый маленький первый)
3. Не позиционированные элементы
4. Позиционированные элементы со значением z-index равным auto или 0
5. Позиционированные элементы с положительным z-index (каждый следующий по порядку расположен выше предыдущего, при равенстве z-index)

Когда ситуация становится неприятной

Итак, мы рассмотрели основы z-index понимание которых сэкономит вам кучу времени, уж поверьте. К сожалению, их недостаточно. Тогда все было бы слишком просто.

Дело в том, что каждый контекст наложения имеет свою ось Z. Например, элемент A в контексте 1 и элемент B в контексте 2 не могут взаимодействовать через z-index. Это значит, что элемент A, как часть контекста наложения находящегося в самом низу общего контекста наложения, никогда не сможет перекрыть элемент B другого контекста, находящегося выше уровнем, даже с очень большим значением z-index.

Но, что еще хуже. Элемент html создает корневой контекст наложения. Затем, каждый не статично-спозиционированный элемент со свойством z-index не равным auto, также создает свой контекст наложения. Ничего нового. Но вот где все начинает рушиться: некоторые, никак не связанные с контекстом наложения css свойства, также создают новые контексты. Например, свойство opacity.

Все верно, свойство opacity создает новый контекст наложения. То же самое делают свойства transform и perspective. Хотя это не имеет никакого смысла, не так ли? Например, если у вас есть какой-нибудь элемент с opacity меньше 1 или с любой трансформацией, у вас потенциально может возникнуть проблема.

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

Давайте подведем краткий итог вышесказанного:

• Перед применением z-index убедитесь, что установили свойство position не равным static
• Не используйте более 5 цифр для значения z-index, это абсолютно бессмысленно; в большинстве случаев, значение z-index в районе 10, будет более чем достаточно
• Убедитесь, что элемент, который вы хотите перекрыть находится в том же контексте наложения.
• Если у вас все еще что-то работает не так, как должно, убедитесь в отсутствии трансформаций и opacity выше у родительских элементов.

В тему, я так же рекомендую к прочтению What No One Told You About Z-index от Филипа Волтона (Philip Walton) и официальную спецификацию css.

Борьба со схлопыванием отступов

Как мне кажется — это один из глюков css, который крадет наибольшее количество времени, чтобы разобраться в чем же дело. Можно сказать, что он чем-то похож на баг с z-index. Как бы то ни было, схлопывание отступов — это когда верхний и нижний отступ двух элементов схлопываются в один (самый большой из двух).

К счастью, как правило, такое поведение и ожидается. Возможно, поэтому оно так и работает (так указано в спецификации css). Однако, иногда вы не хотите, чтобы вертикальные отступы схлопнулись. Чтобы понять как этого избежать, мы для начала посмотрим, почему так происходит. Схлопывание отступов может произойти в трех разных случаях.

Соседние элементы

Когда два соседних элемента имеют вертикальные отступы — они схлопываются до самого большого из них. Есть несколько способов предотвратить схлопывание:

• clear: left; float: left; (right то же работает)
• display: inline-block;

Пример на jsFiddle иллюстрирует работу фиксов.

Родитель и первый/последний дочерний элемент

Обычно, верхний отступ родительского и дочернего элементов схлопываются до самого большого. Аналогичным образом работает и для последнего дочернего элемента и нижних отступов. Для решения этой проблемы, также есть несколько способов. Большинство из которых заключаются в добавлении одного из следующих свойств родительскому элементу:

• overflow: hidden (или любой другой, но не visible)
• padding: 1px (или другое значение больше 0)
• border: 1px solid transparent (или любой другой border)
• float: left (right то же работает)

Пример на jsFiddle иллюстрирует работу фиксов.

Пустые блоки

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

Заключение

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

Также я бы рекомендовал к ознакомлению следующие статьи и сайты:

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

Источник

Не работает width и height в таблице

Блин, уже как только не пробовал, не меняется размер этой чертовой таблицы.

Должно быть вот так:

Пробовал height=»значение» — больше делает, меньше — нет.
А width=»значение» — вообще не работает.

Стало шире, но ничего не меняется, width: 100% — вообще не работает.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Не работает width и height в таблице
Подскажите в чем может быть проблема с таблицей не работает ширина и высота, побывал писать в самом.

не работает width и height
Всем привет. Как заставить работать height и width? http://jsfiddle.net/0ka1y383/

Height i Width
бла-бла-бла z=fgets(a,10000,f); бла-бла-бла if(z!=0) n+=1; Memo1->Height=((n*5)+(n*10)); .

height width
Наверное глупый вопрос: Как задать размеры изображению которое стоит как фон сайта ? 8

Попробуй к ячейкам добавить свойство:

Не помогло, всё так же осталось.(Код точно изменил).

Может не туда сунул?

Решение

Inline style — лучше не использовать (очень плохая практика »/>) — а если и задавать то правильно нужно писать:

Решение

Вот если открыть браузером popup.html по ширине всё нормально.
А в приложении оно вон как выглядит:

padding в width и height
В общем-то пытаюсь тут создать свой первый шаблон и такая ситуация — поскольку контента нету.

Width — Height Binding
Суть вопроса такая. Сделано окно без содержимого, к нему динамически подключаются UserControl’ы.

Вопрос по Height, Width в Auto
Здравствуйте, столкнулся с таким вопросом. Допустим есть у меня контейнер, ну например Grid1.

Соотношение пиксель — width\height
Сколько в одном пикселе width\height?

.attr() height&width of iframe
В консоль значение выводит, но почему-то значение аттрибута iframe не меняется.

Атрибуты WIDTH и HEIGHT тега
Атрибуты WIDTH и HEIGHT тега могут быть использованы для: • Установки для изображения.

Источник

Задавать Height и Width для изображений снова важно

Приветствую. Представляю вашему вниманию перевод статьи «Setting Height And Width On Images Is Important Again», опубликованной 9 марта 2020 года автором Barry Pollard

Сторонники веб-оптимизаций часто советуют добавлять к изображениям атрибуты с размерами, что позволяет при отрисовке страницы оставлять нужное количество пространства ещё до загрузки самого изображения. Это позволяет избежать смещения раскладки страницы по мере загрузки изображений — что с недавних пор начал измерять Chrome в новой метрике Cumulative Layout Shift (CLS).

Секрет, не так хорошо известный разработчикам, не являющимся заядлыми сторонниками веб-производительности, заключается в том, что до недавнего времени, как мы увидим ниже, во многих случаях это фактически не имело особого смысла. Однако, недавние изменения в мире CSS и их быстрое внедрение в браузерах снова делает добавление атрибутов width и height к тегу полезным.

Почему добавление Width и Height было хорошим советом

Эта страница будет отрисовываться в два этапа: первый — после загрузки HTML, второй — после загрузки изображения. Но это может привести к тому, что после загрузки изображения и вычисления необходимого для его отображения пространства, содержимое, расположенное под ним, «прыгнет» вниз:

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

Традиционным способом избежать этого была установка для тега атрибутов width и height , чтобы ещё на этапе загрузки одного лишь HTML браузер мог выделить для изображений необходимое количество места. Сделаем это в следующем примере:

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

Кроме раздражающих пользователя скачков, необходимость многократно перерисовывать страницу также может приводить к существенному увеличению нагрузки на процессор. На приведённом ниже скриншоте отображены расчёты производительности, выполненные в браузере Chrome на сайте с галереей, содержащей около 100 изображений. Показатели слева были достигнуты при наличии атрибутов width и height , справа — при их отсутствии.

Как вы могли заметить, влияние существенное — это будет особенно заметно на маломощных устройствах и при низкой скорости подключения. Время загрузки страницы будет существенно увеличено.

Как CSS работает с шириной и высотой элемента

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

Когда в этом возникает потребность, значение width переопределяется и ширина изображения ограничивается. Но если для тега через атрибут height также задана и высота, она не будет переопределена и изображение в итоге получится вытянутым по высоте и сжатым по ширине, поскольку соотношение сторон картинки больше не сохраняется.

На самом деле, это очень легко исправить, добавив в CSS свойство height: auto , чтобы также переопределить значение заданного в HTML атрибута height .

Однако, не для всех этот факт является очевидным и думаю, что порой именно из-за такого поведения разработчики избегают задания размеров через HTML. Если в атрибутах изображения размеры не заданы, в CSS можно просто указать max-width: 200px , при этом явно не указывая height: auto , и браузер сам рассчитает нужную высоту, как только изображение загрузится.

Следовательно, если мы добавляем размеры через HTML-атрибуты и при этом используем трюк height: auto , то получаем лучшее из обоих миров, так? Раскладка страницы не смещается, но остаётся возможность менять размер через CSS. Что ж, возможно вы будете удивлены (я был удивлён, поэтому и решил написать эту статью), но до недавнего времени это было не так.

Для примера, рассмотрим код ниже:

В данной ситуации загрузка будет происходить следующим образом:

Погодите-ка, что здесь происходит? Мы вернулись к первой проблеме. Я же говорил, что указывая размеры изображения в HTML, можно избежать проблем со смещением элементов страницы. Становится интересно. Мы переходим к основной части данной статьи.

Проблема в том, что если в CSS в свойствах width и height задаётся не фиксированное значение (а в наше время адаптивности фиксированные значения и не используются), при рендеринге страницы возникает потребность получить размеры изображения из самого файла, прежде чем размеры сторон смогут быть посчитаны. При этом атрибуты width и height , заданные в HTML, игнорируются.

Следствием всего этого является то, что на деле задавать атрибуты для изображений нередко оказывается не настолько важным. Да, когда изображение показывается в полный размер без изменения его размеров с помощью CSS, полезно решить проблему смещения раскладки. Однако, когда используется CSS-код, целью которого является, например, предотвращение переполнения изображением доступного пространства, вы столкнётесь с проблемами.

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

На многих веб-сайтах атрибуты width и height для тегов не указываются. Это может происходить из-за того, что разработчики не знают об их пользе, или наоборот знали о том, что в большинстве случае в этом мало смысла. Какова бы не была причина, это встречается. Но как мы можем агитировать за это, если даже популярный инструмент аудита Lighthouse не считает данный момент ошибкой (хотя в свете некоторых моментов, о которых мы поговорим, уже обсуждается добавление данной оценки).

Решение проблемы

Ограничения для адаптивных изображений давно известны и были найдены способы решения этой проблемы, в том числе хак с использованием padding-bottom. В нём используется тот факт, что значение для свойства padding , заданное в процентах, всегда высчитывается из ширины родительского контейнера. Следовательно, это можно использовать для создания контейнера, высота которого будет пропорциональна его ширине. Например, у нас есть изображение с соотношением сторон 16:9, тогда следующий код создаст для этого изображения контейнер соответствующего размера.

У данной техники есть три основных проблемы:

Она требует ручного расчёта и перевода в проценты значения (например, для соотношения 16/9 нужно 9÷16*100 = 56.25% ), что потенциально требует отдельного CSS-правила для каждого соотношения сторон.

Запомнить набор всех необходимых свойств непросто — если забыть добавить или случайно удалить какую-то строку кода из примера выше, всё сломается. Не говоря уже о том, что эта техника требует, чтобы все изображения были обёрнуты в дополнительный элемент-контейнер.

Данный подход известен и используется не всеми веб-разработчиками.

И давайте будем честны — это хак. И нам следовало бы писать код без его использования.

Проблема фиксированного соотношения сторон

Описанная выше проблема рассматривалась несколькими организациями по стандартизации.

Рабочая группа CSS (CSS Working Group) предложила свойство aspect-ratio , о котором писала Rachel Andrew. Как только браузеры начнут поддерживать его, будет решена проблема сложности кода и пример выше будет упрощён до следующего вида:

Намного лучше! Это особенно полезно для видео, где нам обычно доступен набор часто используемых соотношений сторон, позволяя создать несколько классов для каждого размера. Возможно, это менее полезно для изображений, где размеры менее стандартизированы, из-за чего остаются нерешёнными ни проблема №1 с необходимостью отдельного CSS-правила для каждого изображения, ни проблема №3 с необходимостью разработчикам не забывать применять этот код. Следовательно, это шаг вперёд, но пока что не решение всех проблем.

Помимо этого, Web Incubator Community Group (WICG) — группа разработчиков браузеров и других заинтересованных сторон, способных экспериментировать с технологиями ещё до формальной стандартизации — также предложили свой вариант решения. Речь об атрибуте intrinsicsize , который в коде выглядит следующим образом:

Так как это HTML-атрибут, он может быть установлен для каждого изображения (решая проблему №1 с необходимостью отдельного CSS-правила для каждого изображения) и относительно легко задаётся (решая проблему №2 с необходимостью запоминать большой объем кода), но всё ещё остаётся актуальной проблема с популярностью, если только сообщество не станет активно его продвигать.

У нас уже есть распространённый, хорошо известный метод установки width и height для элементов (даже если он не используется так часто, как хотелось бы), поэтому другие подобные решения неизбежно будут испытывать проблемы с принятием. И вот тут сам собой появляется ответ (теперь кажущийся очевидным).

Вместо введения фиксированного значения свойства aspect-ratio , здесь используется CSS-функция attr , чтобы задать соотношение сторон, соответствующее атрибутам width и height , заданным в HTML. Функция attr уже некоторое время существует, но имеет очень ограниченную область применения — все браузеры поддерживают её при использовании в свойстве «content», например, content: attr(width) . Но для других свойств это ещё не реализовано.

Если бы функция attr работала и в других свойствах, с её помощью можно было получать значение атрибутов width и height и использовать для расчёта значения свойства aspect-ratio , как в примере выше. Это решило бы проблему №1 (не требовалось бы вручную задавать соотношение сторон ни в HTML, ни в CSS), проблему №2 (небольшой объем кода для запоминания) и, как мы увидим дальше, это очень простое решение проблемы №3 (принятие разработчиками).

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

для элемента задан HTML-атрибут height

для элемента задан HTML-атрибут width

height (или width ) задаётся в CSS — в том числе, с использованием процентных значений вида max-width: 100%

width (или height ) устанавливается на auto в CSS

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

Как только браузеры смогут использовать width и height для определения соотношения сторон изображения, мы сможем решить проблему, практически не меняя HTML и с помощью одной строки CSS-кода. Как упоминалось выше, возможно, некоторые разработчики считают, что это происходит уже сейчас.

Стимулирование использования этого решения

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

Таблица стилей браузера — место, где заданы CSS-стили по умолчанию (например, какой font-size у элемента h1 ). При необходимости, их можно переопределить собственными правилами оформления. Добавляя вышеупомянутое свойство aspect-ratio , нам не нужно стимулировать использование этого решения разработчиками — мы, по сути, автоматически включаем его для всех сайтов, которые соответствуют четырём указанным выше условиям.

Однако, это зависит от функции attr , имеющей доступ к HTML-атрибутам width и height , и от свойства aspect-ratio — ни то, ни другое ещё полностью браузерами не поддерживается. Поэтому вместо этого, в качестве более простого решения, браузеры могут заложить такое поведение в коде рендеринга страницы, а не раскрывать его в таблицах стилей браузера, но эффект будет тот же. Такой альтернативный способ реализации даже был частью основного предложения.

Firefox первым реализовал этот принцип в виде эксперимента, после чего включил его по умолчанию в Firefox 71. Как только это было сделано, ваш сайт мог стать немного быстрее и удобнее. Возможно, в будущем это будет реализовано через таблицы стилей браузера, но пока что спасибо и на этом.

Обратная совместимость

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

Тем не менее, когда Firefox начали экспериментировать, обнаружились проблемы там, где width и height были заданы неправильно. Если раньше эти некорректные значения при переопределении CSS-стилями игнорировались бы, то теперь при установке значения auto они продолжали использоваться, что приводило к искажению пропорций изображения. Вы можете возразить, что разработчикам просто следует задавать правильные значения, а в некоторых случаях проблемы могут возникать и сейчас (как в приведённом выше примере, где не установили height: auto ). Но и повышать риск сломать разметку из-за небольшой ошибки — идея плохая. Это то, чего в вебе очень стараются избегать.

Решение этой проблемы относительно простое: пусть фактическое соотношение сторон изображения переопределяет значение, вычисленное в CSS. Таким образом, неправильно рассчитанное соотношение сторон будет использоваться для первоначально отрисованной страницы, но потом может быть пересчитано, когда изображение всё же загрузится. Это действительно может приводить к смещению макета (поскольку изначально выделенное может оказаться неправильным), но ведь так было и раньше. А в конечном счёте это ещё и лучше, поскольку неправильное соотношение сторон часто будет ближе к истине, чем нулевая начальная высота.

Внедрение в других браузерах

После успешного эксперимента Firefox, в Chrome также решили это реализовать (снова-таки, пока что с помощью изменения метода рендеринга, а не таблиц стилей браузера) и запустили по умолчанию в Chrome 79. Недавно, в январе 2020, Apple добавила данный функционал в Tech Preview версию Safari, так что вскоре он может появиться и в стабильной версии. Это будет значить, что последний из основных браузеров реализует это и веб станет лучше при использовании огромного количества сайтов.

Ограничения

При использовании данного функционала следует помнить о некоторых ограничениях, включая проблемы с:

Art Direction

Фикс отлично работает для расчёта соотношения сторон, основанном на фиксированных width и height , но что если они меняются? Это называю art direction — ниже показан пример:

В этом случае мы используем широкое изображение для десктопов, а для мобильных — обрезанное квадратное. Адаптивность изображений может быть реализована с помощью атрибутов srcset элемента :

или с помощью элемента

В настоящее время оба эти элемента позволяют задавать в теге атрибуты width и height только один раз. Также, их нельзя задавать в . Уже было предложено добавить возможность делать это, но пока что использование адаптивных изображений разных размеров всё равно будет приводить к смещению раскладки.

Ленивая загрузка

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

Некоторые техники ленивой загрузки могут включать отсутствие элемента или, по крайней мере, атрибута src (для предотвращения загрузки изображения браузером по умолчанию). Следовательно, в предложенных нововведениях может и не быть существенной пользы, в зависимости от того, как браузер обрабатывает элемент , с атрибутом src или без него. Хотя, если данное CSS-решение станет доступным, разработчики получат больше контроля над соотношением сторон.

Недавно командой Chrome была внедрена встроенная ленивая загрузка, после чего она была добавлена в спецификацию HTML. Вскоре эта функция появится и в Firefox а затем, надеюсь, и в Safari. В этом случае используется элемент с атрибутом src с примерно следующим синтаксисом:

Отлично. Что ж, к сожалению, я обнаружил, что это решение с высотой и шириной несовместимо с ранее добавленным встроенным функционалом ленивой загрузки, в чём можно убедиться на этой тестовой странице. Я сообщил об этой ошибке и надеюсь, что команда Chrome исправит её (Update: было исправлено в Chrome 83).

Не изображения

В данный момент браузеры, которые реализовали данный функционал, сделали это только для элемента , но это также было бы полезно и для элементов , и и этот вопрос обсуждается. Снова-таки, если данное CSS-решение станет доступным через функцию attr и свойство aspect-ratio , разработчики смогут реализовать его для любых необходимых элементов.

Заключение

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

Единственное что потребуется от веб-разработчиков, — задавать атрибуты width и height в разметке. Нам не следует отказываться от этой привычки, а многие CMS лишь помогают в этом. Согласно данным HTTPArchive, 62% тегов имеют ширину или высоту, что намного выше, чем я ожидал, если честно. Но давайте попробуем увеличить эту статистику еще больше, теперь у нас снова есть причина для этого. Итак, я призываю вас делать это при разработке сайтов. Это улучшит удобство ваших пользователей и, в конечном итоге, сделает их счастливее, а не к этому ли мы все стремимся?

Мне написал @Alexandr_Mi, указав на ещё один вариант решения данной проблемы с помощью «data: image / svg + xml + lazyload».

Источник