Charter Review

Christian: We have consensus on our comment. Need input from the wider group on the comment - it may be contraversial.

Marcos: It also has to go out today (the 12th, US East Coast time)

Lola: Still need additional review?

Christian: We had a good discussion and we feel the comment is balanced. Will post it right after this meeting.

JY: I'm worried about the length of the comment, and the assumption that Chromium-only APIs shouldn't be in a WG.

MC: Let's split that into parts. There's vibration and battery status which are chrome only now but were in all browsers, or that was the intention. But some browsers decided to remove tjem. The chrome-only ones fall into the discussion around generic sensors. There's a question of whether use case fort those is valid. The proximity API doesn't list any use cases. So I don't think it's about that it's Chrome only, it just happens that they are. It's more around the architectural models are using the generic sensor. Do these APIs have activity. Going back to the start, the motivation was that devices have these sensors, there's APIs to access them, so let's access them; rather than, is this a good idea or not.

JY: Sounds like a.request to write expaliners for each API, if can't write a good one then drop the API.

MC: Could be an explainer or anything that explains the use case, but needs to make a strong case as to why you might have it. So hopefully that covers at least the chrome-only part, which isn't that relevant. If they're a great idea then they shoujld be starndardized. But larger question is, given the arch. was rejected, their utility is in question -- that's the interesting architectural quesiton.

JY: Makes sense to ask them to describe use cases for all APIIs.

MC: Yeah, or at least revisit them.

JY: Just that would be short comment.

XH: I'm wondering how they would anwser use case question.

JY: I thikn it''d be the user-serving purpose of the API.

MC: The web plat is its own thing -- considering is it available to native apps is not an interesting argument.

XH: But they want to replkicate native app.

JY: My argument is I don't want their to be a reason to write a native app

MC: That's the correct framing. Comes back to, what is not achievable by the web plat today. What problem is this solving for users.

JY: THinking about whether this is good charter feedback, or good spec feedback.

MC: I think it's a charter question. This group is tasked to do stuff, they've done stuff over the yeras, based on particular premise abut how we're doing APIs 10-15 yrs ago. It's been rechartered, but completely fair to say in this modern world, is this stuff still relevant? Wake lock API is an example. There's nothing new being proposed from this group, but if they do, should be looking at it in this way. There's also this old stuff: asking, is it worth pursuiong those, put them on recommendation track, which is the larger question. To me that's a charter concern.

JY: Question of do you have use cases for all the specs, and how do you balance specs that allow some abuse but have use case -- good to include in a charter. One other point about which statuses they should develop specs under. Process forbids moving some of these to note track; can't be done after it's patent draft.

MC: In those cases would be nice if there was signaling even in title to say it's a maintenance thing.

JY: I would want to see examples in other specs we could ask a WG to copy.

MC: Yeah, maybe in payments WG we violated, took the ??? event and moved it out. This is why it's dangerous -- group very quickly moving things into CR, because it creates bad situation where something is in the rec track and we can't move it out.

JY: That's one of the questions I'd like to get a formal rejection council to talk about. What are the formal requirements to get something into CR. Not really a chartering question yet; could get a formal objection and ask council to review it, but not something I want in a charter review before that point.

MC: Can they drop to working draft?

JY: Yes. But if has ever been patent draft, can't switch tracks, go to note.

BK: Could go to deprecated.

JY: Eventually the ones that are duplicated by consensus spec shouldl eventually go to discontinued/superceded.

MC: That's the real solution here depending on what they want to do. They have these specs with features that may or may not be interesting...if there are cool features, should bring those over to other specs. Hopefully that's conveyed in the comment.

JY: At least for the things that overlap, should be building on consensus spec.

MC: That's the bit I'm unsure of, don't know if there's anything interesting in the other specs.

JY: Marcos can you write concise omment or should I?

MC: If you write I'll focus on making more consise..

BK: We do have group of other things we've been talking about being new charter that would cover webviews, maybe miniapps, IWAs. I can see them being different in some of these areas. Curious about if we ask this question about: based on never getting Apple and Moz to sign on to it, but maybe that's just in the browser itself. Maybe a world where they could be standardized but not in the way we have now. Does that modify this feedback in any way.

JY: I think this might be something where Marcos and I disagree. I think we should be able to get things to rec even if only in chromium. Device APIs don't touch engine much, if they have multiple implementations at OS side and UI side, should be ablet o get to rec.

MC: Don't necessarily disagree -- only on the assumptions on which the APIs are built. We evaluated other things on the same basis. Embedded in Brian's question is about other platforms having these capabilities, we want the same capabilities where possible across all UAs. Don't want different permission/feature model, want cohesive architecture. But there are APIs only exposed in certain contexts, like Badging API, only makes sense in WebApp. MiniApps may fall into this category. Or Push notifications only available in installed WebApps.