Freeform questions: discourage non-meaningful answers

[SachaG]

Currently when asking people e.g. what pain points they have with CSS, we get a lot of answers such as "nothing really", "none that I can think of", etc. which pollute the data.

It would be good to find a way to discourage that and let people know they can just leave the questions blank.

[huijing]

Currently WIP

CSS pain points

These refer to CSS that already has been spec-ed out, but either not supported by browsers, or there are aspects of its usage that are unwieldy for certain use-cases

1. Lack of subgrid support
   • https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/
   • Useful for having elements within grid items to align with each other (grandchild grid items to align)
   • Overcomes the issue with being unable to set a grid item to span all grid rows if the number of grid rows are not explicitly defined
2. Lack of masonry support
   • https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/
   • Native support for masonry, good for layouts that have items which are uneven in a single dimension, i.e. if there are gaps left by shorter items, the next one moves up to fill said gap
3. Variables in media queries
   • https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/
   • Now that more folks are declaring CSS values in variables (—sm-breakpoint: 32rem), it would be useful to be able to use these variables within media queries
4. Flexbox gap support
   • https://ishadeed.com/article/css-wishlist-2023/#flexbox-gap-support
   • gap is in an awkward state where it was retroactively added to Flexbox after the feature was widely available, thus we currently do not have a good way to detect if a browser already supports the gap property for Flexbox or not
5. Lack of support for leading-trim
   • https://ishadeed.com/article/css-wishlist-2023/#leading-trim
   • https://daverupert.com/2023/01/css-wishlist-2023/
   • Resolves common complaints about text not looking vertically centred due to extra space reserved by the default line height
   • Background (optional but nice for context)
     • The way leading is calculated today was defined when CSS first debuted back in 1996, where the browsers would split the leading in half and put it above and below each line in order to avoid uneven bounding boxes
     • But every font has a different default line-height which is usually taller than the text it contains to accommodate accents or special characters, so this plus the half-leading leads to a lot of uncontrollable spacing issues
6. Detect when element position: sticky is active
   • https://ishadeed.com/article/css-wishlist-2023/#detect-when-sticky-is-active
   • Useful if you want the sticky element to have certain styles triggered when it’s actually being sticky
   • Might be achievable once we get style queries (see https://www.w3.org/TR/css-contain-3/#style-container)
7. Styling of grid lines
   • https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/
   • The ability to style separator lines between grid tracks
   • CSS multi-column has a column-rule-style property but no other layout properties have this
8. Parent selectors
   • Currently, there is no direct implementation, although it is now possible to use :has() to achieve a similar result
   • Technically, it’s not impossible but there were performance implications for implementing it (see https://snook.ca/archives/html_and_css/css-parent-selectors)

CSS missing features

These are more wishlist style ideas that do not exist at all at the moment

1. Native support for visually hidden content
   • https://www.matuzo.at/blog/2023/css-wish-list/
   • Currently, most developers have a go-to set of styles to implement visually-hidden styling to content that does not display for visual users but are still detectable by assistive technologies
   • A native CSS implementation would be a nice-to-have for this use-case
2. Alt text for generated content
   • https://www.matuzo.at/blog/2023/css-wish-list/
   • Currently, generated content is still being factored into accessible name computation so it would be nice if we could either exclude it, or better yet, provide an accessible name instead
3. Animation of height to auto
   • https://chriscoyier.net/2022/12/21/things-css-could-still-use-heading-into-2023/#animate-to-auto
   • A common use-case for this is the accordion pattern, where content should animate smoothly from 0 to the height of the content
   • All current implementations are workarounds to this browser limitation, each with their own set of issues
4. Anchored positioning
   • https://meyerweb.com/eric/thoughts/2023/02/08/css-wish-list-2023/
   • Currently, the ability to position an element in relation to the edges of another element that isn’t a containing block does not exist
5. Flex wrapping detection
   • https://ishadeed.com/article/css-wishlist-2023/#flex-wrapping-detection
   • Currently, there is no way to detect if one of your flex items has wrapped down to the next line, it would be useful for if you wanted to modify the styling when that happens
6. More than 2 pseudo-elements per element
   • https://blog.jim-nielsen.com/2023/css-wishlist/
   • Sometimes, additional pseudo-elements would be helpful to achieve certain visual effects
7. SVG-in-CSS
   • https://blog.mayank.co/my-css-wishlist-2023
   • The ability to use inline SVGs within CSS itself, e.g. for background would allow us more granular control of the SVG’s styles
   • Currently, we can only add the inline SVG to the markup and apply CSS from there

[SachaG]

Those are good lists but I feel like they might both converge a bit too much? By that I mean that a couple items in the "pain points" list are actually missing features too, or else browser incompatibility issues (which are covered by yet another question).

Specifically, I think that the following could be in the "missing features" list:

• masonry
• variables in media queries

The following feel more like "browser interoperability" items:

• subgrid
• flexbox gap

And leading-trim could be a full-fledged feature if there's already a spec for it?

But at the end of the day, maybe it doesn't make sense for the "pain points" question to have predefined options? Maybe a better way to do it would be to 1) ask about browser interop issues; 2) ask about missing features, and only then 3) ask about other pain points in a freeform field, meaning that we would hopefully select out any answers that fall into categories 1) and 2) and get better that for that question?

[SachaG]

Also I think we can probably keep Scoping and Mixins in missing features?

[huijing]

Also I think we can probably keep Scoping and Mixins in missing features?

Ah, that actually fits well. Let's do it.

Let me re-arrange and tweak the list some more based on your response.

[SachaG]

Switching to a "predefined options + other… option" format which I think will solve the issue of people answering "none".