Делая вещи лучше

В 2019 году я выступил с докладом в разделе «Отдельное событие» о своих идеях и опасениях относительно веб-платформы. Этот пост является письменной версией этого разговора.

Вы можете посмотреть видео выступления на веб-сайте An Event Apart, а также найти слайды и ресурсы в Интернете по адресу Notist.

Переосмысление технических возможностей CSS

Мне посчастливилось быть приглашенным стоять на сцене An Event Apart и говорить о CSS более трех лет. За это время наше понимание и возможности CSS Layout были полностью переписаны. Участники «Событий друг от друга» стали свидетелями того, как это изменение стало частью волнения.

Более 15 лет мы использовали поплавки в качестве основного метода компоновки. Это использование теперь смирилось с историей.

События последних нескольких лет не менее драматичны в связи с переходом от таблиц к макету в CSS.

«Веб-дизайн без таблиц»

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

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

Многие веб-сайты на протяжении более десяти лет черпали вдохновение в таких проектах, как тема минимума Дуга Боумена для Blogger.

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

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

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

Мы взломали проблему

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

Введите flexbox, а затем Grid и тот факт, что align-items имеет начальное значение stretch и проблема не только исчезла, но поведение этих методов макета по умолчанию было с чем мы долго боролись.

Насколько велика эта коробка?

Но дело не только в том, какой высокий рост, а в общем, насколько он большой. Мы приобрели новые возможности оценивать вещи в зависимости от их размера. Мой доклад в 2018 году в разделе «Событие отдельно» опубликован в виде видео, и в этом выступлении я раскрыл некоторые сложности, связанные с определением размеров в новом макете.

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

Лучшие способы остановить контент, просто «гудя из коробки»

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

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

Возможно, вам нужна коробка фиксированной ширины, но не стоит возражать, если она станет выше. В этом случае используйте overflow-wrap: break-word .

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

Вертикально потрясающе

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

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

Flexbox и CSS Grid принесли с собой независимый подход к режиму написания документа

Впервые мы должны были думать о начале и конце, а не о левом и правом, верхнем и нижнем. Этот независимый подход проявляется в выравнивании, а также в линейном и автоматическом размещении в сетке. На самом деле, в моем раннем выступлении в Grid, которое вы бы увидели, если бы пришли в An Event Apart в конце 2015 или 2016 года, я упомянул, что если вы установите все четыре строки, используя свойство grid-area порядок строк был не знакомым вверху справа внизу слева от настройки сокращения поля, а вместо этого — в горизонтальном режиме — вверху слева внизу справа. Обратный порядок.

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

Логические свойства и значения

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

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

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

Поэтому, если мы дадим нашему удивительному мему встроенный размер минимального содержимого, когда мы будем крутиться горизонтально, встроенный размер будет идти горизонтально. Чтобы быть удивительным по вертикали, размер строки работает вертикально.

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

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

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

Сетка и подсетка

Прежде чем больше думать о постраничных носителях, я хотел немного подумать о проблеме, которая в настоящее время решается. Я думаю, что большинство людей согласятся с тем, что CSS Grid Layout был самым большим решением проблем за последние несколько лет, впервые предоставив нам реальную систему макетов для Интернета. Отодвигая нас от взлома плавающих макетов для создания основанных на сетке проектов.

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

Проблема, однако, заключается в том, что мы добавляем дополнительный текст к заголовку. Он становится выше, чем другие предметы, и эффект симпатичных выровненных коробок уменьшается. Мы не можем выстроить заголовки, потому что эти вложенные сетки не знают друг о друге и насколько велика каждая подпись. Звучит знакомо?

Это верно. Мы никогда не знаем, какой высокий рост в сети .

Нам нужен способ попросить вложенную сетку использовать дорожки, определенные на родительском элементе. Таким образом, подписи могут быть в одном ряду. Изменение размера одного заголовка изменило бы высоту всего ряда, взяв другие заголовки вместе с ним. Именно это дает нам значение подсетки для grid-template-columns и grid-template-row . Вы можете увидеть это действие в CodePen ниже, если вы используете Firefox. Firefox в настоящее время является единственным браузером, поддерживающим подсетку. Если вы хотели бы видеть его в Chrome, не мешало бы отметить эту ошибку, чтобы показать свою поддержку.

Суть в том, что когда вы начнете проектировать с этими новыми методами макета, вы столкнетесь с другими проблемами. И знаете, это хорошо.

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

Мы просто пока не можем этого сделать

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

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

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

Если мы можем вернуться к моему примеру трех страниц галереи изображений. Что произойдет, если я захочу поместить текст в одно из этих полей? Это сетка, поэтому область может принимать текст, а не изображение. Однако, если мы получим больше содержимого, чем строка фиксированного размера примет, мы получим переполнение. Единственный способ исправить это — увеличить размер моей дорожки до автоматического размера, и тогда я потеряю свой красивый эффект постраничного вывода, потому что я не могу быть уверен, что мои строки увеличатся до 100vh. Мы вернулись к нашей той же проблеме, мы не знаем, насколько высокие вещи в Интернете. Здесь день сурка.

Переполнение и Multicol

Как мы можем решить эту проблему? Мы можем начать с рассмотрения переполнения в multicol. Столбцы CSS ведут себя по-разному в зависимости от того, находимся ли мы в Paged Media, например в книге или на печатной веб-странице, или в Continuous Media, то есть в Интернете. Эти вещи действительно относятся к тому, что происходит с переполнением контента. Когда у вас будет больше контента, чем уместится на странице в Paged Media, будет создана новая страница. Когда в итоге вы получаете больше контента, чем умещается на экране в Continuous Media, вы получаете полосу прокрутки и можете прокрутить вниз, чтобы просмотреть больше контента.

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

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

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

Изображение на «Можно ли использовать» выше было получено до того, как Edge перешел в Chromium. В Edge была реализована Regions, и поэтому я смог записать следующее видео, демонстрирующее, как Regions работали с моим макетом сетки.

Текст представляет собой одну непрерывную тему. Он заполняет коробки по очереди. Сначала заполняем коробку 1, затем коробку 2 и переходим на коробку наполнения 3.

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

Но что произойдет, если контента будет больше, чем могут вместить эти три поля, или пользователь увеличил размер шрифта? Это верно — мы переполнены, потому что вы никогда не знаете, насколько большие вещи в Интернете. Регионам нужно куда-то, чтобы контент уходил. Вы должны создать стек избыточных элементов для хранения контента, который может или не может быть получен, во-вторых, предполагая, что контент имеет достаточно макета и не слишком много. По всей вероятности, используя JavaScript, можно решить это и создать достаточно элементов.

У нас не было возможности делать что-то наподобие того, что мы можем делать в Paged Media, не было способа объявить, что мои страницы или компоненты выглядят так, пожалуйста, создайте столько, сколько вам нужно, и поместите содержимое в эти коробки.

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

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

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

Как и в случае с переполнением размерности блока для multicol, я думаю, что это также связано с переполнением. Веб-дизайн всегда был битвой против переполнения, против того факта, что мы никогда не оцениваем, насколько высоким (или большим в измерении блоков) является что-либо в Интернете.

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

Веб-дизайн — это в основном борьба с переполнением.

Регионы проложили путь к чему-то лучшему?

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

Делать вещи лучше

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

На «Отдельном событии» я поговорил с Робом о проблеме, которая у него была с Гридом. Он хотел иметь возможность плавать на предметах, но все же попросил их использовать сетку.

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

Теперь Роб видел это как проблему с сеткой. Он написал это как проблему с сеткой.

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

Мне удалось написать решение с некоторыми демонстрациями.

Что еще более важно, это дало мне отличный вариант использования, чтобы вернуться к Рабочей группе CSS, чтобы показать им реальную проблему, которую решают Исключения, чтобы посмотреть, сможем ли мы начать говорить об этом и решать проблемы в этой спецификации. so more browsers might implement it.

This is the sort of thing that anyone can do. Write up the things you can’t do – even guess at a solution – don’t worry if it isn’t the best solution. Figuring that out takes more than one mind most of the time – that’s why we have the CSS Working Group. But do show us. Don’t assume that because CSS doesn’t work like that now it can never work like that.

We have come so far in the last few years. The last thing I want, is for it to stop now.

Perhaps these first few years of grid, when we look back will look very grid like, as we all got excited about being able to neatly line up our boxes. That’s great, lining up boxes is a useful thing to be able to do, but let’s not allow that to define our new technical limitations, and instead keep poking at the edges and asking what next, why can’t I do that? And we’ll keep pushing at the edges, and continue to break out of the technical limitations, making things better, faster, or yes just less weird.

And this was very nearly the end of this talk. But, when I was about to present this in San Francisco for the first time something happened that I think backs up the importance I place on more people having input into the web platform.

I woke up, to the rumors that were later confirmed that Microsoft were dropping their rendering engine EdgeHTML in favour of using Chromium. And I feared that we were heading right back to the days where one browser had over 95% market share. Where one browser could quite literally dictate the direction of the web.

Many of the things I have talked about, Exclusions and Regions for example, were implemented by the Microsoft team. No, not in a perfect finished way, but enough for us to be able to experiment. Enough for us to try them out. Grid Layout was first implemented by the Microsoft Team in IE10. No, it wasnt perfect, essentially a prototype for what was to come, but it enabled people to experiment. I probably wouldn’t be known as the CSS Grid person if it hadn’t been for that implementation allowing me to start to work with the spec.

Fewer browsers mean fewer experiments. Mean fewer places where things can start to evolve. When I first gave this talk, I said I was absolutely sure that the excellent people on the Microsoft browser team, people who I would call my friends, good people, good engineers, true standards advocates would do great work on Chromium. That has already played out to be true. But ultimately, it’s a single rendering engine and is driven by the needs of Google.

And, if we are not to have diversity in rendering engines then we need to double down on making sure that there is diversity of thought involved in the standards process.