csdn怎么让代码变得好看
In 2019 I presented a talk at An Event Apart about my ideas about and fears for the web platform. This post is a written version of that talk.
在2019年，我在An Event Apart上发表了关于我对Web平台的想法和恐惧的演讲。 这篇文章是该演讲的书面版本。
You can see the video of the talk on the An Event Apart website, and also find the slides and resources online at Notist.
您可以在An Event Apart网站上观看演讲视频 ，也可以在Notist在线找到幻灯片和资源 。
重新定义CSS的技术可能性 (Redefining the technical possibilities of CSS)
I have been fortunate enough to be invited to stand on the An Event Apart stage and talk about CSS for over three years now. Over that time our understanding of and abilities with CSS Layout has been totally rewritten. The An Event Apart attendees have witnessed that change, been part of the excitement.
我很幸运地被邀请参加An Event Apart舞台，谈论CSS已有三年多了。 在那段时间里，我们对CSS Layout的理解和功能已被完全重写。 An Event Apart的与会者见证了这一变化，这是兴奋的一部分。
We had been using floats as our primary layout method for over 15 years. That usage is now being resigned to history.
超过15年以来，我们一直将花车用作主要的布局方法。 现在，该用法已被废弃到历史记录中。
The happenings of the last few years being no less dramatic of the move away from tables for layout to CSS.
过去几年中发生的事情同样令人震惊，从表的布局转移到CSS。
“无桌网页设计” (“Tableless web design”)
If we think about tables to CSS for a moment though. That move was difficult because we asked people to limit their designs in many ways. If we look at the table layouts of early websites, some of these were incredibly complex. They were designed in graphics design applications, sliced up into pieces and reassembled in complex table structures.
如果我们暂时考虑一下CSS表。 这一举动之所以困难，是因为我们要求人们以多种方式限制他们的设计。 如果我们看一下早期网站的表格布局，其中一些非常复杂。 它们是在图形设计应用程序中设计的，切成小块，然后重新组装成复杂的表格结构。
A move to CSS meant a simplification, as those complex designs were not possible to create using CSS alone, we just didn’t have the tools.
转向CSS意味着简化，因为那些复杂的设计无法仅使用CSS来创建，我们只是没有工具。
A lot of the web for over a decade drew inspiration from designs such as Doug Bowman’s Minima theme for Blogger.
十多年来，很多Web都从Doug Bowman的Blogger Minima主题等设计中汲取了灵感。
And this was no bad thing, I think that the move from table based designs to CSS heralded the start of us thinking about the web as it’s own medium, something which progressed with the idea of Responsive Web Design. Yes, we simplified, but we did so in order to enable great experiences for everyone.
这并不是一件坏事，我认为从基于表的设计到CSS的转变预示着我们开始考虑将Web作为其自身的媒介，这随着响应式Web设计的思想而发展。 是的，我们进行了简化，但是我们这样做是为了为每个人提供出色的体验。
However we downplayed the problems. Us CSS advocates, those of us involved with the Web Standards Project. We weren’t looking to see how we could improve the platform and invent new CSS to solve problems, we were campaigning for browsers and web developers alike to comply with the standards that existed, to build accessible and cross platform websites, and to be happy with our lot.
但是我们淡化了这些问题。 我们CSS倡导者，我们当中那些参与Web标准项目的人。 我们不希望看到如何改善平台和发明新CSS来解决问题，我们正在为浏览器和Web开发人员开展运动，以遵守现有标准，建立可访问的跨平台网站并感到高兴。与我们很多 。
I keep coming back to this idea that what we see as good web design is rooted in the technical limitations of CSS2.
我一直回到这个想法，我们认为好的Web设计植根于CSS2的技术局限性 。
[I] accepted that CSS is just hacks over top of a document model that was never designed to be used like it is today.
[我]接受CSS只是文档模型之上的黑客，该文档模型从未像今天这样被使用过。
Bailey Ling 百利灵
I believe that the way many people see the web is still hobbled by the attitudes and limitations of those early days.
我相信，早期人们的态度和局限性仍然困扰着许多人浏览网络的方式。
Sometimes, an audience member or a reader will object to something I demonstrate. They tell me that, “the web is not print” deeming the technique to be too close to print design. Or, I will hear the idea that CSS is something of a failed medium, without any of the things we really need, and we have to just hack at it to get what we want.
有时，听众或读者会反对我展示的内容。 他们告诉我，“网络无法打印”，认为该技术与印刷设计过于接近。 或者，我会听到这样的想法，即CSS是一种失败的媒介，没有我们真正需要的任何东西，我们只需要破解它就可以得到我们想要的东西。
Yet times have changed.
然而时代变了 。
In this article I want to show you the problems we have solved, the problems we are solving, and also point at the problems we haven’t yet solved. Because I not only want you to understand new CSS, use it, create beautiful things, and practical things, solve the problems of your site visitors in ever more elegant ways.
在本文中，我想向您展示我们已经解决的问题，我们正在解决的问题，并指出我们尚未解决的问题。 因为我不仅希望您了解新CSS，使用它，创建漂亮的东西，而且还有实际的东西，以更加优雅的方式解决站点访问者的问题。
I also want you to be empowered to contribute to solving the new problems that we hit. I want you to know that is possible, and to walk with me to remove even more of the technical limitations of CSS.
我也希望您有能力为解决我们遇到的新问题做出贡献。 我希望您知道这是可能的，并与我同行消除CSS的更多技术限制 。
你永远都不知道网络上有什么东西 (You never know how tall anything is on the web)
“We can’t control the height of things”, I would explain to the designers I was working with who would produce a design which relied on the height of things being known.
“我无法控制事物的高度”，我将向与我合作的设计师解释，谁将根据已知的事物的高度进行设计。
A design as simple as this one. Three boxes, different amounts of content, but we want the bottoms of those boxes to line up. Not so many years ago this was impossible, because a floated layout had no way to line up the bottom of the boxes.
如此简单的设计。 三个盒子，内容不同，但是我们希望这些盒子的底部对齐。 并不是很多年前，这是不可能的，因为浮动的布局无法对齐盒子的底部。
So we would fix the height, based on an assumed amount of content. And, when too much content was added, and poked out the bottom of the box we would look to our CMS, see if there was a way to prevent too much content getting in.
因此，我们将根据假定的内容量确定高度。 而且，如果添加了太多内容，然后跳出框的底部，我们将查看CMS，看看是否存在防止过多内容进入的方法。
I have a CMS product. I still get people asking how to do this for this very reason.
我有CMS产品。 出于这个原因，我仍然有人问我该怎么做。
我们解决了这个问题 (We hacked around the problem)
Designs were created that hid the issue, a gradient that faded away and hid the fact that the boxes were uneven heights, avoiding background colors altogether, the faux columns technique of the past. A technical limitation influencing design, and even sometimes our content.
创建的设计隐藏了这个问题，渐变消失了，并且隐藏了盒子高度不均匀的事实，完全避免了背景色，这是过去的人造柱技术。 影响设计的技术限制，有时甚至影响我们的内容。
Enter flexbox and then Grid and the fact that align-items has an initial value of stretch and the problem not only disappeared, but the default behaviour of these layout methods was the thing we struggled with for so long.
输入flexbox，然后输入Grid，然后align-items的初始值就是stretch ，问题不仅消失了，而且这些布局方法的默认行为也是我们长期以来一直在努力的事情。
这个盒子有多大？ (How big is that box?)
But it isn’t just about how tall the thing is, but in general how big it is. We’ve gained new abilities to size things based on how big they are. My talk in 2018 at An Event Apart is online as a video, and in that talk I unpacked some of the complexity of sizing in new layout.
但这不仅关乎事物的高度，而且还关乎事物的大小。 我们已经获得了根据事物的大小来确定事物大小的新功能。 我在2018年在An Event Apart上发表的演讲是作为视频在线播放的 ，在那次演讲中，我讲解了新布局中调整大小的一些复杂性。
And we think we know a lot about sizing because to make those floated layouts work we have to give everything a width, and make sure that the total width across the container – including margins used for gutters - doesn’t add up to more than 100%
而且我们认为我们对尺寸调整有很多了解，因为要使这些浮动的布局正常工作，我们必须给所有宽度都设置宽度，并确保容器上的总宽度（包括装订槽的边距）加起来不超过100 ％
This means that to make a responsive design, we end up using a lot of media queries to change the size at various breakpoints. For when the box gets too small for the contents suboptimal things occur, we get the CSS is Awesome problem, or the floated layout starts to fall apart.
这意味着要进行响应式设计，我们最终会使用大量媒体查询来更改各个断点的大小。 因为当框变得太小而无法容纳内容时，发生了次优的事情，我们得到了CSS令人敬畏的问题，或者浮动布局开始崩溃。
This obsession with setting the width of things resulted in everyone believing that Flexbox should behave in the same way as floats. We find Flexbox grid systems which set the width of things exactly as we did for float-based systems. And, the fact that flex items sometimes seem to end up an unusual size is quoted in various articles as being a failure on the part of flexbox, it behaves weirdly, it isn’t intuitive.
对设置宽度的痴迷使每个人都认为Flexbox的行为应与float相同。 我们发现Flexbox网格系统的设置宽度与基于浮动系统的设置完全相同。 而且，在各种文章中都引用了flex项目有时看起来不正常的事实，这是flexbox的失败，它的行为很怪异，不直观。
No, it just isn’t the layout method you think it is.
不，这不是您认为的布局方法。
If you think flexbox is for lining things up with other things then yes, it seems weird and badly behaved. Once you realise it is for taking a bunch of oddly sized things and returning the most reasonable layout for those things it makes sense.
如果您认为flexbox是用于将其他事物排列在一起的，那么是的，这似乎很奇怪并且表现不好。 一旦意识到这是拿一堆大小不一的东西并为这些东西返回最合理的布局，这就是有道理的。
It does this by looking at the things and seeing how big they are then assigning space to give the best sort of layout for those items, rather than squashing a big thing into a tiny column and leaving loads of spare space around a tiny thing. In doing so, it solves the problem of needing to give everything a width and then change that width when the viewport changes because it works that out for you.
它通过查看事物并查看它们有多大然后分配空间来为这些项目提供最佳布局来做到这一点，而不是将一个大事物挤成一个很小的列，而在一个小事物周围留有备用空间。 这样，它解决了需要给所有内容一个宽度然后在视口更改时更改该宽度的问题，因为它可以为您解决问题。
It just blew my mind that someone thought the default behavior should be to just have the text honk right out of the box, instead of just making the box bigger.
这让我感到震惊，有人认为默认行为应该是直接将文本鸣号开箱即用，而不是仅仅使框变大。
Steven Frank 史蒂文·弗兰克
Staying with sizing, and the problem highlighted by the CSS is Awesome meme. What we really have here is an issue of overflow. You have made a fixed width container and are trying to put content into that container which is too big, what do you want CSS to do here?
保持大小不变，CSS突出显示的问题是Amesome meme。 我们这里真正遇到的是溢出问题。 您已经制作了一个固定宽度的容器，并试图将内容放入那个太大的容器中，您想CSS在这里做什么？
CSS by default will do what you see in the meme because to do anything else would cause data loss, which is CSS terms means that some of your content vanishes.
默认情况下，CSS将执行您在模因中看到的内容，因为执行其他任何操作都会导致数据丢失，这就是CSS术语，这意味着您的某些内容消失了。
We try and avoid data loss because if something on your page vanishes at certain screen sizes – because of overlap, or it going off the side of the screen, you may be unaware of it. A quick eyeballing of the page may not cause something missing to jump out at you. You will tend to spot the messy overflow though.
我们尝试避免数据丢失，因为如果页面上的某些内容在某些屏幕尺寸下消失了–由于重叠或从屏幕的侧面掉落，您可能没有意识到。 快速浏览该页面可能不会导致缺少某些内容跳到您的身上。 但是，您将倾向于发现凌乱的溢出。
A good example of this design pattern can be seen in the Box Alignment specification, with the safe and unsafe alignment keywords. Safe alignment, means that your chosen alignment method won’t be used if it causes data loss, unsafe means that data loss may happen.
在Box Alignment规范中可以看到该设计模式的一个很好的例子，其中包含安全和不安全的对齐关键字。 安全对齐，表示如果选择的对齐方式会导致数据丢失，则将不使用，不安全意味着可能会发生数据丢失。
In certain situations, your choice of alignment method could cause overflow that results in data loss, for example by pushing an item off the side of the viewport. If you use the keyword safe you are telling the browser that you would prefer a different alignment over data loss. The keyword unsafe declares that you want your chosen alignment even if it causes data loss. You can see these keywords in action in a supporting browser in the CodePen below.
在某些情况下，您选择的对齐方式可能会导致溢出，从而导致数据丢失，例如，将某个项目推离视口的侧面。 如果使用关键字safe ，则会告诉浏览器，与数据丢失相比，您希望使用其他对齐方式。 关键字“ unsafe声明您希望您选择的对齐方式，即使它会导致数据丢失。 您可以在下面的CodePen中的支持浏览器中查看这些关键字的运行情况。
Overflow happens, if you fix the size of things. By default CSS tries not to cause some of your information to vanish. If you want something else to happen then you need to declare that. And you have an increasing number of options.
如果确定大小，则会发生溢出。 默认情况下，CSS尝试不使您的某些信息消失。 如果您希望发生其他事情，则需要声明它。 而且您有越来越多的选择。
停止内容的更好方法只是“开箱即用” (Better ways to stop content just “honking out of the box”)
The author of the meme wondered why the box didn’t grow to fit the content. However if you give something a fixed size in CSS, it will respect that size. What the author really wanted was to make the box min-content sized. With a box that has a width of min-content the box will grow as big as it needs to be to contain the content, with all soft-wrapping opportunities taken, but no bigger.
该模因的作者想知道为什么盒子不适合内容。 但是，如果您在CSS中提供固定大小的内容，则会尊重该大小。 作者真正想要的是使盒子min-content 。 对于具有min-content宽度的框，该框将增长到容纳内容所需的大小，并且会占用所有软包装机会，但不会更大。
If instead, you want to make the box not wrap at all, then give it a width of max-content. The text will then display all as one line and take no soft-wrapping opportunities.
如果相反，您想使盒子根本不包裹，那么给它一个宽度max-content 。 然后，文本将全部显示为一行，并且没有换行的机会。
Perhaps you need to have the box that fixed width, but don’t mind if it grows taller. In that case use overflow-wrap: break-word.
也许您需要具有固定宽度的盒子，但不要介意它变得更高。 在这种情况下，请使用overflow-wrap: break-word 。
Take a look at the next CodePen for all your awesome possibilities.
查看下一个CodePen，了解您的所有超乎寻常的可能性。
垂直很棒 (Being awesome vertically)
A problem which perhaps many of us English speakers haven’t run into, is the fact that CSS had for any years a baked in assumption that we were all using a left to right top to bottom language. Essentially that we were all English speakers.
也许我们许多英语使用者尚未遇到的问题是，假设我们都使用从左到右从上到下的语言，那么CSS已经烤了几年。 本质上，我们都是讲英语的人。
However CSS has also updated to match the reality that worldwide many languages are not horizontal, and running left to right, but perhaps are horizontal and running right to left, or written vertically, or maybe even a mixture of the two. The Writing Modes specification details the different writing modes and allows us to switch between them, we can do so for creative reasons or, because we are typesetting a language which uses those writing modes.
但是CSS也进行了更新，以适应这样的现实：全球许多语言不是水平的，而是从左到右运行的，但是可能是水平的并且是从右到左运行的，或者是垂直编写的，甚至可能是两者的混合。 写作模式规范详细介绍了不同的写作模式，并允许我们在它们之间进行切换，这是出于创造性的原因，或者因为我们正在排版使用这些写作模式的语言而设计。
Flexbox and CSS Grid brought with them an agnostic approach to the writing mode of the document
Flexbox和CSS Grid带来了不可知论的文档编写方式
For the first time we had to think about start and end, rather then left and right, top and bottom. This agnostic approach is apparent in alignment, and also in line-based and auto placement in grid. In fact, in my early Grid talk, which you would have seen if you came to An Event Apart sometime in late 2015 or 2016, I mentioned that if you set all four lines using the grid-area property the order of the lines wasn’t the familiar top right bottom left of setting a margin shorthand, but instead - when in a horizontal writing - mode top left bottom right. The reverse of that order.
第一次，我们不得不考虑起点和终点，而不是左右，顶部和底部。 这种不可知的方法在对齐，网格中基于行的自动放置中很明显。 实际上，在我早期的Grid谈话中，如果您是在2015年末或2016年某个时候参加“活动分开”，您会看到，我提到如果您使用grid-area属性设置所有四行，则行的顺序不是t熟悉的右上角在设置边距速记的左下角，但是-在水平书写时-模式是左上角右下。 该顺序相反。
What that shorthand is doing is setting the block and inline start then the block and inline end, for as soon as your grid is not in horizontal-tb thinking about top, right, bottom, and left doesn’t make a lot of sense.
速记的操作是先设置块和内联开始，然后设置块和内联结束，因为一旦您的网格不在水平TB范围内，那么思考上，右，下和左就没有多大意义了。
逻辑属性和值 (Logical Properties and Values)
The problem then is that we have a situation where our main layout methods talk about start and end and inline and block, and everything else in CSS - floats, positioning, margins, padding and borders, all describe themselves in terms of physical dimensions.
然后的问题是，在这种情况下，我们的主要布局方法谈论开始和结束以及内联和块，而CSS中的其他所有内容-浮点数，位置，边距，边距和边框，都用物理尺寸来描述。
All this specification contains is a set of mappings, and additional shorthands that give us a way of defining things in a flow relative, logical way as opposed to the physical way we are used to. If I have a grid layout with a width but then use Writing Modes to switch to a vertical writing mode, the grid layout will all work in that writing mode. However the width remains tied to the horizontal measure, meaning that the shape of the grid changes.
本规范仅包含一组映射，以及一些其他速记，这些速记使我们可以用一种相对于逻辑的方式（相对于过去的物理方式）以流的方式定义事物。 如果我有一个具有一定宽度的网格布局，然后使用“书写模式”切换到垂直书写模式，则该网格布局将全部在该书写模式下工作。 但是，宽度仍然与水平度量相关，这意味着网格的形状会发生变化。
Instead of width I could use the new mapped property inline-size, representing the size in the inline direction. Which for a vertical writing mode is vertical not horizontal. This would mean that once in a vertical writing mode, the inline-size would control the height of the component and the entire grid would retain its dimensions.
我可以使用新的映射属性inline-size代替宽度来表示内联方向的大小。 对于垂直写入模式，哪个是垂直而不是水平。 这意味着一旦处于垂直书写模式， inline-size控制组件的高度，而整个网格将保留其尺寸。
Therefore if we give our awesome meme an inline-size of min-content, when we are being awesome horizontally, the inline-size runs horizontally. To be awesome vertically the inline-size runs vertically.
因此，如果我们给真棒模因一个最小内容的内联大小，则当我们水平很棒时，内联大小会水平运行。 要使竖向很棒，内联大小会垂直延伸。
There are mapping like these for pretty much all properties in CSS, and some values too. I’ve recently documented these over at MDN, MDN also has lots of live examples so you can play around with the different properties.
在CSS中几乎所有的属性都有这样的映射，还有一些值。 我最近在MDN上记录了这些内容 ，MDN还提供了许多实时示例，因此您可以试用不同的属性。
Browser support is improving with the mapped properties, and I mention this here, partly because I think ultimately these logical, flow relative properties will become our defaults but also in the context of problem solving. In creating CSS.
浏览器支持通过映射的属性而得到了改善，我在这里提到这一点，部分原因是我认为这些逻辑的，相对于流程的属性最终将成为我们的默认值，但同时也要解决问题。 在创建CSS。
An additional complexity for anything that we create in CSS is it needs to consider these writing modes. We’re not in the business of creating a better web just for horizontal language users. In fact, as I’ve looked into vertical writing more as a spec editor, I’ve realised what a wealth of interesting patterns emerge from people who use the written word in a different way to me.
我们在CSS中创建的任何内容的另一个复杂之处在于，需要考虑这些编写模式。 我们不仅仅为横向语言用户创建更好的网站。 实际上，当我以规范编辑人员的身份研究垂直写作时，我已经意识到，以与我不同的方式使用书面文字的人们会产生许多有趣的模式。
没有折痕 (There is no fold)
Clients ask us to have things above the fold, and we roll our eyes as we explain for the millionth time that there is no fold on the web, that people do know how to scroll. Once responsive design became a thing, this request seemed all the more frustrating. Which fold were they talking about? The one on a watch, a phone, or a giant desktop screen?
客户要求我们把事情摆在首位，然后，当我们向百万分之一解释说网络上没有折叠，人们确实知道如何滚动时，我们会roll之以鼻。 一旦响应式设计成为现实，这个要求就显得更加令人沮丧。 他们在说什么折叠？ 是手表，手机还是巨大的台式机屏幕？
The thing is, today we know exactly where the fold is. We can even engineer our designs to reflect on the size of the screen the user has.
关键是，今天我们确切地知道了折痕在哪里。 我们甚至可以设计我们的设计以反映用户的屏幕尺寸。
视口单位 (Viewport units)
Viewport units represent a portion of the height or width of the viewport. 100vw = 100% of the viewport width, so 1vw is 1% of the viewport width. 100vh is 100% of the viewport height. We can’t use percent, because that already means something in pretty much every part of CSS.
视口单位代表视口的高度或宽度的一部分。 100vw =视口宽度的100％，因此1vw是视口宽度的1％。 100vh是视口高度的100％。 我们不能使用百分比，因为这已经在CSS的几乎每个部分中都意味着含义。
Given that we know the size of the viewport, we can create designs which make use of the viewport. The bit that the user sees. Treating that space almost as if it were a page.
鉴于我们知道了视口的大小，我们可以创建利用视口的设计。 用户看到的位。 几乎像对待页面一样对待该空间。
My layout here is using CSS Grid Layout, and viewport units for track sizing. This means that I can size a screenful of images exactly to fit the desktop. I essentially have three pages of content, arranged using siz rows. The sizing of the rows and gap has been implemented using the vh unit, so that I end up with 100vh. I then get a nice paged effect as I move through my gallery. If you play with the demo you will also see I’m using the CSS Scroll Snap specification to snap from screen to screen of images. In a layout like this we see the lines between the continuous media of the web and the paged media of print converging in some ways. I’ll come back that point later.
我在这里的布局使用CSS Grid Layout和视口单位进行轨道大小调整。 这意味着我可以精确调整屏幕大小以适合桌面大小。 我基本上有三页内容，使用siz行排列。 行和间隙的大小已使用vh单位实现，因此我最终得到100vh 。 当我在画廊中移动时，我得到了很好的页面效果。 如果您在演示中玩游戏，您还将看到我正在使用CSS Scroll Snap规范在图像的屏幕之间进行捕捉。 在这样的布局中，我们看到了Web 连续介质和页面打印介质之间以某种方式汇合的线条。 我稍后再讲。
网格和子网格 (Grid and Subgrid)
Before thinking more about paged media, I wanted to think a little bit about a problem that is currently being solved. I think most people would agree that CSS Grid Layout has been the biggest problem solver of the last few years, giving us a real layout system for the web for the first time. Moving us away from hacking around floated layouts to build grid-based designs.
在进一步考虑分页媒体之前，我想对当前正在解决的问题进行一些思考。 我想大多数人都会同意CSS Grid Layout是最近几年最大的问题解决方案，这使我们第一次为网络提供了一个真正的布局系统。 让我们远离在浮动布局周围进行黑客攻击，以构建基于网格的设计。
A new problem appears however when we begin to really work with grid, we discover that one grid is not enough. I’ve got a different presentation of my gallery here, which uses grid layout and I have this time added some captions to the images. The overall layout here is a fairly straightforward grid, each individual image and caption is also a grid, by making the grid item a grid container and defining two row tracks. This enables me to stretch the image over two tracks, and place the caption in the second track.
然而，出现了一个新问题，当我们开始真正使用网格时，我们发现一个网格是不够的。 我在这里有一个不同的画廊展示，它使用网格布局，这次我为图像添加了一些标题。 这里的总体布局是一个相当简单的网格，每个单独的图像和标题也是一个网格，通过将网格项变成网格容器并定义两个行轨迹。 这使我可以将图像拉伸到两条轨道上，并将标题放在第二条轨道上。
The problem we have however is if we add additional text to the caption. It becomes taller than the other items and the effect of nice lined up boxes is diminished. We can’t line the captions up because those nested grids don’t know about each other and how big each caption is. Sound familiar?
但是，我们遇到的问题是，如果我们在标题中添加其他文本。 它比其他物品高，并且排列好的盒子的效果减弱了。 我们无法将标题对齐，因为这些嵌套的网格彼此之间不了解，也不知道每个标题的大小。 听起来有点熟？
That’s right. We never know how tall anything is on the web.
那就对了。 我们永远不知道网络上有什么东西 。
What we need is a way to ask the nested grid to use tracks defined on the parent. That way the captions could be in the same row. A change to the size of one caption would then change the height of the entire row, taking the other captions with it. This is exactly what the subgrid value of grid-template-columns and grid-template-rows gives us. You can see this is action in the CodePen below, as long as you use Firefox. Firefox is currently the only browser to support subgrid. If you would like to see it in Chrome, it wouldn’t hurt to go star this bug to show your support.
我们需要一种让嵌套网格使用在父级上定义的轨道的方法。 这样，字幕可以在同一行中。 更改一个字幕的大小将更改整个行的高度，同时使用其他字幕。 这正是grid-template-columns和grid-template-rows的subgrid值所提供的。 只要您使用Firefox，就可以在下面的CodePen中看到此操作。 Firefox是当前唯一支持子网格的浏览器。 如果您希望在Chrome浏览器中看到它，请为该bug加上星标以表示支持是没有坏处的。
The point it, that as you start to design with and for these new layout methods you will hit other problems. And do you know, that’s a good thing.
关键是，当您开始使用这些新的布局方法进行设计时，还会遇到其他问题。 而且你知道吗，那是一件好事。
Don’t fall into the trap, of becoming excited about all the new things, and when someone points out something you can’t do, perhaps scoffing, oh you think grid is so great but look, it can’t do this, feeling you need to defend it, perhaps explaining that this isn’t a limitation, the web doesn’t work like this, the web is not print, or perhaps the web is not native, or whatever ….
不要落入陷阱，成为激励所有的新事物，当有人点了一些东西你不能这样做，也许是嘲笑，哦，你认为电网是如此之大，但看起来，它不能做到这一点 ，感觉您需要捍卫它，也许要说明这不是一个限制，网络不能像这样工作，网络不是打印的，或者网络不是本机的，等等。
我们只是不能这样做， 但 (We just can’t do that yet)
We get to do it, by finding the use cases, explaining them, writing them up. Pointing to other media and asking whether we can do that thing on the web in an elegant and performant manner. We get this stuff because we create this stuff.
我们通过找到用例，对它们进行说明，编写来做到这一点。 指向其他媒体并询问我们是否可以以优雅而高效的方式在网络上进行该操作。 我们得到这些东西是因为我们创建了这些东西。
Not just me, or the CSS Working Group, or the browsers, or the folk from print user agents or EPUB. All of us.
不只是我，CSS工作组，浏览器，还是印刷用户代理或EPUB的同事。 我们所有人
So here are my edges, the things I want to be able to do. Things I think we’re sort of close to, and where more use cases and more thinking might just help to push them over the line.
这就是我想要做的事情，这是我的优势。 我认为事情已经接近完成，更多的用例和更多的思考可能只会帮助他们克服困境。
If we can back to my example of three pages of gallery images. What would happen if I wanted to put text into one of those boxes? It’s a grid layout, so the area can accept text rather than an image. However, if we end up with more content than the fixed size row will accept we get overflow. The only way to fix that is to make my track expand to auto size, and I then lose my nice paged effect because I can’t be sure that my rows will add up to 100vh. We are right back to our same problem, we don’t know how tall things are on the web. It’s like groundhog day here.
如果可以回到我的三页画廊图像示例。 如果我想在其中一个框中输入文字会怎样？ 它是网格布局，因此该区域可以接受文本而不是图像。 但是，如果最终得到的内容多于固定大小的行将接受的内容，则会溢出。 修复此问题的唯一方法是使音轨扩展到自动大小，然后我失去了很好的分页效果，因为我不确定我的行总和为100vh。 我们回到了同样的问题，我们不知道网络上有多少东西。 就像这里的土拨鼠日。
溢出和Multicol (Overflow and Multicol)
How might we solve this problem? We can start by taking a look at overflow in multicol. CSS Columns behave differently in a few ways depending on whether we are in Paged Media, such as a book or a printed webpage, or in Continuous Media which is what we are on the web. These things really refer to what happens with overflowing content. When you end up with more content than will fit on a page in Paged Media, a new page is created. When you end up with more content than will fit on a screen in Continuous Media you get a scrollbar and can scroll down to view more content.
我们如何解决这个问题？ 我们可以先看一下multicol中的溢出。 CSS列的行为在某些方面有所不同，具体取决于我们是在页面媒体（例如书本还是印刷网页）中还是在我们在网络上的连续媒体中。 这些东西实际上是指内容溢出时会发生什么。 如果最终您获得的内容超出页面媒体中页面的容纳量，则会创建一个新页面。 当您最终获得的内容超出了Continuous Media屏幕中显示的内容时，您将获得一个滚动条，并且可以向下滚动以查看更多内容。
In multicol on the web, if you have more content than fits on the screen the columns just get longer and longer. Eventually you have to scroll up and down to read the content, which is a terrible reading experience, and the reason people tend not to use multicol on the web.
在网络上的multicol中，如果您的内容超出了屏幕显示的范围，则列会越来越长。 最终，您必须上下滚动才能阅读内容，这是一种糟糕的阅读体验，也是人们倾向于不在网络上使用multicol的原因。
If you fix the height of the container, to prevent the up and down scrolling thing, the overflow columns are created in the inline direction. You will end up with a horizontal scrollbar. Again, there might be some use cases for this but I don’t want to do a horizontal scrolling thing very often.
如果您固定了容器的高度，为防止上下滚动，将在嵌入式方向上创建溢出列。 您将最终得到一个水平滚动条。 再次，可能会有一些用例，但是我不想经常做水平滚动。
So let’s assume I’m not a maverick and want to stick with scrolling in the block dimension. What if you could say I want my multicol container to be so high - perhaps 100 viewport height high AND if there is more columns, create another 100 vh box in the block dimension and fill it with columns. Keep on doing that until you run out of columns.
因此，假设我不是特立独行者，并且想坚持使用块尺寸滚动。 如果您可以说我希望我的multicol容器如此之高-也许高100视口高度，并且如果有更多列，则在块尺寸中创建另一个100 vh框，并用列填充它。 继续这样做，直到用完所有列。
How useful would that make multicol? I think that would be excellent, and this idea of overflow in the block dimension is something we are considering for a Level Two of the multicol specification.
这会使multicol有用吗？ 我认为那将是极好的，并且对于multicol规范的第二级，我们正在考虑这种块尺寸溢出的想法。
Multicol doesn’t quite solve my problem, as even with block dimension overflow I would need space for those columns to go.
Multicol并不能完全解决我的问题，因为即使发生块维溢出，我也需要为这些列留出空间。
What I really want here is to be able to have some marked up content, and instead of having to work out how much can go in each box, and break it up into sections somehow, and stick some in each container, I want to let the browser deal with it.
我真正想要的是能够具有一些标记的内容，而不是必须弄清楚每个盒子中可以放入多少，然后以某种方式将其分成几部分，然后在每个容器中粘贴一些，我想让浏览器处理它。
Hey browser, this content can go into any of these boxes. Fill them up!
嘿，浏览器，此内容可以放入任何这些框中。 填满它们！
分页媒体 (Paged Media)
We already have places where CSS has come close to this idea. If we start with Paged Media. It often comes as a surprise to people how much usage there is of CSS for print and other paged media such as EPUB, when we talk about paged media we are talking about any of these things. There are user agents which turn HTML and CSS into a print ready PDF.
我们已经有CSS接近这个想法的地方。 如果我们从分页媒体开始。 人们通常会感到惊讶，当我们谈论页面媒体时，我们谈论的是这些东西，而印刷和其他页面媒体（例如EPUB）在CSS方面的使用率却很高。 有些用户代理会将HTML和CSS转换为可打印的PDF 。
You need to use a specific user agent for print when you work with paged media, browsers support a very small subset of the tools that you get with a user agent such as Prince.
使用分页媒体时，需要使用特定的用户代理进行打印，浏览器支持用户代理（如Prince）获得的工具的很小一部分。
When creating a PDF either to use as a PDF or for print, you have the concept of a page box, which defines a physical page with a size. You can add things into the header and footer area of each page box, target left and right pages individually. You can insert content - using Generated Content - into the margin boxes of the page. Then, when you add your content, enough pages will be created to hold the content. If you add more text, increase the text size in your stylesheet, or decide to change the size of the page to make it smaller. More pages will be created – each the same.
创建要用作PDF或用于打印的PDF时，您将具有页面框的概念，该页面框定义了具有尺寸的物理页面。 您可以将内容添加到每个页面框的页眉和页脚区域，分别定位左和右页面。 您可以使用“生成的内容”将内容插入页面的页边距框中。 然后，当您添加内容时，将创建足够的页面来容纳内容。 如果添加更多文本，请增加样式表中的文本大小，或决定更改页面大小以使其更小。 将创建更多页面-每个页面都相同。
In a paged context you can take content and flow it through as many pages as are needed to contain it. But if you think about creating web site or application with defined screens, how different is that to paged media? Perhaps not very.
在分页的上下文中，您可以获取内容并将其流过包含它所需的尽可能多的页面 。 但是，如果您考虑创建具有定义屏幕的网站或应用程序，那么与分页媒体有何不同？ 也许不是很好。
Is it wrong to think of web content as a set of defined pages rather than a continuous scroll? I don’t think so, but at the moment you will fight quite a battle to make it work well. However, we have had attempts in CSS to develop a spec which would behave in the way I explained, allow the creation of sets of boxes that content could flow through. That attempt was CSS Regions.
将Web内容视为一组定义的页面而不是连续滚动是错误的吗？ 我不这么认为，但此刻您将进行一场艰苦的战斗以使其运作良好。 但是，我们已经在CSS中尝试开发一种规范，该规范的行为方式与我解释的方式相同，允许创建内容可以流经的盒子集。 那个尝试是CSS Regions。
CSS区域 (CSS Regions)
I’m using Regions here as a demo because it helps me describe something that we can’t otherwise come close to in browsers today, and not because I expect it to end up in our browsers any time soon. As the screenshot below demonstrates, that seems unlikely. Regions was actually implemented and then removed from browsers.
我在这里使用Regions作为演示是因为它可以帮助我描述一些我们今天无法在浏览器中实现的功能，而不是因为我希望它很快就会出现在我们的浏览器中。 如下面的屏幕截图所示，这似乎不太可能。 区域实际上已经实现，然后从浏览器中删除。
The image on Can I Use above was taken before Edge moved to Chromium. Edge had an implementation of Regions and so I was able to record the following video, demonstrating how Regions worked with my grid layout.
上面“我可以使用”上的图像是在Edge移至Chromium之前拍摄的。 Edge实施了Regions，因此我可以录制以下视频，演示Regions如何与我的网格布局配合使用。
The text is one continuous thread. It fills the boxes in turn. First filling box 1, then box 2 and moving onto fill box 3.
文本是一个连续的线程。 它依次填充框。 首先填充框1，然后填充框2，然后移至填充框3。
The problem with Regions can be understood via this example. The content flows nicely between the boxes. I get a multicol like effect between the first two boxes. The remaining content then flows into the third box.
通过此示例可以理解区域的问题。 内容在各个框之间顺畅地流动。 我在前两个方框之间得到了类似multicol的效果。 然后，其余内容将流入第三个框。
But what happens if there is more content then these three boxes can hold, or the user has increased their font size? That’s right – we get overflow because you never know how big things are on the web. Regions needs somewhere for the content to go. You have to create a stack of redundant elements to hold content which may or may not be forthcoming, second guessing the content to have enough layout and not too much. In all likelihood using JavaScript to work that out and create enough elements.
但是，如果有更多内容可以容纳这三个框，或者用户增加了字体大小，会发生什么？ 没错–我们无所适从，因为您永远不知道网络上有多么大的事情。 区域需要在某处放置内容。 您必须创建一堆冗余元素来保存可能即将出现或可能不会出现的内容，其次要猜测内容是否具有足够的布局，而又不要过多。 极有可能使用JavaScript解决这个问题并创建足够的元素。
There was no ability to do anything like the things we can do in Paged Media, no way to declare that my pages or components look like this, please create as many as you need and put the content into these boxes.
无法执行我们在Paged Media中可以做的事情，也无法声明我的页面或组件看起来像这样，请创建所需数量的内容并将其放入这些框中。
It has been suggested to me that the spec is fine because you can dump everything leftover into a final div for sad content without a home. I don’t think that is a solution anyone really wants. That’s a hack, a workaround, it feels like something not fully thought through.
我认为规范是很好的，因为您可以将剩余的所有东西丢到最后的div中，以便在没有家的情况下感到悲伤 。 我认为这不是任何人真正想要的解决方案。 这是一个hack，一种解决方法，感觉有些事情没有经过深思熟虑。
Regions faltered. The code was removed from Blink. Whenever it comes up people get very tetchy. However this all really predated grid layout.
地区步履蹒跚 。 该代码已从闪烁中删除。 每当它出现时，人们都会变得非常挑剔。 但是，这实际上早于网格布局。
I think that now, in a world where we have Grid and where Regions makes a lot of sense, we can circle back and look at something which is like Regions again.
我认为，现在，在一个拥有网格并且区域很有意义的世界中，我们可以回头看看又一次类似于“区域”的事物。
As with block dimension overflow for multicol, I think this is also all about overflow. Web design has always been a battle against overflow, against the fact that we never now how tall (or how big in the block dimension) anything is on the web.
与针对multicol的块尺寸溢出一样，我认为这也与溢出有关。 Web设计一直是与溢出争夺的斗争，因为我们现在从来没有像现在这样高的人（在块尺寸上这么大）。
The minute we decide that we have a finite page, we aren’t just scrolling forever, we have decided how big this is in the block dimension, we risk overflow and we have given ourselves the job of managing it.
我们决定拥有有限页面的那一刻，我们不仅仅是在永久滚动，还决定了块尺寸有多大，我们冒着溢出的风险，并且已经完成了管理它的工作。
Web design is mostly a batle against overflow.
网页设计主要是防止溢出的工具。
地区是否为更好的事情铺平了道路？ (Did Regions pave the way for something better?)
What if, as with multicol overflow, we can say - this is my container - it’s 100vh. It looks like this, at this breakpoint, it looks like this at another breakpoint. Here is my content, I want it to flow through these boxes. If I fill all the boxes, create me another box with the same layout and continue to add content.
如果与multicol溢出一样，我们可以说-这是我的容器-100vh，该怎么办？ 在此断点处看起来像这样，在另一个断点处看起来像这样。 这是我的内容，我希望它能通过这些框显示。 如果我填满所有框，请为我创建另一个具有相同布局的框，然后继续添加内容。
As with the original regions idea my content thread is a semantically marked up thing, it makes sense outside of that layout. We gain that separation of structured content and the layout. I think it would be incredibly exciting and useful. There are however things that need to be put into place before anything Regions-like can happen. CSS Regions, like multicol relies on Fragmentation, and fragmentation is not in great shape across browsers right now. And, while it is annoying enough to end up with a heading at the bottom of one column with the content in the next. It would be a dealbreaker to have the heading in a box completely disconnected from the rest of the content.
就像最初的区域想法一样，我的内容线程是一个语义标记的东西，在该布局之外有意义。 我们获得了结构化内容和布局的分离。 我认为这将是令人兴奋和有用的。 但是，在任何类似地区的事情发生之前，都需要做好一些准备。 CSS区域（如multicol）依赖于碎片化，而碎片化目前在各个浏览器中的状态都不理想 。 而且，虽然它很烦人，但最后以一列的标题为标题，而下一列的内容为标题。 将框中的标题与其余内容完全断开连接将是一件大事。
使事情变得更好 (Making things better)
Whether you like the idea of Regions or not, I talk about these things because this is how we get new things. This is how we solve problems.How we figure out the next big layout challenge and start to fix it. Here is another example.
无论您是否喜欢“区域”的概念，我都在谈论这些事情，因为这是我们获得新事物的方式。 这就是我们解决问题的方式。我们如何解决下一个重大布局挑战并开始解决它。 这是另一个例子。
At An Event Apart I ended up chatting to Rob about a problem he had with Grid. He wanted to be able to float items but still have them use the grid layout.
在“一个活动”中，我最终和Rob聊了聊他与Grid有关的问题。 他希望能够浮动项目，但仍使它们使用网格布局。
Because a floated item, when it becomes a grid item, loses the float behaviour he couldn’t do that. So had come up with a hacky solution to the problem and he wrote it up.
因为浮动项目在变成网格项目时失去了浮动行为，所以他无法做到这一点。 因此，他想出了一个解决问题的办法，于是他写下来。
Now Rob saw this as a grid problem. He wrote it up as a grid problem.
现在，Rob将此视为网格问题。 他把它写成网格问题 。
However when I looked at it, because I’ve been digging around these specs for years, I recognised that we already had something in CSS that could solve this. The Exclusions spec – also only useable in Edge right now – solves this problem perfectly.
但是，当我查看它时，因为多年来一直在研究这些规范，所以我意识到我们已经在CSS中找到了可以解决此问题的方法。 排除规范（目前仅在Edge中也可用）完美解决了此问题。
I was able to write up the solution with some demos.
More importantly it gave me a great use case to take back to the CSS Working group, to show them of a real-world problem that Exclusions solved, to see if we could start talking about it and solving the problems in that spec so more browsers might implement it.
更重要的是，它为我提供了一个很好的用例， 可以带回到CSS工作组 ，向他们展示排除问题解决的实际问题，看看我们是否可以开始谈论它并解决该规范中的问题，因此有更多的浏览器可能实现它。
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.
这是任何人都可以做的事情。 写下您无法做的事情-甚至猜出解决方案-不要担心它是否不是最佳解决方案。 在大多数情况下，弄清楚这一点不只需要一个主意，这就是我们拥有CSS工作组的原因。 但是请向我们展示。 不要以为因为CSS现在不能这样工作，所以它永远不能这样工作 。
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.
这几乎是本演讲的结尾。 但是，当我第一次在旧金山展示此内容时，发生了一件事情，我认为这支持了我对更多人输入Web平台的重视。
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.
我醒来，有传言后来被证实微软将放弃其渲染引擎EdgeHTML以便使用Chromium。 而且我担心我们会回到一种浏览器拥有超过95％市场份额的时代。 一个浏览器可以从字面上决定网络的方向。
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.
我讨论的许多事情（例如，排除和区域）都是由Microsoft团队实现的。 不，不是以一种完美的方式完成，而是足以让我们进行实验。 我们可以尝试一下了。 网格布局最初是由Microsoft团队在IE10中实现的。 不，它不是完美的，本质上是即将发生的事情的原型，但是它使人们能够进行实验。 如果不是那个实现允许我开始使用该规范的实现，那么我可能不会被称为CSS Grid。
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.
更少的浏览器意味着更少的实验。 意味着事物开始发展的地方越来越少。 在我第一次演讲时，我说过，我绝对确信Microsoft浏览器团队中的优秀人才，我称呼我的朋友的人，优秀人士，优秀工程师，真正的标准拥护者将在Chromium上做出出色的贡献。 那已经证明是正确的。 但最终，它是一个单一的呈现引擎，并受到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.
而且，如果我们在渲染引擎中不具有多样性，那么我们需要加倍努力，以确保标准流程中涉及各种思想。
At a W3C meeting or standards discussion, the room should not be 60–70% Googlers.
在W3C会议或标准讨论中，会议室人数不应为60％到70％的Google员工。
— Ferdy Christant —费迪·克里斯坦 （ Ferdy Christant）
As Ferdy Christant points out, there are other players who can be involved in standards discussions, not just the people behind rendering engines. CSS Shapes, Exclusions and Regions came out of work done by Adobe.
正如Ferdy Christant指出的那样，还有其他一些参与者可以参与标准讨论，而不仅仅是渲染引擎背后的人。 CSS形状，排除项和区域是Adobe所做的工作。
Many of the people on the CSS Working Group represent the world of publishing. We need to make sure that those non-browser companies are given weight and impact.
CSS工作组中的许多人代表着出版界。 我们需要确保给那些非浏览器公司以分量和影响力。
We need to encourage independent voices into the process. We need to make sure that it is as easy as possible for web designers and developers to join the discussion, and encourage those who show real talent for standards work.
我们需要鼓励独立的声音参与进来。 我们需要确保网站设计师和开发人员尽可能轻松地参加讨论，并鼓励那些对标准工作表现出真正才能的人。
Then we need to make sure that every time someone comes along who is good at this, who can impact the process, who can be a different voice or represent different people, that they are supported to do so and are not just immediately hired by Google as the only route to do web platform work. A shoutout in that regard to Fronteers and their great experiment in funding me as an official representative of web developers.
然后，我们需要确保每当有人出现时会擅长此事，会影响流程，可能会以不同的声音或代表不同的人出现，并确保他们得到支持，而不仅仅是被Google立即雇用作为执行Web平台工作的唯一途径。 在这方面对Fronteers以及他们为资助我作为Web开发人员的正式代表而进行的伟大实验大喊大叫。
And I am not having a dig at Google here, again, there are some great people doing great things there, and the company is being a company doing what companies do - growing, succeeding. This isn’t a fight between good and evil. It’s a fight against a monoculture turning the web platform into the product of a single company. Whoever that company might be this time.
同样，我在这里没有深入研究Google，那里有一些很棒的人在做伟大的事情，而该公司正在成为一家公司，他们在做公司正在做的事情-成长，成功。 这不是善与恶之间的斗争。 这是与将网络平台转变为一家公司的产品的单一文化的斗争。 谁该公司可能是这个时候 。
So please. Participate, share your ideas, help us solve problems. And let’s work together for the future of the open web platform.
所以，请。 参与，分享您的想法，帮助我们解决问题。 让我们一起为开放式Web平台的未来而努力。
翻译自: https://rachelandrew.co.uk/archives/2020/04/07/making-things-better/
csdn怎么让代码变得好看
539
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
