Meta: Do we ask about features without browser support?

[LeaVerou]

There are currently a number of issues about CSS features that don't yet have any browser support, but that developers may have heard of and be excited about:

• 4

• 7

• 8

• 20

• 29

What should be the general policy here?

[SebastianZ]

29 does have browser support in Firefox for quite some time already. The other browsers just didn't catch up yet.

To the general question, yes, those features should definitely be part of the survey, in my opinion. The question is just how to ask for them.

If the goal is to provide implementors with the info about what to prioritize, the question should be something along "What are you looking forward to the most?". The way to answer this question is also important. It could be a single choice, multiple choices (e.g. three of all) or even an actual prioritization list.

And if we agree on adding those to the survey, we should probably add some more to the list. Here's a bunch of suggestions (disregarding their spec. stability):

• corner-shape
• animation-composition
• Scoped styles
• @when and @else
• Exclusions and shape-inside
• Extensions
• Paged Media features
• Masonry layout
• image()
• Spatial navigation
• line-clamp and related properties
• Regions
• Rhythmic Sizing
• Round Display
• shape()
• Speech
• text-space-trim
• Spread distance and inset for text shadows
• Generalized and extended attr()
• toggle()
• Scroll-linked Animations
• Grid-structural selectors
• color-contrast() (or contrast-color() as it's called from now on)

Some are probably very niche, others presumably cover a very common need.

Sebastian

[LeaVerou]

I wonder if we could hide the "I have used it" option for features with no implementations. @SachaG what do you think?

[SachaG]

I think if we want to ask about features with no implementation we might as well give them their own question format? It could be something like "don't know about/know about but don't care/excited about it"? But then yes as https://github.com/Devographics/Surveys/issues/36 mentions there's some overlap with the "Missing Features" question so we could remove that one.

[SebastianZ]

This definitely overlaps with the missing features. The difference here is that the participants are explicitly told that those features exist while in the missing features question they could come up with something of their own.

So, the goal would be the same as for asking for missing features. Both provide some priorization information for specifications and implementations. Though asking about features without browser support is approaching it from the other side. This question lets authors know about something and they may decide whether it matches their use cases or not while when asking for missing features, people come up with their use cases and they are matched against existing features.

Sebastian

[ramiy]

There are currently a number of issues about CSS features that don't yet have any browser support, but that developers may have heard of and be excited about:

• Feature: object-view-box #4
• Feature: CSS Nesting #7
• Feature: Trigonometric functions (sin(), cos() etc) #8
• Feature: margin-trim #20
• Feature: Two-value syntax for display #29

What should be the general policy here?

@LeaVerou ,

Just to be clear, trigonometric functions (sin(), cos() etc) #8, have browser support. They just not supported by all browsers. They should be treated as incompatibilities CSS features #36.

[SachaG]

So to recap, I suggest adding a new feature section (similar to Layout, Shapes & Graphics, etc.) entitled "Upcoming Features" or similar which would list 10 upcoming features that either are not implemented at all; or have poor browser support (poor enough to make asking people if they've used it a bit meaningless).

For these features, we'd have a different set of options. Maybe something like:

• Never heard about it
• Heard but not interested
• Heard and interested

Or maybe:

• Never heard about it
• Heard and mildly interested
• Heard and very interested

This would let us measure which upcoming features generate the most interest.

[SachaG]

• [ ] decide criteria for including a feature and come up with list of upcoming features
• [ ] decide on list of options

[SebastianZ]

I like the idea of "upcoming features". I just wonder, how you imagine this to be presented in the survey? In https://github.com/Devographics/Surveys/issues/36#issuecomment-1228439979 you mentioned a freeform text field to ask for them and here you are suggesting a list of ten predefined features people can choose from. If both are shown, the freeform field should be part of that section, i.e. it should be placed directly below that list and be titled like "Any other upcoming features you're looking forward to?".

Sebastian

[SebastianZ]

I currently can't come up with some precise criteria for which ten features to select, but I'd say general author interest, number of possible use cases, implementor interest, and specification status should play some role here.

Sebastian

[SachaG]

After talking with @LeaVerou, our conclusion was that there isn't really a clear-cut difference between features with or without browser support. A feature could be:

• supported in all browsers
• supported in some browsers
• supported in only one browser
• supported behind a flag
• supported using a polyfill
• supported using a pre/post-processor

So it's tough to know where to draw the line here… Instead we'll present all features together, and this has the added benefit of collecting historical data as early as possible in a feature's lifecycle.

So basically the opposite of what I said here. We'll keep things simple and have the same options for all features, even those that are barely supported (usage will be near 0% but that's fine, we can still track interest).