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!

Reading Time: 2 minutes Since 2019, the annual State of CSS survey has collected feedback from web developers from across the world to try and take the pulse of the CSS ecosystem, and it’s become a valuable resource not only for CSS developers, but also for browser vendors. This summer, one of my side projects is helping out with survey […]

Since 2019, the annual State of CSS survey has collected feedback from web developers from across the world to try and take the pulse of the CSS ecosystem, and it’s become a valuable resource not only for CSS developers, but also for browser vendors. This summer, one of my side projects is helping out with survey design and outreach for the State of CSS survey, thanks to a generous Google UI fund grant.

The target is for the survey to launch in mid September, and we are currently working on the outline. So far we have created a preliminary outline based on last year’s survey and early research. All our work happens is in the open, in this repo. Here are some of the changes from last year’s survey:

• Removed the Pre-processors category as it feels like there isn’t too much debate around that area.
• Got rid of “which browser do you primarily develop in?” question as we already ask which browsers people test in.
• Merged “Opinions” and “Environments” sections into new “Usage” section.
• Moved browsers question to “Other Tools”.
• New features:
  • currentcolor
  • color-mix()
  • Wide gamut colors
  • scroll-behavior
  • scroll-padding
  • font-palette
  • :focus-visible
  • :has() pseudo-class
  • :where() pseudo-class
  • Cascade Layers
  • Houdini Paint API
  • and there are several others we are considering

We are currently looking for feedback from the community, including suggesting CSS features to ask about, libraries and tools, or even new questions altogether.

There are also some design issues to flesh out, you’re welcome to weigh in there too.

If you want to quickly vote on which features are most important for you to make it into the survey, you can do that either via GitHub 👍🏼reactions, or here (which uses GitHub reactions behind the scenes). Do note that reactions are only one metric among many we will use to consider items.

The feedback period will be open until August 20, then we will start working on launching the survey.

Do note that browser makers are looking at this and similar surveys to prioritize what to implement. This is why Google is sponsoring this project. So any effort you put into survey outline feedback, and on responding to the survey when it’s ready, could come back to you tenfold when your favorite CSS features get implemented faster!

Since 2019, the annual State of CSS survey has collected feedback from web developers from across the world to try and take the pulse of the CSS ecosystem, and it’s become a valuable resource not only for CSS developers, but also for browser vendors. This summer, one of my side projects is helping out with survey design and outreach for the State of CSS survey, thanks to a generous Google UI fund grant.

The target is for the survey to launch in mid September, and we are currently working on the outline. So far we have created a preliminary outline based on last year’s survey and early research. All our work happens is in the open, in this repo. Here are some of the changes from last year’s survey:

• Removed the Pre-processors category as it feels like there isn’t too much debate around that area.
• Got rid of “which browser do you primarily develop in?” question as we already ask which browsers people test in.
• Merged “Opinions” and “Environments” sections into new “Usage” section.
• Moved browsers question to “Other Tools”.
• New features:
  • currentcolor
  • color-mix()
  • Wide gamut colors
  • scroll-behavior
  • scroll-padding
  • font-palette
  • :focus-visible
  • :has() pseudo-class
  • :where() pseudo-class
  • Cascade Layers
  • Houdini Paint API
  • and there are several others we are considering

We are currently looking for feedback from the community, including suggesting CSS features to ask about, libraries and tools, or even new questions altogether.

There are also some design issues to flesh out, you’re welcome to weigh in there too.

If you want to quickly vote on which features are most important for you to make it into the survey, you can do that either via GitHub 👍🏼reactions, or here (which uses GitHub reactions behind the scenes). Do note that reactions are only one metric among many we will use to consider items.

The feedback period will be open until August 20, then we will start working on launching the survey.

Do note that browser makers are looking at this and similar surveys to prioritize what to implement. This is why Google is sponsoring this project. So any effort you put into survey outline feedback, and on responding to the survey when it’s ready, could come back to you tenfold when your favorite CSS features get implemented faster!