As far as i can tell, this is not a browser feature in the traditional sense. This spec simply defines a standardised URL that password managers can go to if they want to automatically update a password. All major browsers happen to have a built-in password manager, but if someone uses a third-party password manager, support for this will be independent of the browser.

It might still make sense to include a support table for it, but i'm afraid it could mislead a lot of developers/users into thinking that the feature wouldn't work or would always work in a specific browser. They might also think that the feature only works in browsers, which it does not.

Adding the support table to Caniuse also wouldn't paint a complete picture. For this data to really be useful, i think it would make more sense to expand the existing spec FAQ with all major password managers, or create a feature site for it, similar to Is Service Worker Ready? and Are We Distributed Yet?.

While I agree that the feature might not be in line with other traditional browser features, I’m not sure if I see a convincing argument not to include it in CanIUse. Many of the existing “traditional” features already live freely outside of the realm of web browsers, implemented by many other softwares—for example: H.264, WebM, and even ECMAScript and TLS!

I believe it’s safe to assume that the visitors understand the listings are provided for web development and web compatibility. Every other support table doesn’t present the whole picture, but only in the context of which browser and which version—Exactly what makes CanIUse so useful! In that sense, I don’t think they’ll be mislead to believe this specific feature is exclusive to browsers.

True, there are many other features that live outside the web, but they are very clearly containerised. In those cases you are either integrating it solely for browsers, or solely for non-browser tech. In this case you are doing a bit of both.

My convincing (at least if you ask me 😉) argument not to include it in caniuse:
If you are implementing a feature in a website and caniuse says it's 100% supported, it always means that 100% of your target audience will be able to make use of this feature.
If we created a support table for this feature, the percentage would be completely arbitrary. 100% could mean that 30% of your target audience can make use of it, while 0% could mean that 70% of your target audience can make use of it.

My thinking is this: because we only focus on a small subset of the password manager market, the support information is not useful. At the same time, adding this support table could mislead people, and could muddy the waters on how much you can actually trust the caniuse support percentage. Ergo, it is only harmful to add it.

If you are convinced that adding a support table is actually useful to some people, and that the same cannot be achieved by simply updating the spec FAQ, i would definetely be interested in hearing it!

I think I get where you’re coming from, but the thing is that password managers interact with browsers using browser plugins/extensions. Since they do not represent browsers’ capabilities, it’s hard for me to see anyone would be mislead to believe “100% supported (by browsers)” would somehow imply extensions are in consideration as well—They are out of scope by definition.

I think CanIUse support data would never describe about the target audience, but only about the browsers. In a hypothetical scenario, say there’s a CanIUse entry for WMV video format. Modern browsers do not support WMVs by itself, so it’s basically 0% supported. But the underlying OS might, or a browser plugin like Flip4Mac might. If your audience is only comprised of enterprise Windows users, then the actual number is 100%. If that’s Mac users, then it’s non-zero%; very much different from the data. Since factoring into the target audience to the development, rather than only the browsers, would be a deliberate choice, its burden should not be on CanIUse’s.

In that sense, I’m not quite convinced this inclusion would cause harm in one way or other, and then the concern would quickly fade away as long as there are some notes right along with the support table. I guess the decision is up to Fyrd, so I’m eager to hear their thoughts. 😉

Nevertheless, this very discussion is quite interesting in that how the web has evolved into is this everything-independent-containerized thing to many people. But historically and realistically I think it has never been and can never be, but the vendors are doing an absolute mad job to make sure to look like that’s the case.

I'm not sure i completely understand your argument, but before discussing whether or not it could be harmful, i think we need to establish that it could actually be useful.
I still don't understand how it can be valuable to focus on such a small subset of password managers, when we instead could add a support table in the spec, where we could list all major vendors and paint a complete picture?

The reason I've been quite hesitant to chime in on contributing directly to the spec—which is an absolutely great idea—is that it is out of scope of this project, so this is not the right place to discuss. As long as this feature is a part of web technologies (WICG, so more or less by definition) and there are support disparities, the support status will be useful to those who develop on the web platform. Since CanIUse is all about browser status, we include it, but only in the context of browsers, not of password managers, or any other software in general. Gathering the whole implementation status of a technology is a responsibility on that very technology, in this case the specification. At least that's what I believe.

That's why I talked about the hypothetical WMV scenario. The technology in itself can be implemented by many softwares, but as long as it is part of web technologies (hypothetical; by a W3C/WHATWG spec, or a de-facto standard, or an extension to an existing standard for a feature,) I believe it's hard to argue the support status will not be useful to web developers (e.g., H.264, WebM.) But should CanIUse include other implementation statuses; such as, VLC, MPlayer, ffmpeg, etc, for a complete picture? Probably not, so then should the feature be removed? That's also not a very good idea. So we focus solely on the browsers.

I immensely thank you for the thoughts and contributions, but it’s still hard for me to agree the inclusion of this feature will be either: misleading, or not useful, to the web developers in the context of web browsers. Please do chime in if I’m missing something. It is an interesting discussion for sure.