MDN short surveys design

[foolip]

I have proposed to run short surveys on MDN to get some additional signals on the relative interest in the different features being proposed for Interop 2023.

This is not the only input for Interop 2023, just one more data point, and will have its blind spots.

We have a lot of proposals, and some of them have a very different target audience. Most of MDNs page views are for JavaScript reference docs like Array, so asking all MDN visitors about all features is not practical. Instead I've tried to created groups and targeting based on topic.

In the lists below, the survey wording is the first level and the proposals these map to (not shown in survey) is in a nested level. This is inherently an imperfect mapping, and wording choice can affect the results.

Prompt and Question

Survey prompt before expanding: "Browser vendors are working together to improve feature support across browsers. Shape the future of the web by taking this 1-question survey!"

(I'm open to toning down the "Shape the future of the web" bit.)

Question: "For your needs as a developer, which features should be improved across browsers in the coming year? This means enabling support or fixing bugs. Please rank up to 5. (This is not a complete list, other features may also be planned.)"

CSS & HTML

For pages under CSS and HTML, show this list:

• CSS attribute references (attr() function)
  • attr() support extended capabilities (Interop 2023) #86
• CSS backdrop-filter property
  • backdrop-filter #210
• CSS :blank and :empty pseudo-classes
  • :blank pseudo-selector support (re form fields) #179
• CSS color font feature detection and palettes
  • Font feature detection and palettes #164
• CSS color spaces and functions (color(), lab(), gradients, etc.)
  • Interpolation color space for gradients #109
  • Add P3 in WebGL Canvas tests to Color Spaces and Functions focus area #168
  • CSS Relative Color Syntax #226
• CSS containment (contain, contain-intrinsic-size, content-visibility)
  • css-contain-2 and contain-intrinsic-size #189
• CSS custom properties (@property)
  • Better support for @property #158
• CSS :dir() pseudo-class
  • :dir() improved support #177
• CSS outline property (including outline-color)
  • Focus Outline Color #166
• CSS images (border-image, image(), image-set())
  • css image-set() #144
  • CSS border-image #146
  • CSS image() function #153
• CSS leading-trim property
  • CSS leading-trim #155
• CSS mask property (mask-image, mask-mode, etc.)
  • Better Support for CSS masks #148
• CSS math functions (round(), sin(), pow(), abs(), etc.)
  • CSS Math Functions #149
• CSS motion path (offset-path, offset-distance, etc.)
  • CSS Motion Path (offset properties) #227
• CSS media queries range syntax (example: @media screen and (428px < width < 744px))
  • Range syntax for media/container queries #141
  • Media Queries 4 #154
• CSS :nth-child() pseudo-class with selector-list argument
  • :nth-* pseudo-classes interoperability #225
• CSS scoping (@scope at-rule)
  • @scope #183
• CSS Typed Object Model (computedStyleMap() API)
  • Typed OM (houdini) #163
• CSS :user-invalid and :user-valid pseudo-classes
  • :user-invalid & :user-valid browser support #178
  • :empty pseudo-selector (spec updated) #180
• Custom Paint API (Paint Worklet)
  • paintAPI (houdini) #160

APIs & JavaScript

For pages under API and JavaScript, show this list:

• Canvas text rendering
  • Canvas text rendering and metrics #159
• Clipboard API (navigator.clipboard)
  • Clipboard API #143
• Editing (contenteditable)
  • contenteditable #188
• File System (navigator.storage.getDirectory())
  • Origin Private File System (OPFS) #172
• History API (window.history)
  • History and navigation, excluding the navigation API #199
• Import Maps
  • Import Maps #184
• Intersection Observer
  • Intersection Observer v2 #173
• Navigation API (window.navigation)
  • The navigation API #200
• OffscreenCanvas
  • OffscreenCanvas #161
• Pointer Events
  • Pointer and mouse events #202
• Priority Hints (fetchpriority HTML attribute)
  • Priority hints #223
• Push notifications
  • PWA manifest and push notifications #218
• Storage quota estimation (navigator.storage.estimate())
  • StorageManager.estimate #221
• Temporal API
  • [JS API] Temporal #169
• URL (parsing and API)
  • URL Standard – new URL() #145
• User agent client hints (navigator.userAgentData)
  • User agent client hints  #219
• Web Codecs (AudioDecoder, VideoDecoder, etc.)
  • WebCodecs API #175
• Web Components (custom elements, Shadow DOM, etc.)
  • Web Components #181
  • Form-Associated Custom Elements #203
  • Constructable Stylesheets & adoptedStyleSheets #204
  • CSS Module Scripts #206
  • Imperative Slot Assignment #207
  • :host(:has(...)) pointing to light DOM content #208
  • @font-face and @property constructs in Shadow Roots #212
  • Composed Selection (Selection APIs for Shadow DOM) #216
• WebTransport
  • WebTransport #186

Not Included

These proposals aren't included, for a variety of reasons:

• font-style for variable fonts with either Slant or Italic axes. #64 (hard to explain succinctly)
• Support for speak-as property to control aural presentation #114 (MDN short surveys design #196 (comment))
• Container Queries  #133 (already have strong signals, likely to dominate results if included)
• :has() pseudo-class #134 (already have strong signals, likely to dominate results if included)
• inert attribute + :modal pseudo-class #135 (MDN short surveys design #196 (comment))
• User gestures #142 (hard to explain the exact scope)
• Machine Learning in the Browser #152 (MDN short surveys design #196 (comment))
• WebDriver BiDi #165 (target audience is mainly automation frameworks, not general web developers)
• Input write mode consistency #167 (hard to explain succinctly)
• RegExp lookbehind assertions #171 (too small?)
• css conic-gradient #174 (already supported, unclear if there are bugs)
• JPEG XL image format #176 (unclear which bucket makes sense)
• Animated AVIF #182 (unclear which bucket makes sense)
• WebGPU #185 (investigation effort)
• Web Compatibility #187 (mix of features)
• ES Module support for Web Workers #192 (this limitation is probably not widely known)
• Support for CSS Flexbox/Grid Gap Decorations #193 (new feature, likely to be conflated with flex gap)
• Non-responsive image loading #195 (hard to explain succinctly)
• MathML Core  #197 (unclear which bucket makes sense)
• Mobile Testing #201 (test infrastructure)
• Consistent accessibility tree outputs #211 (not web exposed, affects users, not developers?)
• Cross-Origin Opener Policy: restrict-properties #213 (network feature, unclear which bucket makes sense)
• SVG 1.1 and 2.0 #214 (very broad, like MathML unclear which bucket)
• Web Performance: Paint Timing #215 (investigation effort)
• SameSite cookie handling #217 (network feature, doesn't fit either bucket)
• EditContext API #220 (unlikely to be recognized by web developers, not documented anywhere yet?)
• requestAnimationFrame in WorkerGlobalScope #222 (could be included under APIs, but hit limit of 20)
• Media pseudo classes: :paused/:playing/:seeking/:buffering/:stalled/:muted/:volume-locked #224 (could be included under CSS, but hit limit of 20)

[captainbrosset]

Just a thought: should highly requested features like Container Queries or :has be removed? I think we already know developers want them, and they will probably dwarf all of the other features in the survey.

[foolip]

@captainbrosset I think those two are indeed the two that will be the most popular choices, based on State of CSS results. The question becomes if people will notice the glaring omissions and conclude our survey is nonsense and abandon. And to what extent will this be mitigated by saying it's not a complete list?

[foolip]

I've updated this issue to describe two targeted surveys. It's hard to make a perfect split and two features are listed in both, while others aren't included in either. Open to feedback. I think we shouldn't exceed 20 options for either survey, that starts to be unreasonable.

[foolip]

I want to highlight a few things I think are tricky for discussion in #209:

• Should Web Components be broken down further? I can't see how, and suspect developers don't know the names of all the parts, or use different terminology than I would come up with.
• Should we ask about AVIF and JPEG XL support?
• Should we ask about MathML?

[jgraham]

Being asked to compare fixing existing features with adding new features is quite strange e.g. the "History API" proposal is mostly fixing existing features and is only somewhat related to the location object. There's also a number of other problems here e.g. we know that editing APIs are so complex that editing basically has to be implemented using additional js libraries, so I wouldn't expect those things to come up very high, but that doesn't mean that work to make those libraries more reliable isn't going to make the web better for users.

Also the options aren't very fungible on the browser side; although maybe the CSS-* features are more or less the same team, there isn't a prioritisation decision to be made on those features vs e.g. clipboard APIs because different people would do the work.

Overall I'm not sure that the premise of having a survey that maps ~ 1:1 with proposals is really likely to give us data that is unambigously useful.

[tapananand]

Just a thought regarding exclusion of #213 from the survey, I think the developer impact here primarily is not being able to use WebAssembly threads and SharedArrayBuffer, so could that be considered under the JavaScript category similar to other things like WebNN or WebTransport?

[foolip]

I've updated the proposal again, keeping to 20 options in each survey. Some hard and subjective calls were required, and in the end I had to just omit some features like #224 because there was no obvious other option to remove instead.

When reviewing or proposing changes, when suggesting an addition, please also suggest a removal so that we stick to 20.

[foolip]

@tapananand sorry I didn't respond earlier. I think both WebAssembly and SharedArrayBuffer would be recognizable options to developers, but also much broader than what's proposed in #213. If we did have a strong signal that wasm (for example) was important, I'm therefore not sure how to use that signal. We have this problem to some degree in other cases as well, like "CSS color functions" actually being more broad than what is proposed as an addition for Interop 2023. I've done as well as I could with the proposal now, but recognize it's imperfect. It's still open to suggestions though.

[foolip]

OK, so now tweaking the question a bit in response to #209, @jensimmons's feedback in particular. I suggest:

For your needs as a developer, which features should be improved across browsers in the coming year? This means enabling support or fixing bugs. Please rank up to 3. (This is not a complete list, other features may also be planned.)

Regarding "Please rank up to 3", I've learned that we can pick another number. Given that we now have 20 options in each survey, I suggest we allow up to 5 choices instead.

[nt1m]

@foolip #225 and #224 could be grouped under the "CSS pseudo-classes" category.

[foolip]

@nt1m the pseudo-classes are a bit of an odd category already, and the existing ones (:blank, :empty, :modal, :user-invalid, :user-valid) aren't really a natural grouping, but I thought it'd be better than listing them individually or not at all. It would be a very long list if we add in #225 and #224.

I do actually think that both #225 and #224 are more likely to be recognized and picked than at least #114, so if we could find one additional optional to remove, we could add them both separately. We'd also need to rename the existing option for pseudo-classes I think, but not sure to what?

[foolip]

There are staging links for the two surveys now for review:

• https://survey.alchemer.com/collab/7081564/MDN-Interop-2023-CSS-HTML
• https://survey.alchemer.com/collab/7081727/MDN-Interop-2023-APIs-JavaScript

@web-platform-tests/interop please review. (I'll put this on Thursday's agenda as well.)

[nt1m]

@foolip Thanks for putting these together! Here are my initial thoughts:

• "Web Components" should only be in one of the two surveys, possibly just the JS one (most the APIs involve JS)
• "Custom Paint API" should only be in one of the two surveys, possibly just the CSS one
• "Neural Network API" I doubt that is going to be part of next year's effort, due to the early stage of the spec and the fact that it's difficult to test, so I'd rather leave it out for something that is more likely going to get in.
• CSS color spaces or CSS images could include gradient color space interpolation (issue Interpolation color space for gradients #109)
• I think issue :nth-* pseudo-classes interoperability #225 could actually fit in "CSS pseudo-classes" as ":nth-child() with selector-list argument" as it's an extension to existing pseudo-classes.

[foolip]

We discussed this in #240 and agreed to the following changes:

• "Web Components" only in APIs & JavaScript
• "Custom Paint API" only in CSS & HTML
• Drop "Neural Network API"

Then I was to work through the last two bullets and suggest on the issue. Here are my suggestions.

Change the wording from:

CSS color functions (color(), lab(), etc.)

to:

CSS color spaces and functions (color(), lab(), gradients, etc.)

The final bullet is the trickiest. The pseudo-class option is currently:

CSS pseudo-classes (:blank, :empty, :modal, :user-invalid, :user-valid)

It's already stretching what's reasonable to group, and if this options ranks highly we'll have to do a bit of guessing about which pseudo-classes drew the attention. Adding :nth-child() makes this even harder, but here's what it would look like:

CSS pseudo-classes (:blank, :empty, :modal, :user-invalid, :user-valid, :nth-child() with selector-list argument)

I think my best suggestion in the end is to split it like this:

• CSS :blank and :empty pseudo-classes
• CSS :user-invalid and :user-valid pseudo-classes
• CSS :nth-child() pseudo-class with selector-list argument

That would push the total option count to 21, so we'd remove the speak-as option, as the one I guess will have the least recognition of all the options. (Accessibility is first and foremost a user need and also a developer specialization, so judging its importance by overall web developer demand is hard.)

@nt1m between the different options for pseudo-classes, do you have a preference?

[foolip]

Given time constraints I'll make a decision myself, to split pseduo-classes into 3 and drop speak-as. The :modal pseudo class also won't be listed, it's a small fix to implement and I think the case for it is strong without survey results. (We're planning to support #135.)

[foolip]

I've made the updates now. Since there was now room in the API section, I added "Storage quota estimation (navigator.storage.estimate())"

[foolip]

This survey is now live on MDN, as "pick up to 5" questions.

[foolip]

The results are in now:

• Results of MDN CSS & HTML survey #245
• Results of MDN APIs & JavaScript survey #246

[romainmenke]

@foolip Where and how was this shared?
Is there a way to be notified of surveys like these?

[foolip]

@romainmenke I got the results from MDN via email and posted them to #245 + #246, so that's how they were shared this time. Mozilla is still working on the process for MDN short surveys, and this was only the 3rd such survey, so it's still in "beta" it's fair to say.

There's also a newly formed WebDX Community Group where we're collaborating on research like this, and web-platform-dx/developer-research#9 is the issue to follow for how we intend to make results public by default, not just via ad-hoc GitHub issues like I've done here. Please consider joining the CG if that sort of thing interests you!

[romainmenke]

Please consider joining the CG if that sort of thing interests you!

Joined :)
Thank you for sharing this.