Graduate from Community Group to Working Group

[reillyeon]

Mozilla has announced an Intent to Prototype for this API. With multiple implementations this document can graduate from incubation to the standards track. We just need to pick a venue.

cc @saschanaz @marcoscaceres @gregstoll @tomayac

[tomayac]

Devices and Sensors WG seems like a natural destination?! Also CC: @anssiko.

[marcoscaceres]

DAS has too many specs already, lots of which have failed to get traction (which causes IPR concerns and prevents companies from joining).

Should really spin up a new group solely dedicated to this spec instead.

[anssiko]

What is WebKit’s position on this spec?

[marcoscaceres]

I don’t think one was ever filed.

[tomayac]

It was: WebKit/standards-positions#199

[marcoscaceres]

Ah, missed it somehow. Thanks @tomayac

[anssiko]

My expectation is WebKit will generate an official position to inform this matter. Thank you.

[reillyeon]

I agree that DAS seems obvious since "Device" is in the name however given the lack of group participation by Mozilla I don't think that is a good venue. A WebKit position wouldn't change that since Apple isn't a participant either.

I was going to nominate WebApps given it maintains the Gamepad API, which is both similar as a peripheral API and has overlap in the engineers working as editors and implementers.

Spinning up a new WG seems like a lot of work but once Mozilla gets a little farther in their prototyping work we can look into it.

[anssiko]

My recommendation is to make this a joint deliverable between the DAS WG and WebApps WG. The infrastructure is in place and in use.

Based on my assessment, a new WG would be too costly and is unlikely to garner support from the W3C membership.

[marcoscaceres]

I was going to nominate WebApps given it maintains the Gamepad API, which is both similar as a peripheral API and has overlap in the engineers working as editors and implementers.

I can live with that (though for the same reasons as DAS, WebApps has too many specs :( ).

Based on my assessment, a new WG would be too costly and is unlikely to garner support from the W3C membership.

Right, but that needs to be balanced against DAS and WebApps have too many specs already, which also means that both groups are too costly to join.

This is a larger problem that we need to address by creating a new group at some point.

[tomayac]

I agree that DAS seems obvious since "Device" is in the name however given the lack of group participation by Mozilla I don't think that is a good venue.

At the risk of pointing out something that is clear to everyone with a longer history in the DAS WG: did Mozilla consider joining the group at some point and decided against to, and if so, maybe would they be willing to join now?

[anssiko]

Mozilla has participated the DAS WG and has implemented and shipped APIs produced by the group in its now discontinued FirefoxOS product and certain versions of its Firefox browser. Re-joining WGs is normal and happens from time to time when companies' priorities change. I welcome Mozilla back to the DAS WG.

We have initiated charter refinement process to seek W3C community consensus on this important matter.

[scheib]

If appropriately related in scope, I don't see the concern of adding into the Web apps working group. Yes, there are several specifications there, but I'm not sure how putting them in another working group would improve the overall progress in the portfolio. If anything it would cause scheduling conflicts at things like tpac. I think the joint approach is quite good, given the scopes of the groups. This should also minimize any companies need when considering participating as most companies expected to participate in these have already engaged in these working groups, and it seems the incremental evaluation of charter updates is easier than joining new groups.

…

On Thu, Jan 15, 2026, 2:32 AM Anssi Kostiainen ***@***.***> wrote: *anssiko* left a comment (WICG/serial#218) <#218 (comment)> Mozilla has participated the DAS WG and has implemented and shipped APIs produced by the group in its now discontinued FirefoxOS product and certain versions of its Firefox browser. Re-joining WGs is normal and happens from time to time when companies' priorities change. I welcome Mozilla back to the DAS WG. We have initiated charter refinement process to seek W3C community consensus on this important matter. — Reply to this email directly, view it on GitHub <#218 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC6PG2HB4D2VJHJXLPDVWT4G5UCXAVCNFSM6AAAAACRSUWTJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJUGA3TCOJVGY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[marcoscaceres]

If appropriately related in scope, I don't see the concern of adding into the Web apps working group.

Right, but we literally just got the new Web Apps charter approved... we would need to recharter web apps again to add this, right?

Yes, there are several specifications there, but I'm not sure how putting them in another working group would improve the overall progress in the portfolio. If anything it would cause scheduling conflicts at things like TPAC.

That's actually fine... what we want is focused communities.

think the joint approach is quite good, given the scopes of the groups.
This should also minimize any companies need when considering participating
as most companies expected to participate in these have already engaged in
these working groups, and it seems the incremental evaluation of charter
updates is easier than joining new groups.

I don't disagree... but that wouldn't change with a new group either (more specs eats more time at TPAC regardless, so it's just a tradeoff and one that can be managed... we manage fine with DAS and WebApps overlaps... we just meet on another day).

Consider how effectively groups that are tightly scoped work (e.g., FedID with digital credentials, Payments and the Payment Request API, and I'm sure @anssiko concurs with respect to WebML... small focused groups and communities work effectively!).

I know those groups take a few months to set up. But this work is not going anywhere (it's been incubating for 12 years and 2 months)... there spec is more or less done. Let's not pretend there's suddenly a huge hurry.

What would be cool is if we had some kind of working group that allowed us to do APIs that have a security model that goes beyond the Web's current one: like, Mozilla is not going to expose this API to every website, IIUC. They are only exposing it on a per requested site basis through their web extensions mechanism. Grouping APIs like that somehow (and into a new working group) seems like potentially a good idea (to me).