Comments (13)
@schien Thanks for the concrete proposal.
All - @tidoust has a nice explanation in the Conformance classes definition issue why this separation makes very much sense. Please read the issue, and let the group know if you have any concerns with separating the interfaces to reflect the two conformance classes of products as follows (naming subject to change): opening user agent (or controlling user agent to align with #95) and presenting user agent. This issue proposes the first concrete change to implement this separation.
@mfoltzgoogle How would you like to proceed with baking this into the spec? I suggest you coordinate with @schien who volunteered to help.
from presentation-api.
I think I would like to define the conformance classes for the controlling/opening browsing context and the presenting browsing context as in #93 and re-outline the document as best as I can along those lines.
Then it will be easier to introduce the new interfaces proposed by @schien since they will have a logical place in the new document.
from presentation-api.
A naming idea:
navigator.present - for the controller (sender) page
navigator.presentation - for the presentation (receiver) page
So we leave what we have for the presentation where it is and move the sender API to the shorter interface.
from presentation-api.
It seems no concerns raised with the general direction proposed by @schien. It also appears we've not yet settled on the interface naming. We should first update the Conformance section using the @tidoust's proposal as a starting point and bake in the changes to the normative parts when consensus emerges on naming.
All - please let us know your preference and/or suggestions with respect to naming.
@mfoltzgoogle Feel free to update the Conformance section with a note stating that the rest of the spec have not yet been reworked to match the conformance classes split.
from presentation-api.
@schien what do you think of:
interface Presentation {
attribute PresentationSession? defaultRequest;
readonly attribute PresentationReceiver? receiver;
};
interface PresentationReceiver : EventTarget {
Promise<PresentationSession> getSession();
Promise<sequence<PresentationSession>> getSessions();
attribute EventHandler onsessionavailable;
};
I think it has the benefit of splitting the receiver and sender APIs and also provide a good way to find out whether the current browsing context is a receiver (ie. navigator.presentation.receiver is not null).
from presentation-api.
Overall looks good to me, but I still prefer PresentingContext
over PresentationReceiver
. It's more consistent to the common idiom we defined in spec.
from presentation-api.
I think PresentingContext
has multiple downsides:
navigator.presentingContext
isn't in thenavigator.presentation
namespacePresentingContext
isn't prefixed withPresentation
- I think
navigator.presentation.receiver
is clearer about what it does compared tonavigator.presentingContext
.
from presentation-api.
@sicking, an opinion?
from presentation-api.
I'm fine with any of the proposals here, but I'd probably go with @mounirlamouri's proposal if I had to choose.
from presentation-api.
I like the idea of sticking to the navigator.presentation
namespace.
That's more an editorial point perhaps but since we'll end up with two conformance classes in the spec, it seems good to have separate IDL for each class of products to be able to say "the controlling user agent MUST implement the interface defined in section X.Y." instead of "the controlling user agent MUST implement the defaultRequest
attribute of the Presentation
interface".
How would you define the resulting Presentation
interface in the spec, @mounirlamouri ? An empty interface completed with two partial
interfaces, one with defaultRequest
and the other with receiver
?
from presentation-api.
We can't really have two partial interfaces because we need a Presentation
interface which would be null. I will go with one Presentation
interface with both objects unless there is an objection.
from presentation-api.
@mounirlamouri Please submit a PR with your proposal. It is probably easier for the participants to review the changes in context. I suggest you update the conformance section to match in the same PR (you can borrow the language from #93) and cross-reference the conformance classes appropriately.
As long as the spec is clear to implementers (what must be implemented/tested) and authors (albeit there are surely better API docs for web developers than specs) on the division, we should be fine with @mounirlamouri's proposal even if the spec would end up being a bit more verbose that way. The extra editorial cost will pay off.
from presentation-api.
FWIW, the PR is up and was sent between my previous comment and yours. It should show up in GH UI. For those who interact on issues via email, it is issue #186.
from presentation-api.
Related Issues (20)
- Uncaught ReferenceError: PresentationRequest is not defined HOT 5
- send request stuck on presentationRequest.getAvailability() Method HOT 1
- PresentationRequest is not defined? HOT 2
- Same-screen presentation HOT 9
- Requesting enhancements to the presentation API HOT 7
- HTTP header customization when fetching the presentation page
- reconnect after termination HOT 2
- Possibility for UA to close the connection when it is no longer operational HOT 3
- Publish a Candidate Recommendation Draft HOT 6
- Presentation-api cast file working good on Chrome version 87, but it is not work on Chrome version 88 HOT 13
- Presentation API cast app ID's broken on chromium 95 HOT 2
- update status for issue #347 (Local Presentation API to enable child-window presentation documents) HOT 1
- Presentation of objects prototyping HOT 2
- Update spec language around 1-UA mode to reflect Multi-Screen Window Placement HOT 1
- PresentationRequest.getAvailability() could always return a new Promise
- Update spec language to refer to child navigables instead of nested browing contexts?
- Cannot find name 'PresentationRequest' HOT 2
- "Deploy Pages" GitHub action is timing out HOT 2
- Cannot present on multiple devices from the same tab HOT 4
- Update the link to the HTTP spec HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from presentation-api.