Witnessing the evolution of CSS, we seem to be in one of the most exciting innovation periods in CSS history. It was really exciting when all browsers support flexbox and then grid again soon after. They completely transform CSS, making it no longer a clumsy collection of tricks, but something more reasonable and more in line with the trend of the times.
This feeling is getting stronger and stronger. Just recently, the following things have happened.
⚠️? The syntax that was finally released may be slightly different from the following code snippet. ?⚠️
Native nesting has become the first public working draft, meaning it is closer than ever to be a reality. Many people use preprocessors just for the convenience of nesting, which should be helpful for those who want to simplify building tools to avoid this.
I especially like how to nest conditional rules.
<code>.card { & .title { } & .body { } @media (min-inline-size > 1000px) { & { } } @nest body.dark & { } }</code>
I've heard rumors about this viable solution, which avoids the need for & on simple selectors and also completely avoids @nest.
<code>.card {{ .title { } .body { } body.dark & { } }}</code>
Container query is currently just an editor draft (CSS Containment Module Level 3), but it is already implemented in Chrome (need to enable flags). They make a lot of sense because they allow us to make style decisions based on the size of the container itself, which is a very good idea in today's component-driven world.
Check out the code for a simple example site (it might look weird if you don't have the enabled flag in Chrome).
<code>/* 在您要查询的父元素上设置containment */ .card-container { /* 目前两者都有效,不确定哪个是正确的*/ contain: style layout inline-size; container: inline-size; } .card { display: flex; } @container (max-width: 500px) { /* 必须设置子元素的样式,而不是容器*/ .card { flex-direction: column; } }</code>
The container unit also has a draft specification that for me it almost doubles the practicality of container queries. The idea is that you have a unit based on container size (width, height, or "inline-size"/"block-size"). I think qi units are the most useful.
Hopefully soon, we will write container-wide CSS that styles based on our own size and can pass that size for use by other internal properties. The font-size property is a simple practical example (a font based on its container scaled size), but I believe the container unit will be used for various purposes, such as gap, padding, and many other purposes.
<code>/* 在您要查询的父元素上设置containment */ .card-container { /* 目前两者都有效,不确定哪个是正确的*/ contain: style layout inline-size; container: inline-size; } .card h2 { font-size: 1.5rem; /* 备用*/ } @container type(inline-size) { .card h2 { font-size: clamp(14px, 1rem 2qi, 56px) } }</code>
The cascade layer (in the working draft specification) introduces a completely new paradigm for determining the winner of the CSS selector in the cascade. Currently, it is mainly a specific competition. The selector with the highest specificity wins, only the inline style and specific rules with the !important clause can outperform it. But with the layers, any matching selector on the higher layer will win.
<code>@layer base; @layer theme; @layer utilities; /* 没有层的重置样式(超低)*/ * { box-sizing: border-box; } @layer theme { .card { background: var(--card-bg); } } @layer base { /* 大多数样式?*/ } @layer utilities { .no-margin { margin: 0; } }</code>
The CSS When/Else rule proposed by Tab Atkins is accepted, it is a way to express @media and @supports queries, and you can express the else condition more easily. While media queries already have some logical capabilities, expressing mutually exclusive queries has long been difficult, which makes it very simple.
<code>@when media(width >= 400px) and media(pointer: fine) and supports(display: flex) { /* A */ } @else supports(caret-color: pink) and supports(background: double-rainbow()) { /* B */ } @else { /* C */ }</code>
The idea of scope styles (which is a draft editor) is that it provides a syntax to write styles that are only applied to selector blocks and internals, but also has the ability to stop scopes, thus creating scope loops.
My favorite thing is the "proximity" intensity stuff. Miriam explains this way:
<code>.light-theme a { color: purple; } .dark-theme a { color: plum; }</code>
<code><div> <a href="//m.sbmmt.com/link/93ac0c50dd620dc7b88e5fe05c70e15b">Plum</a> <div> <a href="//m.sbmmt.com/link/93ac0c50dd620dc7b88e5fe05c70e15b">Maybe it's plum? ? ?</a> </div> </div></code>
Right? ! There is no good way to express how close you want the link to win with .light-theme. Currently, the specificity of both topics is the same, but .dark-theme is behind - so it wins. Hopefully scope styles can solve this problem as well.
<code>@scope (.card) to (.content) { :scope { display: grid; grid-template-columns: 50px 1fr; } img { filter: grayscale(100%); border-radius: 50%; } .content { ... } }</code>
<code>/* 邻近性帮助!*/ @scope (.light-theme) { a { color: purple; } } @scope (.dark-theme) { a { color: plum; } }</code>
You are currently unable to use anything from this list on your production website. After years of trying to follow this kind of thing, I still don't know how this ends up going. I think the specification needs to be completed first and agreed upon. The browser then selects them, hoping for more than one. I think once they have them, the specifications can be finalized?
I have no idea. Maybe some of them will disappear. Maybe some of them will happen very quickly, while others will be very slow. Probably, some of them will appear in some browsers, and not in others. Hey, at least we have evergreen browsers now, so when things happen, it happens very quickly. I feel like we are now in a stage where most of the biggest and best CSS features are supported by all browsers, but with all this coming, we are going to be in a more fragmented phase of support for the latest technology.
The above is the detailed content of CSS is Going Gosh-Darned Hog Wild, I Tell Ya What. For more information, please follow other related articles on the PHP Chinese website!