State of CSS 2022 ToDo

[SachaG]

• :is selector?

[SachaG]

https://css-irl.info/exciting-times-for-browsers-and-css/

[SachaG]

https://css-tricks.com/colrv1-and-css-font-palette-web-typography

[SachaG]

https://www.smashingmagazine.com/2022/05/lesser-known-underused-css-features-2022/

[SachaG]

https://ishadeed.com/article/css-object-view-box/

[SachaG]

https://www.smashingmagazine.com/2022/05/accessible-design-system-themes-css-color-contrast/?ref=heydesigner

[SachaG]

https://www.smashingmagazine.com/2022/06/simplify-color-palette-css-color-mix/

[SachaG]

I think we can probably get rid of the pre-processors category. Maybe the survey should focus more on features/usage and less on libraries anyway?

[SachaG]

New questions:

• do people write JS?

[SachaG]

Other changes:

• Get rid of "which browser do you primarily develop in?" question as we already ask which browsers people test in.
• Merge "Opinions" and "Environments" sections into new "Usage" section.
• Move browsers question to "Other Tools"

[LeaVerou]

Hi Sacha,

A few initial thoughts while going through the features today.

Houdini

• I'd break Houdini down into multiple features, since it consists of many specs with completely different maturity levels.
• Some of these I believe are known more as the feature itself than as part of Houdini. I was puzzled to read "Houdini custom properties" since a) custom properties are not part of Houdini and b) I don't associate @property with Houdini as much anymore. Perhaps something like "@property rule (part of Houdini)" might de-prioritize Houdini but still keep it in the title for those that have heard of the feature through Houdini but help those using it key in on the actual feature much more quickly.
• Since @property is the only part of Houdini that is not JS syntax, I wonder if it would make sense to have a separate JS APIs section asking about several Houdini APIs as well as CSSOM stuff. This may work as a proxy for JS skill as well. It could ask about Paint API, Typed OM, and maybe Layout API and AnimationWorklet.

Features that could be added

• :has()
• Color fonts (probably as one category, no need to go into COLRv1 vs SVG in OT vs sbix etc)
• @font-palette-values and font-palette
• Relative color syntax
• Wide gamut colors (lab(), lch(), oklab(), oklch())
• Gradient interpolation (e.g. linear-gradient(in lab, lime, red))
• Trigonometric functions (sin(), cos() etc)
• New math functions (round(), sign(), mod())
• New viewport units (e.g. lvw, svh, dvw etc)
• CSS wide keywords: initial, unset, revert
• env()
• CSS Nesting

Features that could be removed

• Not sure we should be asking about tabindex and ARIA. Definitely useful statistics, but not related to CSS. Perhaps there should be a State of HTML survey!
• Not sure it's worth asking about @when and @else. They are not implemented anywhere and there's not even consensus in the CSS WG about them.
• Agreed with the suggestion to focus less on tools and libraries and more on CSS itself
• Features with very high usage (>90%) in 2021:
  • Flexbox
  • calc()

Other

• You are asking about CSS shapes, and separately about clip-path. How should someone who has used clip-path: polygon() respond? If "CSS shapes" is only meant to encompass things like shape-inside and shape-outside, this should be clarified.
• I'd separate media queries into a different category or at least make it very clear that the question is asking about a MQ. I was reading the list of features and had to do a double take at color-gamut, which was between perspective and backdrop-filter. I was like "is there a color-gamut property I'm not aware of?!
• There is font-variant-numeric and font-variant-*. Unclear if these are meant to be orthogonal or if the former is a subset of the latter. Might be a good idea to spell them out and make them separate.
• There is "CSS Contaiment" and "Container queries". I'd suggest expanding "CSS Containment" to what is actually being asked and make it not include container queries since they are asked about in a separate question.
• It might be nice to get a sense of people's workflow. Do they design primarily by writing code? Do they write CSS to implement an existing mockup (either by them or others)? Or a mix, where they work primarily in CSS but use a variety of graphical tools, pickers, generators?

Meta

• I'd add clarifications under every feature name / spec title. People may know about @container but not what "CSS Containment" is. People may know about filter but not what "CSS Filter Effects" are. Most people who write CSS in the wild have no idea about specifications.
• "Are there any CSS features you have difficulties using because of differences between browsers?" I wonder if we can integrate this to the feature questions so they don't need to go over features again. E.g. perhaps have a "Want to use it but can't due to browser support" answer?

[SachaG]

Those all seem like great suggestions! I'll leave the discussions of specific properties for later, but just to address a couple points:

• A separate section for JS or non-CSS APIs/attributes etc. could be a good idea I think. We just have to make sure we don't overlap too much with the JS survey. Alternatively, we leave these things out for this time and just make a note to remember to ask about them there.
• @when and @else: if we don't want to have that as a feature we could fold that into the "what's currently missing from CSS question" maybe? That being said if we think there's a reasonable chance it will be implemented and widespread at some point in the future, we can still leave it here just to have historical data that we can track over time.
• Not sure what you meant by making questions "mutually exclusive"?
• Adding clarifications everywhere is a good idea.
• The "Are there any CSS features you have difficulties using because of differences between browsers?" question was added at Philip's request I think, since it's useful to browser vendors. I know they generated some good insights from that last time so I think we can leave it.

[LeaVerou]

• @when and @else: if we don't want to have that as a feature we could fold that into the "what's currently missing from CSS question" maybe? That being said if we think there's a reasonable chance it will be implemented and widespread at some point in the future, we can still leave it here just to have historical data that we can track over time.

The thing is, we don't have consensus in the CSS WG about whether it's even going to be called @when and @else, most people wanted @if but there was a lot of pushback from the Sass community about that. It's kind of a can of worms.

• Not sure what you meant by making questions "mutually exclusive"?

Not sure what I was thinking, that didn't make sense indeed. 🤣 I just edited to reword. I meant make them separate, so that A doesn't include B and vice versa.

• The "Are there any CSS features you have difficulties using because of differences between browsers?" question was added at Philip's request I think, since it's useful to browser vendors. I know they generated some good insights from that last time so I think we can leave it.

I wasn't suggesting we remove it, just wondered if we can integrate it with the large list of questions we already ask. I can't find this question in the 2022 survey so I'm not sure if it's a freeform text field or a multiple choice question but if it's a freeform field it's often hard to think of examples (even if you were looking at them a few minutes ago in the previous pages) and if it's a list it can be tedious to go over the same list twice. There could still be a freeform field at the end asking if there are any other features they don't use due to browser differences.

[SachaG]

Yes it was a freeform field. The reason why I'd rather not integrate this to the feature questions like you suggested (even though that would be a great idea) is that changing the available answers would make it harder to establish a valid historical comparison with previous years. It would become hard to be sure if data is different because of trends or because of the new question wording.

[SachaG]

Btw I'll go through your post and update the outline accordingly next week and then we can have another round of feedback, or maybe even already open it to public comments if we feel it's good.

[foolip]

Here's the freeform question from 2021: https://2021.stateofcss.com/en-US/opinions/#browser_interoperability_features

Some responses, like Scrollbar Styling, aren't things we asked about as features, but most of them were. I assume there's a priming effect, that developers are more likely to name features they've just been asked about. Nevertheless, it was useful, and motivated multiple Interop 2022 proposals.

If there is a way to ask "does this feature give you trouble" for each feature without invalidating historical comparison, then that could be very valuable, at least for some features.

I suspect it would not be trivial to implement, but one option could be to say "Here's a list of features you've used. Have you had difficulties using any of them (because of differences between browsers)?" Maybe as checkboxes, or maybe as a freeform text field. And then possibly an "any other features" question.

Final thought. One has to be careful to not make the survey tedious with this sort of question. The type of question that would give us the most insight if answered faithfully by everyone might not be the same as keeps developers engaged. For every addition we should probably remove something else.

[LeaVerou]

One way to remove the priming effect is to ask before the long list of features. But then you have the opposite problem, of respondents not being able to remember the relevant features off the top of their head.

[SachaG]

I like the idea of isolating the features that we already know people use based on their answers, and then asking for more details on those specifically. This could be a good temporary solution until we change the main feature question itself (but I'd like to do some testing before we do that so I don't know if it'll be possible for this round of the survey).

[SachaG]

This is an alternate design I have in mind for the library evaluation questions, but the same principle could apply to features. Instead of offering 3, 4, 5, etc. choices for each item sequentially, group the choices in a series of yes/no questions where each successive step only shows the relevant items.

If we do switch to this format (assuming it's faster/easier/better) I think that'd be a good time to introduce the new "does this feature give you trouble" question, because we'd be messing with the question format anyway. I guess the first step would be deciding whether switching to that format would work better or not in the first place?

[LeaVerou]

I think when you have such a long list of questions, it's very tedious to go over them twice, even if it's a reduced set. I do agree however it would be good to improve efficiency and cognitive overhead when respondents go over them. I wondered if making the "Yes/no" questions checkboxes and having two columns would work, but then it starts looking too close to the dreaded long matrix question

[SachaG]

Hmm yeah good point. Two other possibilities:

1. Same setup as above but "check items where X" ("check the libraries you have heard of") instead of yes/no.
2. Same setup as currently but go through the options sequentially (Have you heard of React? If so, have you used it? If not, are you interested in learning it?" etc.).

I think 1. might be the best but the downside is that it's harder to distinguish between someone having not answered the question yet (or skipped it) and someone who just hasn't heard of any of the items. But then maybe we can have an explicit "I haven't heard about any of these items" button…?

[SachaG]

It's not a drastic change but I think grouping the options like that might be worth a try, and I think it's close enough to the current format that it wouldn't impact the ability to make historical comparisons too much.

This is for libraries though, for features I think keeping things the same and then doing a follow-up question is probably best since the current feature question doesn't quite follow the same pattern anyway.

[SachaG]

Oh actually another idea (or someone might have mentioned it already [EDIT: this is exactly what @LeaVerou suggested actually!]), but we could do the follow-up inline with the question, but only if people check that they've used a feature. This way we don't modify the original question at all but are still able to collect extra data?

Also if the follow-up question consists of checkboxes rather than e.g. rating a feature on a scale from 1 to 10 like in a matrix question, it makes it easier for people to just skip the follow-up if it's not relevant (for example maybe they have no issues with the feature at all, so they just move on).

[LeaVerou]

Yup, in fact that's basically what I suggested in the email thread:

What if we have a question that appears dynamically if they select "Know what it is, never used it" or "I have used it":

Would you use it in the future?

• Yes
• Yes, once widely supported
• No

Obviously, as with everything that appears dynamically, it should be done in a way that does not make the UI jump around.

Note we need to collect this info even if they have just heard of it, as these may be reasons they didn't use it in the first place.

I really like the multiple options you're proposing here as opposed to just focusing on browser support, though with that many choices I'd worry about cognitive overhead, and it's hard to make the UI not jump around too much when the question is shown.

[SachaG]

I guess it depends on your definition of "used it"… for me that includes trying it out and then realizing it's not usable in production, for example. So I would probably vote for not showing the follow-up when people say they've just heard of a feature, as to me that means they haven't done any actual coding with that feature. I also want to avoid lengthening the survey too much, which I feel like triggering the follow up for 2 out of 3 potential answers would do.

As for UI jumping that's a good point, maybe we can use transitions to smooth it out or something.

[SachaG]

Btw for the 2018 State of JS survey we actually had "what do you like about X" and "what do you dislike about X" questions for each of the libraries: https://2018.stateofjs.com/front-end-frameworks/react/

I don't remember how those questions were phrased but I could see reintroducing them in some form as a follow-up to the libraries questions to parallel what we're discussing for the features questions.

[SachaG]

Oh and we could have an "Other…" freeform field too, I think this would be a pretty awesome way of collecting really granular, qualitative data for a specific feature.

I think it'd be cool to also let people know that what they type in that box has a very high chance of being read by people at Google, Apple, Firefox, etc. who can actually do something about those issues!

[SachaG]

Moving UI discussions to https://github.com/StateOfJS/Monorepo/issues/99

[SachaG]

I think we can probably declare as a rule that if something doesn't exist on MDN or CanIUse yet it's too new to be included in the survey (thinking of object-view-box specifically here).

[SachaG]

@LeaVerou does it make sense to ask about color fonts separately from font-palette?

[LeaVerou]

@LeaVerou does it make sense to ask about color fonts separately from font-palette?

Absolutely. Not everyone who uses color fonts needs to customize their colors. Also color fonts existed for a lot longer than font-palette.

[LeaVerou]

Closing this since we now use separate issues to track feedback.