Meta: Browser incompatibilities, CSS pain points and features missing from CSS overlap about surveys HOT 11 OPEN

I think it makes sense to remove the "missing features" question altogether actually.

from surveys.

As stated earlier, the important point is to differenciate the questions more by clarifying why they are asked.

I believe asking about missing features can provide valuable input. The goal behind it is to provide some information about priorization for new features.
The answers may be valuable for spec. authors to know what are the topics they should focus on in their specifications. And they may be valuable for implementors to prioritize their implementations of new features that are already specified. They may even provide incentives for completely new features.

@SachaG and I were thinking of adding some sort of autocomplete to this question, either from the survey's features list, and/or from caniuse. I wonder if that would help?

That would surely help. But I wonder how smart this autocompletion could be. In the best case it would tell people about existing features by matching a list of keywords and possible aliases with them. If caniuse data will be included, maybe some kind of full text search across the feature descriptions might help.

Browser incompatibilities should really just be about incompatible implementations between browsers. If we do not add a separate question about features that have insufficient support across browsers, then its description should clearly state that this includes incompatibilities due to lack of support.
The goal here is to get to know about which implementation differences, specification holes and browser bugs to focus on.
Again, I would split out the question about lack of support, but I can see by last year's answers that participants treated both the same.

Pain points should focus on features that are supported and work the same in all browsers but authors are still having difficulties with. This provides information about documentation, developer tools and authoring tools needs.

Sebastian

from surveys.

From an email thread, @stubbornella made a good point that wrt developer pain points we tend to hear disproportionately more about layout compared to other areas (e.g. typography). I wonder if we should have a What is missing / pain points question whose answer is structured around specific areas, e.g.:

• Typography
• Colors
• Layout
• Responsive design
• Components
• Visual Effects
• Other

(categories list obviously TBB)

from surveys.

Also, after talking a little bit with @stubbornella, it appears that the "missing features" question is very useful for prioritizing implementation work. So after thinking about it for a bit, how about the following structure:

• What CSS features you can't use today due to little/no browser support? (with autocomplete from features list and/or caniuse, since this is likely to be a longer and more constrained list)
• What features you feel are missing from CSS altogether? (freeform)
  Hopefully having the browser support question immediately precede it will reduce duplication and make it clear that this is not about browser support. Possibly with an explicit note to not include things mentioned in the previous question?
  This one could also use the breakdown in categories that I suggested above.
• Any other pain points related to writing CSS? (freeform)
  Again, hopefully having them in this order (and the "any other" wording) could reduce any implied duplication.

from surveys.

A variation on @LeaVerou's suggestion:

1. What upcoming CSS features are you looking forward to the most? (freeform textfield)
2. What features do you feel are missing from CSS altogether? (freeform textfield)
3. Any other pain points related to writing CSS? (freeform textfield)

from surveys.

I agree these need to be fleshed out a bit more to either be merged or be clearly separate. We don't want participants to be feeling like they need to repeat themselves 3x.

from surveys.

From #35 by @SebastianZ :

Having a look at the answers for features missing from CSS from last year, many of them actually do exist in one way or the other.

So the question is, do participants of the survey know that they exist (in a specification) and just mean that there is little or no browser support for them? Or don't they know about them?

I don't remember how the answers to this question were structured. If this was a multiple-choice list or if there was a free form field or both.

But maybe people could somehow be informed about it if a feature they mentioned there actually does exist. This might be directly while giving the answers or when presenting the outcome of the survey or both.

Sebastian

from surveys.

@SachaG and I were thinking of adding some sort of autocomplete to this question, either from the survey's features list, and/or from caniuse. I wonder if that would help?

from surveys.

I like this suggestion a lot! Thanks, @LeaVerou!

While the questions are already much more self-explanatory, also due to their order, I still believe a short one or two sentences description for them would clarify things further.

And just to be clear, these three questions put browser incompatibilities into the pain points bucket. So it should explicitly be mentioned there. It might also benefit from a categorization like the other two questions.

Regarding the categorization, how do you imagine the UI for it? I.e. how do you combine freeform with the categories? I think people should still have the possibility to provide feedback for multiple categories. But a text area for each category might be overwhelming.
A simple solution would be to add checkboxes for all the categories and let people check those to which they think their feedback fits. And then just have one text area in which they write all their feedback.
A more complex but better split solution would be to have a select for one category and a text area for it and + and - buttons to add or remove a category. Though that may lead participants to only provide feedback to one category.

And an example for the autocompletion: People should get "Scroll Snap" as suggestion when just typing "snap". If possible, it should also be lenient with misspellings like "scoll snap" or "scrollsnap".
Also, it should link to MDN and/or caniuse and/or provide a short description of the feature. With that, participants will easily know whether the feature really covers their use case.

Sebastian

from surveys.

What CSS features you can't use today due to little/no browser support? (with autocomplete from features list and/or caniuse, since this is likely to be a longer and more constrained list)

What about using a spelled-out feature list with the "don't know about/know about but don't care/excited about it" format I mentioned in #31 (comment) ? Can we come up with a list of ~10-15 features that will cover most people's needs?

from surveys.

What CSS features you can't use today due to little/no browser support? (with autocomplete from features list and/or caniuse, since this is likely to be a longer and more constrained list)

What about using a spelled-out feature list with the "don't know about/know about but don't care/excited about it" format I mentioned in #31 (comment) ? Can we come up with a list of ~10-15 features that will cover most people's needs?

I don't think it's a good idea for respondents to have to go through the entire list again. It's a very long list. The first time might be fun, because they may not have heard some of the features, but the second time it will just be tedious drudgery. If they are to pick from a list, we may as well ask them the first time they see each feature.

from surveys.