surveys
surveys copied to clipboard
State of HTML 2025 Suggestions
Browser Interoperability Opinion Question
Current question:
The lack of browser interoperability is a major obstacle to web development
Issue: people might interpret this as "[when there is a] lack of browser interoperability [it] is a major obstacle to web development" and check "agree" whether or not it's something that they experience right now.
Reword it to:
The lack of browser interoperability is a major obstacle to web development today
Clarify the term "validation" to avoid confusion with form validation:
I’ve moved to speaking of “conformance checking,” and only to speak of anything valid in the context of the output being (in)valid HTML or CSS. While it has the problem that not everyone makes the connection to HTML validation (an expression that may be an alternative, too, and which I’d prefer over “DOM validation”), it seems to prevent being mistaken for input validation.
Ask about devtools? (which features people use/wish were better?)
- moveBefore https://github.com/whatwg/dom/issues/1255
- alternative text for generated content: https://adrianroselli.com/2020/10/alternative-text-for-css-generated-content.html
Thanks for driving this effort!
Here are some suggestions after reviewing the survey result form 2024. (For full disclosure, I work on Chromium)
-
We recommend including the Web Audio API and Web MIDI API in future surveys. While Web Audio API has baseline browser support according to MDN, collecting broader developer feedback will significantly benefit browser implementers and the W3C Audio Working Group in addressing existing interoperability nuances. Web MIDI API's omission is equally critical, representing a blocker for a class of web applications.
-
The current survey results omit any mention of Device APIs (Bluetooth, HID, NFC, USB). This set of APIs is implemented in Chromium based browsers, dedicated browser apps (e.g. Bluefy), Electron, and nodejs libraries (e.g. node-usb, node-hid); though not Safari or Firefox. It would be beneficial to gauge and understand developer interest and demand. Such insights could play a crucial role in advocating for and ultimately fostering broader cross-browser support for these important capabilities.
-
The survey doesn't talk about testability around installed web apps, which we believe to be a big dev pain point. For example, testing the site being displayed with the 'window-controls-overlay' display mode.
Thank you for considering these suggestions.
cc: @scheib @dmurph
A few more:
- People responding to the survey seem confused between 'File Handling API', where they can register their installed PWA to handle file launches from the OS, and the 'File System' APIs like Writeable File Handlers etc. It might be good to clarify somehow.
- "Web Share" (which as far as I know is implemented on all platforms now for Chrome) also seems to be confused with "Web Share Target". "Web Share" allows a site to do a 'share' action to another app. "Web Share Target" allows an installed PWA to be the 'receiver' of shared items. For Chrome this is currently only implemented on ChromeOS and I believe Android. On Edge, they have this also shipped for installed PWAs on Windows.
- Drop web components section?
- I personally know very little about them and it always makes it hard to analyze the resulting data.
Devtools
I think it could be interesting to ask which devtool features people know about and/or use. Maybe split by tab? e.g.
Which feature of the Elements devtools tab do you regularly use?
- [ ] inspecting an element's CSS styles
- [ ] highlighting an element's grid/flexbox layout
- [ ] editing an element's inner HTML
- [ ] ...
Which feature of the Console devtools tab do you regularly use?
- [ ] running code in the console
- [ ] logging out using console.log()
- [ ] logging out using console.table()
- [ ] ....
and so on.
One reason against including this would be that this is potentially data that browser vendors already have internally, but I'm not aware of that data being published anywhere; and also this would be browser-agnostic. And I think it could be quite helpful in letting people know about devtools features they are not currently using (I personally think discoverability is a huge devtools issue).
- Move State of CSS's accessibility questions to State of HTML
Drop web components section?
- I personally know very little about them and it always makes it hard to analyze the resulting data.
The 2024 results were very useful to me to analyze the quality of Web Components MDN docs: https://github.com/w3c-cg/webdocs/issues/1#issuecomment-2830399247
Generally, statements about how people learn and use docs and whether they are useful or not useful is quite interesting to me. Why do people know very little about WCs? Are they badly documented? Are WCs too low-level and mostly abstracted away by frameworks?
Colour input alpha attribute and colorspace attributes
Dialog closedby attribute (enabling light dismiss)
Button command/commandfor attributes
The 2024 results were very useful to me to analyze the quality of Web Components MDN docs: w3c-cg/webdocs#1 (comment)
Maybe we could keep some questions about WCs (especially about pain points) but not necessarily dedicate an entire section to them?
Web Components section is still useful. Fine to slim things down. One question I'm curious about and I wonder if this bears out in the data... is the "7% dislike" statistic a majority of people who tried them and never looked back? Or is it people who are frequent users and care about the technology but are being harsh critics?
Can we change the Baseline question to one about the perception of the web as a platform?
The first one would give us a one time indication in 2025 that things have changed with recent improvements via Baseline and Interop. The second question would be an evergreen question to see where we are in absolute terms, and to track changes over time.
Q1 Compared to the past, do you think new web features are becoming stable across major browsers faster today, slower today, or at about the same pace?
Much faster Somewhat faster About the same Somewhat slower Much slower I don’t know
Q2. "How satisfied are you with the speed at which new web features and APIs become reliably usable across major web browsers?" Very Dissatisfied Dissatisfied Neutral Satisfied Very Satisfied
Compared to the past, do you think new web features are becoming stable across major browsers faster today, slower today, or at about the same pace?
I think this might be a bit too vague since "the past" is very subjective…
How satisfied are you with the speed at which new web features and APIs become reliably usable across major web browsers?
I also don't think we necessarily need both questions, they seem to more or less be asking the same thing to me?
To review, this is the question we have currently:
The lack of browser interoperability is currently a major obstacle to web development (disagree/agree/etc.)
If you want to measure people's thought on the speed of improvement, we could adapt your second question to fit the same format and replace it with:
New web features and APIs take too much time to become reliably usable across major web browsers (disagree/agree/etc.)
Just a quick note that after taking the input here into consideration (and the community input that followed https://lea.verou.me/blog/2025/design-state-of-html/ ) @SachaG and I have been fleshing out the outline here. It's already shared with @atopal and @foolip, if any other stakeholders want to have a more involved role in fleshing out the outline feel free to request access!
Thank you @LeaVerou! I see that ctx.drawElement() (HTML in canvas) is in there and that was my main request. @progers @schenney FYI
Thank you @LeaVerou! I see that
ctx.drawElement()(HTML in canvas) is in there and that was my main request. @progers @schenney FYI
I’m wondering about adding a common pain point around this too, e.g. "Rending rich text on canvas is painful".
Btw the survey preview is here, though we're still fleshing out several things (common pain points + re-adding a Content section are the main ones, the rest are small tweaks).
There seems to be a layout bug when clicking the teal "progress bar" at the top of each page to jump between sections. Here's what it looks like for me:
I’m wondering about adding a common pain point around this too, e.g. "Rending rich text on canvas is painful".
Rich text rendering is indeed a main use case for ctx.drawElement().
The ctx.drawElement() feature is very early in its lifecycle so I don't expect many to have even heard about it. But I do expect a lot of developers to want it, and will be looking at how many indicate "interested" next to their choice.
I think the freeform question "What are your pain points around generating and rendering graphics, sound, or video?" should also provide a place to mention pain points for canvas.
@foolip it should look like this:
what browser/platform was this on?
@SachaG it was on Chrome 138.0.7204.101 on macOS 15.5 (24F74). It seems like it's broken between two breakpoints, from width ~990 until width ~1200. Narrower or wider than that range it's fine.