2023 was an epic year for CSS. As this post by Google’s Chrome UI DevRel Team shows, some incredible new features launched into stable browser versions across the year. Each feature now achieved with only CSS.
You can find a number of our resources that focus on removing JavaScript and using CSS instead. Posts such as how to create a snap scroll interaction, how to create a simple slider, how to create simple and accessible accordions, or even how to do parallax effects. All of these without the use of JavaScript, which only a few years ago, wouldn’t have been possible.
With new features launched in 2023, many of which are now in stable browser versions, and a whole host of others nearly there, the need for JavaScript for complex layout and interaction is dwindling.
What’s new in CSS
Here are some of the new CSS features now in stable browser versions.
Grids, and Subgrids
With CSS subgrid
, you can create more complex layouts with much better alignment of parent/child elements. This allows for reduced amounts of CSS code whilst creating complex layouts with shared grids.
A (much) wider array of vibrant colours
Colours are a huge aspect of design for the web. We already have a vast array of colours that could be used digitally. However, in 2023 the colour specs got a huge upgrade. This means we have access to a whole host of new colours, new colour spaces, colour functions and capabilities.
Exactly what this means for energy use on devices is yet to be tested. It is important that as designers we know this information, as these new colours start to be used more commonly across the web. A future post on this feels like a good idea, following on from the What’s the worst colour for your digital carbon footprint? post from 2022.
Container queries
Traditionally, you may have been setting up breakpoints for your layouts based on the global viewport size. This is ok for certain aspects of the design and layout, but not the best for everything. You may want to adjust the layout based on the size of a particular content ‘block’. This is where container queries come into play.
For example, a reusable component .tile
is displayed across different areas of a website. On one page it is within a parent container that is the full width of the viewport. On another page, it is within a parent container that has a maximum width of 300px within a sidebar layout. Using a global viewport breakpoint here is not applicable. But a container query would be very useful here. It means we can style the element used as the .tile
component based on the size of its parent container. Making it much simpler and more specific to control the style of the component in different dynamic scenarios whilst reusing code.
The new ‘Update’ media query
The update
media query gives you a way to adapt UI to the refresh rate of a device. It has a couple of possible options for none, slow or fast update speeds/refresh rates.
While modern devices on the whole have very fast refresh rates, older devices may not. This allows sustainable developers to cater to older devices, while progressively enhancing designs for devices with higher refresh rates. This is important as we need to continue to cater to older devices, offering a great experience for those users for a long time. For those users with the latest devices, we can enhance the experience with smoother animations that are possible thanks to the faster refresh rate.
Detecting whether JavaScript is enabled in CSS
It feels somewhat bonkers that this is now possible, but yes, you can now detect whether scripting is enabled within your CSS. The days of including ‘no-js’ as a class on your html
element are (potentially) over.
With the new scripting media query, you can alter the layout, or features, without any JavaScript at all. Here is a very simple example.
/* hide an object when JavaScript is disabled */ @media (scripting: none) { .object { display: none; } } /* show an object when JavaScript is enabled */ @media (scripting: enabled) { .object { display: block; } }
:user-valid and invalid pseudo classes
These new pseudo classes are useful for creating user-friendly forms. They eliminate some of the JavaScript needed to show whether form fields have been interacted with by real users.
The :user-valid
and :user-invalid
behave similarly to the :valid
and :invalid
pseudo-classes, but match a form control only after a user has significantly interacted with the input.
For example: A form control that is required and empty will match :invalid
even if a user has not started interacting with the page. The same control will not match :user-invalid
until the user has changed the input and left it in an invalid state.
With these new selectors, there’s no longer a need to write stateful JavaScript code to keep track of inputs a user has changed. I think that is a win-win.
What’s on the horizon for CSS & HTML?
There are many more new CSS features and HTML elements that are nearly supported in all major browsers. An incredibly useful one is the Popover API.
The Popover API
The new API, supported in all major browsers with the exception of Firefox, allows developers to build (more) accessible-by-default content areas that sit on top of other content. Examples include navigation menus, tooltips, lightboxes, and a host of other creative solutions.
As standard, the API supports:
- Promotion to the top layer. Popovers will appear on a separate layer above the rest of the page, so you don’t have to play around with z-index.
- Light-dismiss functionality. Clicking outside of the popover area will close the popover and return focus.
- Default focus management. Opening the popover makes the next tab stop inside the popover.
- Accessible keyboard bindings. Hitting the esc key or double toggling will close the popover and return focus.
- Accessible component bindings. Connecting a popover element to a popover trigger semantically.
All of this is controllable from just HTML and styled with CSS. No JavaScript is necessary. However, it can be enhanced and fallbacks operated with JavaScript.
I can see there being more of these exciting updates coming to all major browsers in 2024, with even more opportunities to rely less on JavaScript for commonly used features and functions. It may also mean a potentially massive reduction in JavaScript transfer size across the web. If every site was able to reduce this amount of JS, can you imagine how much data and carbon reduction that may result in?