CSS Stuff I'm Excited After the Last CSSWG Meeting

From 11 to 13 June 2024, the CSS Working Group (CSSWG) held its second face-to-face meeting of the year in Cruña, Spain, with the agenda covering many new features and improvements to the CSS language. Following the remarkable advancements such as nesting, container query and style query and has: selectors in 2023, more breakthrough updates will be received in 2024. Whether new features like inline conditional statements are just getting started or long-term projects are about to end, 2024 is already full of exciting developments – and we are just entering July!

This article will share some of the most interesting and important new features of CSS that I think are discussed at this conference. It should be noted that this is not an exact record of the discussions of the conference, but an overview of the main CSS topics that are focused on in the conference. In fact, these features have been brewing for years, and discussions focus on specific cases and new enhancements rather than defining a complete specification; it is impossible to accomplish this in a meeting.

You can view specific issues discussed on the agenda of the CSSWG meeting.

Feature 1: if() Prospect of the function

Since CSS custom properties gained solid support around 2016, many ways have been tried to apply specific styles based on custom property values ​​without relying on JavaScript. One of the earliest conditional style solutions was proposed by Roman Komarov in 2016's "Conditions for CSS Variables." Since then, many other "skills" have been documented for conditional declarations in CSS (including the extremely clever approach proposed by Ana Tudor on CSS-Tricks). In fact, CSSWG member Lea Verou, in her recent article, “Inline Conditional Statements in CSS, Now?”, provides a complete list of discussions and comparisons of these solutions.

To be sure, the community has always longed for a conditional way to apply styles using custom properties. Nowadays, we have a style query specification that can accomplish this task, but it has some limitations that are not related to browser support. What is the biggest limitation? We cannot style the query container directly , so we need to add some kind of wrapping element around the container in HTML.

<code><div style="--variant: info">
  <p>Here is some good <strong>news</strong></p>
</div></code>

…and style query:

<code><div style="--variant: info">
  <p>Here is some good <strong>news</strong></p>
</div></code>

if() What a function might look like

In terms of CSSWG, the addition of if() functions was discussed in 2018. On June 13 this year – yes, six years later – CSSWG decided to start developing if() functions for CSS. Although it looks good, don't expect to see in your browser for at least two years if()! (This is Lea's unofficial estimate.) We may have to wait longer to get enough browser support to use it reliably in production. The draft specification has just begun and many things must be tested first. For reference, the CSS variables work draft began in 2012 and did not receive extensive browser support until 2016.

In terms of syntax, if() may borrow ternary operators from JavaScript and other programming languages, and the structure is as follows:

<code>.news-container {
  container-name: news-container;
}

@container news-container style(--variant: info) {
  p {
    color: blue;
    border: 1px solid blue;
  }
}</code>

… where a is the custom attribute we are checking, and b and c are possible conditional return values. To check the style, the inline style style(--my-property: value) will be used.

<code>if(a ? b : c)</code>

Even if ? is not used in CSS, and : has different meanings elsewhere, I think this syntax is most familiar to most people, not to mention that it also allows seamless conditional links.

<code>.forecast {
  background-color: if(style(--weather: clouds) ? var(--clouds-color): var(--default-color));
}</code>

Future if()Improvement of functions

Although these may not appear in the initial version, it is still interesting to know what changes may occur at some point in time in the future: if()

• Supports other inline conditional statements. We should use the query to check custom properties, but we can also use the inline style() query to check media properties, or use the inline media() to check if the user agent supports specific properties. support()

<code>.forecast {
  background-color: if(
    style(--weather: clouds) ? var(--clouds-color): 
    style(--weather: sunny) ? var(--sunny-color);
    style( --weather: rain) ? var(--rain-color): var(--default-color)
  );
}</code>

• Use conditional statements in other CSS functions. In future drafts, we can use ternary operators in other functions without wrapping them in , for example, if we are in if() or clamp() functions, we can do the calculations without round(). calc()

Feature 2: Transition across document view

Last year, the View Transition API allowed us to create seamless transitions between navigating web pages and states. No components or frameworks, no animation libraries required – just use a small amount of JavaScript and plain HTML and CSS. The first implementation of view transition was integrated into the browser long ago, but it is based on experimental functions defined by Chrome and is limited to transitions between two states (single-page view transitions) without supporting transitions between different pages (i.e., multi-page view transitions), which is exactly what most of our developers desire. The possibility of mimicking native application behavior is exciting!

This is why CSS View Transition Module Level 2 is so great and why it is the most popular of all the CSS new features described in this article. Yes, this feature brings out-of-the-box seamless transition across pages, but what really matters is that it eliminates the dependency on the framework that implements this feature. We can go back to pure CSS and JavaScript instead of using libraries - such as React some routing libraries.

Of course, the View Transition API may be out of reach for some complexity, but it is excellent for the myriad situations where we just want to make page transitions without having to bear the performance cost of introducing frameworks.

Opin to view transition

When we navigate from the same source to between two pages, the view transition is triggered. In this case, the navigation might be to click a link, submit a form, or use a browser button to move back and forth. By contrast, using a search bar between the same source pages does not trigger a page transition.

Both pages—the page we want to leave and the page we want to navigate to—both need to use @view-transition at-rule and set the navigation property to auto to opt into the transition:

<code><div style="--variant: info">
  <p>Here is some good <strong>news</strong></p>
</div></code>

When both pages opt to join the transition, the browser will "snapshot" the two pages and smoothly fade the "before" page into the "after" page.

Transition between "snapshots"

In this video, you can see how the old page fades into the new page, thanks to a complete set of new pseudo-elements that persist during the transition and use CSS animations to produce effects. The browser will group snapshots of elements using a unique view-transition-name property that sets a unique identifier on the transitions we can refer to, and that identifier is captured in the ::view-transition pseudo-element containing all transitions on the page.

You can think of ::view-transition as the :root element of all page transitions, which combines all page transition parts on the same default animation.

<code>.news-container {
  container-name: news-container;
}

@container news-container style(--variant: info) {
  p {
    color: blue;
    border: 1px solid blue;
  }
}</code>

Note that each transition is in a ::view-transition-group , the group contains a ::view-transition-image-pair, and the pair contains both "old" and "new" page snapshots. We can add as many groups as we want, and they all contain an image pair with two snapshots.

Quick example: Let's use ::view-transition "root" as parameter to select all transitions on the page and create a sliding animation between the old and the new snapshots.

<code>if(a ? b : c)</code>

If we navigate between pages, the entire old page will slide to the left and the entire new page will slide in from the right. But we may want to prevent certain elements on the page from participating in the transition because they persist between pages, while everything else moves from the "old" snapshot to the "new" snapshot.

This is the key to the view-transition-name attributes, because we can snapshot certain elements and put them in ::view-transition-group separate from everything else to handle them separately.

<code><div style="--variant: info">
  <p>Here is some good <strong>news</strong></p>
</div></code>

You can find a live demo of it on GitHub. Please note that at the time of writing, browser support is limited to Chromium browsers (i.e. Chrome, Edge, Opera).

We have a lot to look forward to when it comes to transitioning across document views. For example, if we have several elements with different view-transition-name, we can provide them with a shared view-transition-class to style them in one place—and even use JavaScript to further customize the view transition to check which URL the page is transitioning from and animate accordingly.

Feature 3: Anchor Positioning

It seems like a breeze to locate elements relative to another element in CSS, but actually requires mixing margin attributes (top, bottom, left, right) based on a series of magic numbers to get the correct result. For example, a widget prompt popping up on the left side of an element during hover might look like this in HTML:

<code>.news-container {
  container-name: news-container;
}

@container news-container style(--variant: info) {
  p {
    color: blue;
    border: 1px solid blue;
  }
}</code>

…and CSS using the current method:

<code>if(a ? b : c)</code>

Having to change the positioning and margin values ​​of elements is not the end of the world, but it does feel like there should be an easier way. Additionally, the tooltips in the last example are very fragile; if the screen is too small or our element is too left, the tooltips will hide or overflow the edge of the screen.

CSS anchor positioning is another new feature discussed at the CSSWG meeting and it hopes to make such things much easier.

Create anchor points

The basic idea is that we build two elements:

• One acts as an anchor,
• A "target" anchored to the element.

This way, we have a more declarative way to associate an element and position it relative to the anchor element.

First, we need to create our anchor-name anchor point element with the new attribute.

Change our mark slightly:

<code>.forecast {
  background-color: if(style(--weather: clouds) ? var(--clouds-color): var(--default-color));
}</code>

We specify a unique dotted indentation for it as its value (just like a custom property):

<code>.forecast {
  background-color: if(
    style(--weather: clouds) ? var(--clouds-color): 
    style(--weather: sunny) ? var(--sunny-color);
    style( --weather: rain) ? var(--rain-color): var(--default-color)
  );
}</code>

Then we use the position-anchor attribute and fixed or absolute positioning to associate .tooltip. .anchor

<code>.my-element {
  width: if(media(width > 1200px) ? var(--size-l): var(--size-m));
}</code>

is currently on top of .tooltip, but we should move it to another location to prevent this. The easiest way to move .anchor is to use the new .tooltip attribute. Let's assume inset-area is in the middle of a 3×3 grid, and we can locate tooltips in the grid by assigning rows and columns to it. .anchor

inset-area The property is .tooltip Takes two values ​​in the position in a specific row and column. It counts using physical values ​​(such as left, right, top, and bottom) as well as logical values ​​(such as start and end) of the user's writing pattern and shared center values. It also accepts values ​​that reference x and y coordinates, such as x-start and y-end. All of these value types are methods that represent space on a 3×3 grid.

For example, if we want .tooltip to be positioned relative to the upper right corner of the anchor point, we can set the inset-area property like this:

<code><div style="--variant: info">
  <p>Here is some good <strong>news</strong></p>
</div></code>

Finally, if we want our tooltip to span two areas of the grid, we can use the span- prefix. For example, span-top places .tooltip on the top and center area of ​​the grid. If we want to span the entire direction, we can use the span-all value.

One of the example issues we have no anchor points is that tooltips may overflow the screen. We can solve this problem using another new property (called position-try-options this time) combined with a new inset-area() function.

(Yes, there is a inset-area property and a inset-area() function. This is one we have to remember!)

The

position-try-options property accepts a comma-separated list of fallback positions for when .tooltip overflows the screen. We can provide a series of inset-area() functions, each containing the same attribute value as the inset-area attribute. Now, every time the tooltip goes out of the screen, the next declared location is "tryed" and if that location causes overflow, the next declared location is attempted, and so on.

<code>.news-container {
  container-name: news-container;
}

@container news-container style(--variant: info) {
  p {
    color: blue;
    border: 1px solid blue;
  }
}</code>

This is a very novel concept and it takes some time to understand. CSSWG member Miriam Suzanne sat down with James Stuckey Weber to discuss and try anchor positioning in a very worthwhile video.

If you are looking for TL;DW, Geoff Graham took notes on the video.

For simplicity, many aspects of anchor positioning are not introduced here, especially the new anchor() functions and @try-position at-rule. The anchor() function returns the calculated position of the anchor edge, which provides more control over the tooltip margin properties. @try-position at-rule is used to define the custom position to set on the position-try-options property.

My intuition is that for the vast majority of use cases, using inset-area will be powerful enough.

CSSWG is a collective effort

I have said earlier that this article will not give an exact recap of the discussions conducted at CSSWG meetings, but will only be a broad introduction to the new specifications of CSS, which are bound to appear at these meetings due to their novelty. There are even some features that we simply don't have time to review in this review, which are still being discussed (cough, masonry).

One of the things that is certain is that the specification is not formulated in a meeting or two in a vacuum environment; it requires the joint efforts of dozens of great authors, developers, and user agents to turn what we use every day in our CSS work—not to mention what we will use in the future—to become reality.

I also had the opportunity to talk to some of the great developers at CSSWG and I found the most they got from the meetings interesting. You might expect if() to be at the top of their list because this is what is being discussed on social media. But CSSWG member Emilio Cobos tells me that for example, the letter-spacing attribute is inherently flawed, and there is no simple solution to solve the problem that it is consistent with the current definition of letter-spacing and how it is used in the browser. This includes the fact that converting normal properties to abbreviated properties can be dangerous to the code base.

We may think that every detail of insignificance will be carefully analyzed to benefit the Internet and out of love for the Internet. And, as I mentioned earlier, these things do not happen in a closed vacuum environment. If you have any interest in the future of CSS – whether it’s keeping up with CSS or actively participating – consider any of the following resources.

• CSSWG Home Page
• CSSWG Blog
• CSSWG Draft (GitHub)
• CSSWG News RSS Feed (Atom)
• CSS Specification Table
• Public Review Announcement Mailing List and Archives (and RSS Feed)

The above is the detailed content of CSS Stuff I'm Excited After the Last CSSWG Meeting. For more information, please follow other related articles on the PHP Chinese website!