Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TAG feedback #15

Open
xfq opened this issue Sep 17, 2021 · 10 comments
Open

TAG feedback #15

xfq opened this issue Sep 17, 2021 · 10 comments

Comments

@xfq
Copy link
Member

xfq commented Sep 17, 2021

From w3ctag/design-reviews#523 (comment) :

A few things we noted:

  1. The mapping of Miniapp states to other w3c specs may be innacurate - in particular the mapping to service worker states.
  2. The lifecycle document doesn't reference Manifest at all. It was our understanding that Miniapps would use the manifest file with the Miniapp extensions and that doesn't seem to be referenced in the document.
  3. It doesn't look like you're referencing ServiceWorker either - is there a Miniapp state which makes use of ServiceWorker?
  4. When a Miniapp is launched what origin can it be said to have, with regard to the web's security model? That would seem to be important from a lifecycle point of view.

We also note that the Page Lifecycle document that you point to as comparison is out of date and itself needs to be updated (in particular to reflect installation via Manifest, which is missing).

We think it's worth considering whether these lifecycle efforts (MiniApps, web pages, PWA) could be consolidated or brought together in some way.

We need to look at how to deal with these questions.

@QingAn
Copy link
Contributor

QingAn commented Sep 22, 2021

Yes, we can have the first discussion in incoming WG meeting.

At my initial thinking, I remember in one of last year's meeting, we concluded that MiniApp runtime is different from Web App and therefore to develop lifecycle spec for MiniApp. It would be good to consolidate the lifecycle of MiniApps, web app, PWA, but I am not sure whether we make it a requirement for advancing to next CR stage.

Also, since all of them are under development, and some are developed within WHATWG, I am not sure how to consolidate in an efficient way. Any thoughts?

@xfq
Copy link
Member Author

xfq commented Sep 23, 2021

The WG charter says "Whenever possible, the specification should provide a mapping to existing Web specifications such as Service Workers and Page Visibility."

@xfq
Copy link
Member Author

xfq commented Sep 23, 2021

Regarding WHATWG standards, we can first do some investigations to see which features of which standards are involved and then discuss feasible cooperation plans.

@QingAn
Copy link
Contributor

QingAn commented Sep 23, 2021

The WG charter says "Whenever possible, the specification should provide a mapping to existing Web specifications such as Service Workers and Page Visibility."

I will try to provide some mapping in the draft. Any existing spec that I can use as a reference?

@xfq
Copy link
Member Author

xfq commented Sep 23, 2021

Sorry, I don't have a spec for reference here. According to my understanding (of the discussion at the chartering time), the "mapping" here means that we can show how to polyfill the behavior of MiniApp Lifecycle using existing Web APIs like Service Workers in the MiniApp Lifecycle spec.

(Related to this, I remember Thomas made an early prototype of using existing Web APIs to simulate some concepts in a MiniApp.)

@xfq
Copy link
Member Author

xfq commented Sep 25, 2021

We also note that the Page Lifecycle document that you point to as comparison is out of date and itself needs to be updated (in particular to reflect installation via Manifest, which is missing).

I just took a look and found that the Page Lifecycle spec is indeed not active. The last update to the spec was in September 2019.

@QingAn
Copy link
Contributor

QingAn commented Sep 26, 2021

We also note that the Page Lifecycle document that you point to as comparison is out of date and itself needs to be updated (in particular to reflect installation via Manifest, which is missing).

I just took a look and found that the Page Lifecycle spec is indeed not active. The last update to the spec was in September 2019.

So should we keep it in the explainer?

@xfq
Copy link
Member Author

xfq commented Sep 27, 2021

We also note that the Page Lifecycle document that you point to as comparison is out of date and itself needs to be updated (in particular to reflect installation via Manifest, which is missing).

I just took a look and found that the Page Lifecycle spec is indeed not active. The last update to the spec was in September 2019.

So should we keep it in the explainer?

Because the proposal is not deprecated in WICG, IMHO we should keep it for now. We can ask the TAG if that's fine.

@cynthia
Copy link
Member

cynthia commented Sep 28, 2021

Because the proposal is not deprecated in WICG, IMHO we should keep it for now. We can ask the TAG if that's fine.

I think you can either 1) take on Page Lifecycle or 2) absorb Page Lifecycle into a singular lifecycle spec, and officially deprecate it. Ideally, we think work should happen on both specs - we'll follow up on this.

@QingAn
Copy link
Contributor

QingAn commented Sep 28, 2021

Because the proposal is not deprecated in WICG, IMHO we should keep it for now. We can ask the TAG if that's fine.

I think you can either 1) take on Page Lifecycle or 2) absorb Page Lifecycle into a singular lifecycle spec, and officially deprecate it. Ideally, we think work should happen on both specs - we'll follow up on this.

Thanks for TAG's further followup on this. We look forward to TAG's further suggestion on this.

As for Page Lifecycle, since it's WICG's work item, I am not sure whether there is interest from other groups to develop it. Maybe someone needs to ask WICG's opinion and plan on this spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants