Width html что это

Обслуживание HTML и XHTML

В этой статье очень кратко описываются некоторые аспекты того, как XHTML посылается с сервера до клиентского приложения (например, в браузер), и как распространенные клиентские приложения обрабатывают ту разметку, которую они получают. Статья описывает решение конкретных проблем, а не стандарты W3C.

Эти вопросы имеют отношение к тому как назначить кодировку HTML или XHTML документа. Эта информация будет также полезна при объяснении того, почему некоторые аспекты стилизации CSS не появляются такими, как их ожидают, или почему они отличаются в различных клиентских приложениях.

MIME типы

Когда сервер обслуживает (то есть отправляет) документ браузеру, он также с документом посылает некоторую дополнительную информацию, которая называется HTTP заголовком.

Поле Content-Type заголовка HTTP описывает, какой это тип формата данных. Эта информация выражается с помощью пометки (MIME медиа тип). Вот пример HTTP заголовка для HTML файла, используя MIME тип text/html . Обратите внимание, что запись Content-Type также может выражать кодировку символов документа.

HTTP/1.1 200 OK Date: Wed, 05 Nov 2003 10:46:04 GMT Server: Apache/1.3.28 (Unix) PHP/4.2.3 Content-Location: CSS2-REC.en.html Vary: negotiate,accept-language,accept-charset TCN: choice P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml Cache-Control: max-age=21600 Expires: Wed, 05 Nov 2003 16:46:04 GMT Last-Modified: Tue, 12 May 1998 22:18:49 GMT ETag: "3558cac9;36f99e2b" Accept-Ranges: bytes Content-Length: 10734 Connection: close Content-Type: text/html; charset=utf-8 Content-Language: en

MIME тип text/html является нормальным выбором для HTML файлов. Браузер который получает файл с этим MIME типом будем считать, что разметка наследует синтаксис HTML и будет использовать анализатор (парсер) HTML для того, чтобы интерпретировать значение разметки.

В отличие от HTML, XHTML — это язык разметки, который базируется на основе XML. Синтаксис XML немного отличается от HTML, а также XML процессоры будут более требовательными, в том случае, если вы ошибетесь. Разработка контента на основе XML требует корректности и достоверности, и может быть легко интегрирована со всеми инструментами обработки, данными и автоматизацией, которые доступны в XML. Через меньшие требования к редактированию и обработке документов, многие разработчики предпочитают использовать XHTML, а не XML.

Для отправки в браузер разметки XHTML с MIME типом, указывающим, что это XML вы должны использовать один из следующих MIME типов: application/xhtml+xml , application/xml или text/xml . W3C рекомендует, чтобы вы обслуживали XHTML как XML используя только первый из этих MIME типов — то есть application/xhtml+xml .

Когда браузер читает XML он использует XML анализатор (парсер), а не HTML анализатор (парсер).

К сожалению, Internet Explorer до 8-й версии не поддерживает файлы, которые обслуживаются, как XML, пусть и ряд других браузеров поддерживают. Чтобы обойти тот факт, что не все браузеры поддерживают контент, который обслуговуютеся как XML, сейчас много XHTML файлов обслуживаются с использованием такого MIME типа, как text/html . В этом случае, клиентское приложение будет читать файл, как будто это HTML файл, а также будет использовать анализатор (парсер) HTML.

Так как браузер считает, что XML в действительности должна быть HTML, то при написании кода XHTML, чтобы гарантировать то, что различия между XML и HTML синтаксисом не собьют с толку браузер вы должны принять во внимание некоторые различия между этими двумя форматами. Это включает в себя различные способы назначения кодировки символов или назначения языка внутри документа.

Appendix C с XHTML спецификации предоставляет немного информации, по обеспечению совместимости при обслуживании XHTML как HTML. Эта информация, по обеспечению совместимости особенно важна для устаревших версий браузеров. Между прочим они рекомендуют, чтобы вы оставляли пробел перед ‘/>’ в конце пустого тэга (как например img , hr или br ), чтобы вы использовали HTML атрибут lang , а также XML атрибут xml:lang , чтобы вы всегда использовать оба атрибуты id и name для идентификаторов фрагмента и т.д.

Режим ‘Standards’ или ‘Quirks’

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

В последних версиях основных браузеров, режим standards включен за счет наличия . Отсутствие DOCTYPE может привести к различной выдачи в разных браузерах.

Нижеприведенные снимки экрана иллюстрируют некоторые из этих различий.

Изображение такого же файла что отображается в режиме quirks.

Нажмите на картинку, чтобы увидеть фактическую HTML страницу. Если вы просматриваете эту страницу в Internet Explorer, то вы увидите такой же эффект.

Две картины показывают две страницы с одинаковой разметкой и CSS стилизацией, за исключением одной вещи. Единственное отличие между этими двумя файлами — изображение, находящееся слева имеет тэг DOCTYPE в верхней части, а другое изображение его не имеет. Файл с соответствующим назначением DOCTYPE, в последних версиях большинства браузеров, как правило, отображается в режиме standards. При отсутствии DOCTYPE, вы получите режим quirks.

Показанные выше внешние отличия вытекают из следующих отличий в реализации такого браузера, как Internet Explorer:

В режиме standards настройки ширины CSS, которые применяется к тэге div не охватывают ни один набор ширин для настроек отступов (padding) и границ (border), в то время как в режиме quirks охватывают — именно поэтому большое окно на левой картинке (режим standards) шире.
В режиме quirks таблица не наследует настройки размера шрифта от элемента body, поэтому текст выглядит большим.

Первоначальная цель использования DOCTYPE — указание определение языка разметки. Ниже приведен исходный текст с назначением DOCTYPE в верхней части (что выделено красным курсивом).

   XHTML document body < background: white; color: black; font-family: arial, sans-serif; font-size: 12px; >p < font-size: 100%; >h1 < font-size: 16px; >div < margin: 20px; width: 170px; padding: 50px; border: 6px solid teal; >table Тестовый файл для режимов Standards/Quirks
 Тэг div из CSS width:170px, margin:20px, padding:50px and border:6px.
 Текст в элементе p.
 Текст в таблице.

Браузеры, которые таким образом меняют режимы standards и quirks часто предлагают сделать .

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

Назначения XML и DOCTYPEs

Существует один аспект использования DOCTYPEs, что особенно важно для назначения кодировки символов и предполагаемых результатов моделирования.

Поскольку XHTML 1.0 основана на XML, то XML назначение можно добавить в начале разметки, даже если она обслуживается как HTML. Это сделало бы верхнюю часть вышеприведенного файла, похожим на это (XML назначение выделяется красным курсивом):

В таких браузерах, как Internet Explorer 7, Firefox, Safari, Opera, Google Chrome, и других, с или без XML назначения, страница, обслуживаемая с назначением DOCTYPE будет отображаться в режиме standards.

Однако, в Internet Explorer 6, если перед назначением DOCTYPE не появляется ничего, кроме byte-order mark (метки порядка байтов), то страница отображается в режиме quirks.

Если пользователи Internet Explorer 6 и до сих пор являются в значительной частью вашей целевой аудитории, то это может быть проблемой. Если вы хотите убедиться, что ваши страницы в Internet Explorer 6 отображаются так же, как и во всех других standards-compliant (совместимых стандарту) браузерах, то вы должны тщательно подумать над тем, как вам с этим справиться.

Очевидно, что это не является проблемой, когда документ не содержит никаких конструкций, которые зависят от разницы между режимами standards и quirks. Кроме того, если это не так, то для преодоления различий вам придется добавить обходные пути к вашей CSS, или пропустить XML назначения.

Отметим, что если вы примете решение пропустить XML назначение, то в качестве кодировки страницы вы должны выбрать или UTF-8 или UTF-16. (Дополнительные сведения о влиянии на назначения кодировки смотрите Назначение кодировки символов в HTML .)

Дополнительные материалы

Медиа Типы XHTML
XHTML™ 1.0 Расширяемый Язык Разметки Гипертекста , C. HTML Руководство Совместимости
Список действительных DTDs (Определений Типов Документа), которые вы можете использовать в документе
Переключение Doctype в Internet Explorer
Совместимость Каскадных Таблиц Стилей с Internet Explorer 7
Переключение Doctype в Mozilla
Переключение Doctype в Opera
Пособие – Обработка кодировок символов в HTML и CSS

width

The width CSS property sets an element’s width. By default, it sets the width of the content area, but if box-sizing is set to border-box , it sets the width of the border area.

Try it

The specified value of width applies to the content area so long as its value remains within the values defined by min-width and max-width .

If the value for width is less than the value for min-width , then min-width overrides width .
If the value for width is greater than the value for max-width , then max-width overrides width .

Syntax

/* values */ width: 300px; width: 25em; /* value */ width: 75%; /* Keyword values */ width: max-content; width: min-content; width: fit-content; width: fit-content(20em); width: auto; /* Global values */ width: inherit; width: initial; width: revert; width: revert-layer; width: unset;

Values

Defines the width as a distance value.

Defines the width as a percentage of the containing block’s width.

The browser will calculate and select a width for the specified element.

The intrinsic preferred width.

The intrinsic minimum width.

Use the available space, but not more than max-content, i.e min(max-content, max(min-content, stretch)) .

Uses the fit-content formula with the available space replaced by the specified argument, i.e. min(max-content, max(min-content, )) .

Accessibility concerns

Ensure that elements set with a width aren’t truncated and/or don’t obscure other content when the page is zoomed to increase text size.

MDN Understanding WCAG, Guideline 1.4 explanations
Understanding Success Criterion 1.4.4 | W3C Understanding WCAG 2.0

Formal definition

Initial value	auto
Applies to	all elements but non-replaced inline elements, table rows, and row groups
Inherited	no
Percentages	refer to the width of the containing block
Computed value	a percentage or auto or the absolute length
Animation type	a length, percentage or calc();

Formal syntax

width =
auto |
|
min-content |
max-content |
fit-content( )

=
|

Examples

Default width

p.goldie  background: gold; >

p class="goldie">The Mozilla community produces a lot of great software.p>

Example using pixels and ems

.px_length  width: 200px; background-color: red; color: white; border: 1px solid black; > .em_length  width: 20em; background-color: white; color: red; border: 1px solid black; >

div class="px_length">Width measured in pxdiv> div class="em_length">Width measured in emdiv>

Example with percentage

.percent  width: 20%; background-color: silver; border: 1px solid red; >

div class="percent">Width in percentagediv>

Example using «max-content»

p.maxgreen  background: lightgreen; width: intrinsic; /* Safari/WebKit uses a non-standard name */ width: -moz-max-content; /* Firefox/Gecko */ width: -webkit-max-content; /* Chrome */ width: max-content; >

p class="maxgreen">The Mozilla community produces a lot of great software.p>

Example using «min-content»

p.minblue  background: lightblue; width: -moz-min-content; /* Firefox */ width: -webkit-min-content; /* Chrome */ width: min-content; >

p class="minblue">The Mozilla community produces a lot of great software.p>

Specifications

Specification
CSS Box Sizing Module Level 4 # width-height-keywords
CSS Box Sizing Module Level 4 # sizing-values

Browser compatibility

BCD tables only load in the browser

MDN

Support

Product help
Report an issue

Our communities

Developers

Web Technologies
Learn Web Development
MDN Plus
Hacks Blog

Website Privacy Notice
Cookies
Legal
Community Participation Guidelines

Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2023 by individual mozilla.org contributors. Content available under a Creative Commons license.

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

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

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

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

Your title
 Introductory paragraph.
 Lorem ipsum dolor sit amet, consectetur adipiscing elit…

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

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

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

Your title
 Introductory paragraph.
 Lorem ipsum dolor sit amet, consectetur…

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

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

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

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

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

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

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

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

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

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

 img Your title
 Introductory paragraph.
 Lorem ipsum dolor sit amet, consectetur…

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

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

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

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

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

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

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

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

.img-container < position: relative; padding-bottom: 56.25%; /* соотношение 16:9 */ height: 0; overflow: hidden; >.img-container img

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

Она требует ручного расчёта и перевода в проценты значения (например, для соотношения 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
Ленивой загрузкой
Не изображениями

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».

Подробнее в заметке на Reddit

Атрибут width

Устанавливает ширину линии в процентах или пикселах. При использовании процентов за 100% берется ширина родительского элемента. Как правило, в качестве родителя выступает окно браузера.

Синтаксис

Значения

Любое допустимое значение в пикселах или процентах.

Значение по умолчанию

Аналог CSS

Валидация

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

HTML 4.01 IE Cr Op Sa Fx

Тег HR, атрибут width

Результат данного примера показан на рис. 1.

Вид линий разной ширины

Рис. 1. Вид линий разной ширины

Не выкладывайте свой код напрямую в комментариях, он отображается некорректно. Воспользуйтесь сервисом cssdeck.com или jsfiddle.net, сохраните код и в комментариях дайте на него ссылку. Так и результат сразу увидят.