魔法瓶子css动画_CSS不是黑魔法

魔法瓶子css动画

by aimeemarieknight

通过aimeemarieknight

CSS不是黑魔法 (CSS Isn’t Black Magic)

向后拉样式表上的窗帘 (Pulling Back The Curtains on Your Stylesheets)

If you’re a web developer, chances are you’re going to have to write some CSS from time to time.

如果您是网络开发人员，那么您将不得不不时编写一些CSS。

When you first looked at CSS, it probably seemed like a breeze. You added some borders here, changed some colors there. JavaScript is the hard part of front end development, right?

当您初次查看CSS时，可能看起来像是轻而易举的事。 您在此处添加了一些边框，在此处更改了一些颜色。 JavaScript是前端开发的难点，对吗？

Somewhere during your progression as a web developer, that changed though! What’s worse is that many developers in the front end community have come to dismiss CSS as a toy language.

在您成为网络开发人员的过程中，某些地方发生了变化！ 更糟糕的是，前端社区中的许多开发人员已经开始将CSS视为一种玩具语言。

The truth however is that when we hit a wall, many of us don’t actually understand what our CSS is doing under the hood.

但是事实是，当我们碰壁时，我们中的许多人实际上并不了解CSS在幕后所做的事情。

For the first two years after my bootcamp, I did full stack JavaScript and sprinkled in some CSS here and there. As a panelist on JavaScript Jabber, I always felt like JavaScript was my bread and butter, so it’s what I spent the most time on.

在我的训练营开始的头两年，我编写了全栈JavaScript，并在各处散布了一些CSS。 作为JavaScript Jabber的小组成员，我总是觉得JavaScript是我的生计，所以这是我花费最多的时间。

Last year however, I decided to focus on the front end and I realized that I just wasn’t able to debug my stylesheets in the same way I did my JavaScript!

但是，去年，我决定专注于前端，我意识到我无法像使用JavaScript一样调试样式表！

We all like to make jokes about it, but how many of us have actually taken the time to try and understand the CSS we’re writing or reading. How many of us have actually reasonably debugged an issue to the next lowest abstraction layer when we hit a wall? Instead, we settle for the first StackOverflow answer, hacks, or we just let the issue go entirely.

我们都喜欢开玩笑，但是实际上我们当中有很多人花时间尝试去理解我们正在编写或阅读CSS。 当我们碰壁时，实际上我们当中有多少人合理地将问题调试到了下一个最低的抽象层？ 取而代之的是，我们解决了第一个StackOverflow答案，hacks，或者只是让问题完全解决了。

All too often developers are left completely puzzled when the browser renders CSS in ways they didn’t expect. It’s not dark magic though and as developers we know that computers are just parsing our instructions.

当浏览器以他们意想不到的方式呈现CSS时，开发人员常常会完全困惑。 但是，这并不是什么黑魔法，作为开发人员，我们知道计算机只是在解析我们的指令。

Knowledge of internals can also be useful for advanced debugging and performance tuning. While many conference talks discuss how to fix common bugs, my talk (and this post) will focus on the why by taking a deep dive into browser internals to see how our styles are parsed and rendered.

内部知识对于高级调试和性能调整也很有用。 尽管许多会议讨论都讨论了如何修复常见的错误，但我的演讲(以及本博文)将重点探讨为什么通过深入浏览器内部了解我们的样式是如何解析和呈现的。

DOM和CSSOM (The DOM and CSSOM)

First, it’s important to understand that browsers contain a JavaScript engine and a rendering engine. We will focus on the latter. For example, we’ll be discussing details that pertain to WebKit (Safari), Blink (Chrome), Gecko (Firefox), and Trident/EdgeHTML (IE/Edge). The browser will undergo a process that includes conversion, tokenization, lexing, and parsing which ultimately constructs the DOM and CSSOM.

首先，了解浏览器包含JavaScript引擎和渲染引擎非常重要。 我们将专注于后者。 例如，我们将讨论有关WebKit(Safari)，Blink(Chrome)，Gecko(Firefox)和Trident / EdgeHTML(IE / Edge)的详细信息。 浏览器将经历一个包括转换，标记化，词法分析和解析的过程，最终将构建DOM和CSSOM。

At a high level you can think of them as the following:

在较高的层次上，您可以将它们视为以下内容：

• Conversion: Reading raw bytes of HTML and CSS off the disk or network.

  转换 ：从磁盘或网络上读取HTML和CSS的原始字节。

• Tokenization: Breaking input into chunks (ex: start tags, end tags, attribute names, attribute values), striping irrelevant characters such as whitespace and line breaks.

  标记化 ：将输入分成多个块(例如：开始标签，结束标签，属性名称，属性值)，剥离不相关的字符，例如空格和换行符。

• Lexing: Like the tokenizer, but it also identifies the type of each token (this token is a number, that token is a string literal, this other token is an equality operator).

  Lexing ：类似于令牌生成器，但它也标识每个令牌的类型(此令牌是数字，该令牌是字符串文字，该其他令牌是相等运算符)。

• Parsing: Takes the stream of tokens from the lexer, interprets the tokens using a specific grammar, and turns it into an abstract syntax tree.

  解析 ：从词法分析器中获取标记流，使用特定语法解释标记，然后将其转换为抽象语法树。

Once both tree structures are created, the rendering engine then attaches the data structures into what’s called a render tree as part of the layout process.

一旦创建了两个树结构，渲染引擎便会将数据结构附加到所谓的渲染树中，作为布局过程的一部分。

The render tree is a visual representation of the document which enable painting the contents of the page in their correct order. Render tree construction follows the following order:

渲染树是文档的可视表示形式，使您能够以正确的顺序绘制页面内容。 渲染树的构建遵循以下顺序：

• Starting at the root of the DOM tree, traverse each visible node.
  从DOM树的根开始，遍历每个可见节点。
• Omit non visible nodes.
  忽略不可见的节点。
• For each visible node find the appropriate matching CSSOM rules and apply them.
  对于每个可见节点，找到合适的匹配CSSOM规则并应用它们。
• Emit visible nodes with content and their computed styles.
  发出具有内容及其计算样式的可见节点。
• Finally, output a render tree that contains both the content and style information of all visible content on the screen.
  最后，输出一个渲染树，其中包含屏幕上所有可见内容的内容和样式信息。

The CSSOM can have drastic effects on the render tree but none on the DOM tree.

CSSOM会对渲染树产生巨大影响，而对DOM树则没有影响。

渲染图 (Rendering)

Following layout and render tree construction, the browser can finally proceed to actual painting of the screen and compositing. Let’s take a brief moment to distinguish between some terminology here.

在进行布局和渲染树构建之后，浏览器最终可以继续进行屏幕的实际绘制和合成。 让我们花一点时间来区分这里的一些术语。

• Layout: Includes calculating how much space an element will take up and where it is on screen. Parent elements can affect child elements and sometimes vice versa.

  布局 ：包括计算元素将占用多少空间以及它在屏幕上的位置。 父元素会影响子元素，有时反之亦然。

• Painting: The process of converting each node in the render tree to actual pixels on the screen. It involves drawing out text, colors, images, borders, and shadows. The drawing is typically done onto multiple layers and multiple rounds of painting can be caused by JavaScript being loaded that changes the DOM.

  绘画 ：将渲染树中的每个节点转换为屏幕上实际像素的过程。 它涉及绘制文本，颜色，图像，边框和阴影。 通常，绘制是在多层上进行的，并且通过加载更改DOMJavaScript可能导致多轮绘制。

• Compositing: The action of flattening all layers into the final image that is visible on the screen. Since parts of the page can be drawn into multiple layers they need to be drawn to the screen in the correct order.

  合成 ：将所有图层展平为屏幕上可见的最终图像的操作。 由于页面的各个部分可以绘制为多层，因此需要以正确的顺序将它们绘制到屏幕上。

Painting time varies based on render tree construction and the bigger the width and height of the element, the longer the painting time will be.

绘制时间因渲染树的构造而异，并且元素的宽度和高度越大，绘制时间将越长。

Adding different effects can also increase painting time. Painting follows the order that elements are stacked in their stacking contexts (back to front) which we’ll get into when we talk about z-index later on. If you’re a visual learner, there’s a great painting demo.

添加不同的效果也会增加绘画时间。 绘画遵循元素在其堆叠上下文中(从后到前)堆叠的顺序，稍后我们将在讨论z-index时将介绍它们。 如果您是视觉学习者，那么这里有一个很棒的绘画演示 。

When people speak of hardware acceleration in browsers, they’re almost always referring to accelerated compositing which just means using the GPU to composite contents of a web page.

当人们谈论浏览器中的硬件加速时，他们几乎总是指加速合成，这仅意味着使用GPU来合成网页内容。

Compositing allows for pretty large speed increases versus the old way which used the computer’s CPU. The will-change property is one property that you can add that will take advantage of this.

与使用计算机CPU的旧方法相比，复合可以大大提高速度。 will-change属性是可以添加的一项属性，可以利用此属性。

For example, when using CSS transforms, the will-change property allows for hinting to the browser that a DOM element will be transformed in the near future. This enables offloading some drawing and compositing operations onto the GPU, which can greatly improve performance for pages with a lot of animations. It has similar gains for scroll position, contents, opacity, and top or left positioning.

例如，当使用CSS转换时，will-change属性允许向浏览器提示DOM元素将在不久的将来转换。 这样可以将一些绘图和合成操作卸载到GPU上，从而可以大大提高包含大量动画的页面的性能。 对于滚动位置，内容，不透明度以及顶部或左侧位置，它具有相似的增益。

It’s important to understand that certain properties will cause a relayout, while other properties only cause a repaint. Of course, performance wise it’s best if you can only trigger a repaint.

重要的是要了解某些属性将导致重新布局，而其他属性仅导致重新绘制。 当然，从性能角度来看，最好只触发重新绘制。

For example, changes to an element’s color will only repaint that element while changes to the element’s’ position will cause layout and repaint of that element, its children and possibly siblings. Adding a DOM node will cause layout and repaint of the node. Major changes, like increasing font size of an html element will cause a relayout and repaint of the entire tree.

例如，更改元素的颜色只会重绘该元素，而更改元素的位置将导致该元素，其子元素以及可能的同级元素的布局和重新绘制。 添加DOM节点将导致该节点的布局和重新绘制。 重大更改(例如增加html元素的字体大小)将导致重新布局并重新绘制整个树。

If you’re like me you’re probably more familiar with the DOM than the CSSOM so let’s dive into that a bit. It’s important to note that by default CSS is treated as a render blocking resource. This means that the browser will hold rendering of any other process until the CSSOM is constructed.

如果您像我一样，那么您可能比CSSOM对DOM更为熟悉，所以让我们深入了解一下。 重要的是要注意，默认情况下CSS被视为渲染阻止资源。 这意味着在构造CSSOM之前，浏览器将保留任何其他进程的呈现。

The CSSOM is also not 1 to 1 with the DOM. Display none, script tags, meta tags, head element, etc. are omitted since they’re not reflected in the rendered output.

CSSOM也不与DOM一对一。 不显示任何内容，省略脚本标记，元标记，head元素等，因为它们未反映在呈现的输出中。

Another difference between the CSSOM and the DOM is that CSS parsing uses a context free grammar. In other words, the rendering engine does not have code that will fill in missing syntax for CSS like it will when parsing HTML to create the DOM.

CSSOM和DOM之间的另一个区别是CSS解析使用上下文无关的语法。 换句话说，呈现引擎没有像CSS解析HTML来创建DOM时那样会填充CSS缺少语法的代码。

When parsing HTML, the browser has to take into account surrounding characters and it needs more than just the spec since the markup could contain missing information but will still need to be rendered no matter what.

解析HTML时，浏览器必须考虑周围的字符，并且不仅需要规范，因为标记可能包含丢失的信息，但是无论如何仍然需要呈现。

With all that said, let’s recap.

综上所述，让我们回顾一下。

• Browser sends an HTTP request for page
  浏览器发送HTTP请求页面
• Web server sends a response
  Web服务器发送响应
• Browser converts response data (bytes) into tokens, via tokenization
  浏览器通过标记化将响应数据(字节)转换为标记
• Browser turns tokens into nodes
  浏览器将令牌变成节点
• Browser turns nodes into the DOM tree
  浏览器将节点变成DOM树
• Awaits CSSOM tree construction
  等待CSSOM树的构建

特异性 (Specificity)

Now that we have a better understanding of how the browser is working under the hood, let’s take a look at some of the more common areas of confusion for developers. First up, specificity.

现在，我们对浏览器的工作原理有了更好的了解，下面让我们看一下一些对开发人员来说更常见的困惑领域。 首先，特异性。

At a very basic level we know specificity just means applying rules in the correct cascade order. There are many ways to target a specific tag using CSS selectors though, and the browser needs a way to negotiate which styles to give to a specific tag. Browsers make this decision by first calculating each selectors specificity value.

从最基本的层面上讲，我们知道特异性只是意味着以正确的级联顺序应用规则。 但是，有许多方法可以使用CSS选择器来定位特定标签，而浏览器需要一种方法来协商将哪种样式赋予特定标签。 浏览器通过首先计算每个选择器的特异性值来做出此决定。

Unfortunately specificity calculation has baffled many JavaScript developers, so let’s take a deeper dive into how this calculation is made. We’ll use an example of a div with a class of “container”. Nested inside that div we’ll have another div with an id of “main”. Inside that we’ll have a p tag that contains an anchor tag. Without peeking ahead, do you know what color the anchor tag will be?

不幸的是，特异性计算使许多JavaScript开发人员感到困惑，因此让我们更深入地研究如何进行这种计算。 我们将使用一个带有“容器”类的div示例。 嵌套在该div内，我们将有另一个div，其ID为“ main”。 在其中，我们将包含一个包含锚标签的ap标签。 不偷看，您知道锚标签的颜色是什么？

#main a {   color: green;}

p a {   color: yellow;}

.container #main a {  color: pink;}

div #main p a {   color: orange;}

a {   color: red;}

The answer is pink, with a value of 1,1,1. Here are the remaining results:

答案是粉红色，值为1,1,1。 以下是其余结果：

• div #main p a: 1,0,3

  div #main pa: 1,0,3

• #main a: 1,0,1

  #main a: 1,0,1

• p a: 2

  pa: 2

• a: 1

  a: 1

To determine the number, you need to calculate the following:

要确定数量，您需要计算以下内容：

• First number: The number of ID selectors.

  第一个数字 ：ID选择器的数量。

• Second number: The number of class selectors, attribute selectors (ex: [type="text"], [rel="nofollow"]), and pseudo-classes (ex: :hover, :visited).

  第二个数字 ：类选择器，属性选择器(例如： [type="text"] ， [rel="nofollow"] )和伪类(例如:hover ， :visited )的数量。

• Third number: The number of type selectors and pseudo-elements (ex: ::before, ::after).

  第三个数字 ：类型选择器和伪元素的数量(例如::before和::after )。

So, for a selector that looks like this:

因此，对于一个看起来像这样的选择器：

#header .navbar li a:visited

The value will be 1,2,2 because we have one ID, one class, one pseudo-class, and two type selectors (li, a). You can read the values as if they were just a number, like 1,2,2 is 122. The commas are there to remind you that this isn’t a base 10 system. You could technically have a specificity value of 0,1,13,4 and 13 wouldn’t spill over like a base 10 system would.

该值将为1,2,2，因为我们有一个ID，一个类，一个伪类和两个类型选择器( li ， a )。 您可以读取值，就好像它们只是一个数字一样，例如1,2,2是122。这里用逗号提醒您这不是10进制的系统。 从技术上讲，您可以将特异性值设置为0、1、13、4，而13不会像以10为基数的系统那样溢出。

定位 (Positioning)

Second, I want to take a moment to discuss positioning. Positioning and layout go hand in hand as we saw earlier in this post.

第二，我想花点时间讨论定位。 定位和布局齐头并进，正如我们在本文前面所看到的。

Layout is a recursive process that can be triggered on the entire render tree as a result of a global style change, or incrementally where only dirty parts of the page will be laid out over. One interesting thing to note if we think back to the render tree is that with absolute positioning, the object being laid out is put in the render tree in a different place than in the DOM tree.

布局是一个递归过程，由于全局样式更改，可以在整个渲染树上触发该过程，也可以以递增方式触发，仅在页面的脏部分上进行布局。 如果我们回想一下渲染树，需要注意的一件有趣的事情是，通过绝对定位，被布局的对象放置在渲染树中的位置与DOM树中的位置不同。

I’m also asked frequently about using flexbox versus floats. Of course, flexbox is great from a usability standpoint, but when applied to the same element, a flexbox layout will render in roughly 3.5ms whereas a floated layout can take around 14ms. So, it pays to keep up with your CSS skills just as much as you do your JavaScript skills.

我也经常被问到关于使用flexbox和float的问题。 当然，从可用性的角度来看，flexbox很棒，但是当应用于同一元素时，flexbox布局将在大约3.5毫秒内呈现，而浮动布局可能需要14毫秒左右。 因此，跟上JavaScript技能一样，跟上CSS技能也是值得的。

Z索引 (Z-Index)

Finally, I want to discuss z-index. At first, it sounds simple. Every element in an HTML document can be either in front of or behind every other element in the document. It also only works on positioned elements. If you try to set a z-index on an element with no position specified, it won’t do anything.

最后，我要讨论z-index。 首先，听起来很简单。 HTML文档中的每个元素都可以位于文档中其他每个元素的前面或后面。 它也仅适用于定位的元素。 如果您尝试在未指定位置的元素上设置z-index，则它将不会执行任何操作。

The key to debugging z-index issues is understanding stacking contexts, and to always start at the stacking contexts root element. A stacking context is just a three-dimensional conceptualization of HTML elements along an imaginary z-axis relative to the user facing the viewport. In other words, it’s groups of elements with a common parent that move forward or backward together.

调试z-index问题的关键是了解堆栈上下文，并始终从堆栈上下文根元素开始。 堆叠上下文只是相对于面向视口的用户沿虚构z轴HTML元素的三维概念化。 换句话说，是具有共同父级的一组元素一起向前或向后移动。

Every stacking context has a single HTML element as its root element and when z-index and position properties aren’t involved, the rules are simple. The stacking order is the same as the order of appearance in the HTML.

每个堆叠上下文都有一个HTML元素作为其根元素，并且当不涉及z-index和position属性时，规则很简单。 堆叠顺序与HTML中的外观顺序相同。

You can however, create new stacking contexts with properties other than z-index and this is where things get complicated. Opacity, when it’s value is less than one, filter when its value is something other than none, and mix-blend-mode when its value is something other than normal will actually create new stacking contexts.

但是，您可以使用z-index以外的属性创建新的堆栈上下文，这会使事情变得复杂。 不透明度，当其值小于1时，在其值为非零时进行过滤，而在其值为非正常值时进行混合混合模式，实际上会创建新的堆叠上下文。

Just a reminder, blend mode determines how the pixels on a specific layer interact with the visible pixels on the layers below it.

提醒一下，混合模式确定特定图层上的像素如何与其下方图层上的可见像素进行交互。

The transform property also triggers a new stacking context when its value isn’t none. For example, scale(1) and translate3d(0,0,0). Again, as a reminder the scale property is used to adjust size, and translate3d triggers the GPU into action for CSS transitions making them smoother.

当其属性值不为none时，transform属性还会触发一个新的堆叠上下文。 例如， scale(1)和translate3d(0,0,0) 。 再次提醒您，scale属性用于调整大小，translate3d触发GPU进行CSS过渡的动作，使其更平滑。

So, you may still not have an eye for design, but hopefully now you’re walking away a CSS guru! If you’re interested in going even further, I’ve compiled additional resources which I also used here.

因此，您可能仍然没有设计的眼光，但是希望您现在可以离开CSS专家！ 如果您有兴趣进一步研究，我在这里还编译了其他资源。

翻译自: https://www.freecodecamp.org/news/its-not-dark-magic-pulling-back-the-curtains-from-your-stylesheets-c8d677fa21b2/

魔法瓶子css动画