Take State of CSS 2022 survey

A while ago I posted a call for feedback to inform the design of the State of CSS 2022 survey. The response has been overwhelming and it was glorious. We got quite a lot of proposals, feedback, votes. But that also meant we had to make some tough decisions about what gets in the survey and what doesn’t, otherwise we’d end up with a survey so long nobody would want to finish it!

In the end we added questions about 15 new CSS features based on proposals in that repo, and decided against adding 9. Overall, there are 30 new CSS features the 2022 survey asks about. To make space for all of that, we also removed a few that were not really shining much light into what developers do anymore, and also a couple others that were not actually about CSS.

However, CSS features are not the only — or even the most important questions being asked.

Last year, some of the freeform questions about pain points were particularly useful to browser vendors for prioritizing implementation and standards work, and we expect this to be true this year as well. We put considerable effort into redesigning these freeform questions to make them more intuitive, while maintaining their helpfulness for browser vendors:

We hope the new wording makes it more clear that these are mutually exclusive, so that respondents do not feel they need to duplicate their answers.

One of the new questions I’m excited about is this question to gauge whether the respondent spends more time writing JS or CSS:

A focus of this year’s State of CSS survey is to reach a broader range of developers; a majority of respondents of past surveys has been JS developers who also write CSS, rather than developers that focus on CSS equally or even primarily. This is a natural consequence of this having been spun off the State of JS survey. To truly see what the State of CSS is in 2022, we need input from all types of developers, as developers with different focus have different needs and priorities. This question will allow us to evaluate how well we have reached this goal, and going forward, whether we are improving every year.

Another thing I’m excited about in this year’s survey is the ability to add freeform comments to any question.

It’s often hard to tell what the background is behind each of the three answers: are people not using a given feature due to poor browser support, poor ergonomics, or some other reason? When people do use a feature, was their experience good or bad? Would they use it again?

We went back and forth many times about having a more structured followup question there, but in the end settled on a simple freeform field for this first iteration. Maybe next year it will be more structured, depending on how people use it this year.

So, without further ado, the survey is finally open for responses:

Take State of CSS 2022 survey

This survey is not just for fun: the results actually inform what browsers prioritize for implementation. So by spending a few minutes on a thoughtful and comprehensive response, you can actually make both your and other developers’ lives better! What are you waiting for?

Take State of CSS 2022 survey

A while ago I posted a call for feedback to inform the design of the State of CSS 2022 survey. The response has been overwhelming and it was glorious. We got quite a lot of proposals, feedback, votes. But that also meant we had to make some tough decisions about what gets in the survey and what doesn’t, otherwise we’d end up with a survey so long nobody would want to finish it!

In the end we added questions about 15 new CSS features based on proposals in that repo, and decided against adding 9. Overall, there are 30 new CSS features the 2022 survey asks about. To make space for all of that, we also removed a few that were not really shining much light into what developers do anymore, and also a couple others that were not actually about CSS.

However, CSS features are not the only — or even the most important questions being asked.

Last year, some of the freeform questions about pain points were particularly useful to browser vendors for prioritizing implementation and standards work, and we expect this to be true this year as well. We put considerable effort into redesigning these freeform questions to make them more intuitive, while maintaining their helpfulness for browser vendors:

We hope the new wording makes it more clear that these are mutually exclusive, so that respondents do not feel they need to duplicate their answers.

One of the new questions I’m excited about is this question to gauge whether the respondent spends more time writing JS or CSS:

A focus of this year’s State of CSS survey is to reach a broader range of developers; a majority of respondents of past surveys has been JS developers who also write CSS, rather than developers that focus on CSS equally or even primarily. This is a natural consequence of this having been spun off the State of JS survey. To truly see what the State of CSS is in 2022, we need input from all types of developers, as developers with different focus have different needs and priorities. This question will allow us to evaluate how well we have reached this goal, and going forward, whether we are improving every year.

Another thing I’m excited about in this year’s survey is the ability to add freeform comments to any question.

It’s often hard to tell what the background is behind each of the three answers: are people not using a given feature due to poor browser support, poor ergonomics, or some other reason? When people do use a feature, was their experience good or bad? Would they use it again?

We went back and forth many times about having a more structured followup question there, but in the end settled on a simple freeform field for this first iteration. Maybe next year it will be more structured, depending on how people use it this year.

So, without further ado, the survey is finally open for responses:

Take State of CSS 2022 survey

This survey is not just for fun: the results actually inform what browsers prioritize for implementation. So by spending a few minutes on a thoughtful and comprehensive response, you can actually make both your and other developers’ lives better! What are you waiting for?

Reading Time: 3 minutes I always thought that the semantically appropriate way to represent a rating (e.g. a star rating) is a <meter> element. They essentially convey the same type of information, the star rating is just a different presentation. However, trying to style a <meter> element to look like a star rating is …tricky at best. Not to […]

I always thought that the semantically appropriate way to represent a rating (e.g. a star rating) is a <meter> element. They essentially convey the same type of information, the star rating is just a different presentation.

An example of a star rating widget, from Amazon

However, trying to style a <meter> element to look like a star rating is …tricky at best. Not to mention that this approach won’t even work in Shadow trees (unless you include the CSS in every single shadow tree).

So, I set out to create a proper web component for star ratings. The first conundrum was, how does this relate to a <meter> element?

• Option 1: Should it extend <meter> using builtin extends?
• Option 2: Should it use a web component with a <meter> in Shadow DOM?
• Option 3: Should it be an entirely separate web component that just uses a meter ARIA Role and related ARIA attributes?

This is what the code would look like:

<!-- Option 1 -->
<meter is="meter-discrete" max="5" value="3.5"></meter>

<!-- Options 2 & 3 -->
<meter-discrete max="5" value="3.5"></meter-discrete>

Safari has all but killed built-in extends, but there is a very small polyfill, so I didn’t mind too much. I first decided to go with that, but it turns out you can’t even mess with the Shadow DOM of the element you’re extending. You have no access to the existing Shadow DOM of the element, because it’s closed, and you cannot attach a new one. So there’s no way to add encapsulated styles, which was a strong requirement of my use case.

I did some work on Option 2, but I quickly discovered that having an internal <meter> that everything goes through was not worth it, and it was far easier to implement it myself, with appropriate implicit ARIA through ElementInternals.

The next dilemma was even more of a conundrum: A <meter> is not editable by default, but for a rating widget, you need it to be editable at least sometimes (e.g. see Shoelace Rating for an example). There is no established convention in HTML for elements that are readonly by default, and editable only some of the time. All editable elements we have are basically form controls that can lose editability through the readonly attribute. For anything else, I suppose there is contentEditable but there is no way for web components to hook into it and expose custom editing UI that overrides the one generated by the browser.

In the end what I ended up doing was creating two components:

• A <meter-discrete> component that is a discrete version of <meter>
• An <nd-rating> component that inherits from <meter-discrete> but is editable (unless readonly is specified)

I’m still unsure if this is the right way. There were a couple issues with it.

The first problem was related to encapsulation. I like to use a private #internals property for an element’s ElementInternals instance. However, <nd-rating> needed to modify the internals of its parent, to add form association stuff, so I could not use a private property anymore, and you cannot attach a separate ElementInternals object. I ended up going for a Symbol property that the parent exports, but it still doesn’t feel like a great solution as it breaks encapsulation. Ideally JS needs protected class fields, but it doesn’t look like that’s happening anytime soon.

The other problem was related to semantics. Is it still semantically a <meter> when it’s editable, or does it then become closer to a slider that you set by hovering instead of dragging? I decided to ignore that thought for now, but it does make me a little uneasy.

Anyhow, you can find my experiments at nudeui.com:

• <meter-discrete>
• <nd-rating>

All NudeUI components are very much works in progress and mainly my personal experiments, but if you feel like it, please report issues in the repo. I can’t promise I’ll get to them though!

I always thought that the semantically appropriate way to represent a rating (e.g. a star rating) is a <meter> element. They essentially convey the same type of information, the star rating is just a different presentation.

An example of a star rating widget, from Amazon

However, trying to style a <meter> element to look like a star rating is …tricky at best. Not to mention that this approach won’t even work in Shadow trees (unless you include the CSS in every single shadow tree).

So, I set out to create a proper web component for star ratings. The first conundrum was, how does this relate to a <meter> element?

• Option 1: Should it extend <meter> using builtin extends?
• Option 2: Should it use a web component with a <meter> in Shadow DOM?
• Option 3: Should it be an entirely separate web component that just uses a meter ARIA Role and related ARIA attributes?

This is what the code would look like:

<!-- Option 1 -->
<meter is="meter-discrete" max="5" value="3.5"></meter>

<!-- Options 2 & 3 -->
<meter-discrete max="5" value="3.5"></meter-discrete>

Safari has all but killed built-in extends, but there is a very small polyfill, so I didn’t mind too much. I first decided to go with that, but it turns out you can’t even mess with the Shadow DOM of the element you’re extending. You have no access to the existing Shadow DOM of the element, because it’s closed, and you cannot attach a new one. So there’s no way to add encapsulated styles, which was a strong requirement of my use case.

I did some work on Option 2, but I quickly discovered that having an internal <meter> that everything goes through was not worth it, and it was far easier to implement it myself, with appropriate implicit ARIA through ElementInternals.

The next dilemma was even more of a conundrum: A <meter> is not editable by default, but for a rating widget, you need it to be editable at least sometimes (e.g. see Shoelace Rating for an example). There is no established convention in HTML for elements that are readonly by default, and editable only some of the time. All editable elements we have are basically form controls that can lose editability through the readonly attribute. For anything else, I suppose there is contentEditable but there is no way for web components to hook into it and expose custom editing UI that overrides the one generated by the browser.

In the end what I ended up doing was creating two components:

• A <meter-discrete> component that is a discrete version of <meter>
• An <nd-rating> component that inherits from <meter-discrete> but is editable (unless readonly is specified)

I’m still unsure if this is the right way. There were a couple issues with it.

The first problem was related to encapsulation. I like to use a private #internals property for an element’s ElementInternals instance. However, <nd-rating> needed to modify the internals of its parent, to add form association stuff, so I could not use a private property anymore, and you cannot attach a separate ElementInternals object. I ended up going for a Symbol property that the parent exports, but it still doesn’t feel like a great solution as it breaks encapsulation. Ideally JS needs protected class fields, but it doesn’t look like that’s happening anytime soon.

The other problem was related to semantics. Is it still semantically a <meter> when it’s editable, or does it then become closer to a slider that you set by hovering instead of dragging? I decided to ignore that thought for now, but it does make me a little uneasy.

Anyhow, you can find my experiments at nudeui.com:

• <meter-discrete>
• <nd-rating>

All NudeUI components are very much works in progress and mainly my personal experiments, but if you feel like it, please report issues in the repo. I can’t promise I’ll get to them though!