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

posterCanvas use is ambiguous for audio only #1605

Closed
azaroth42 opened this issue May 9, 2018 · 7 comments
Closed

posterCanvas use is ambiguous for audio only #1605

azaroth42 opened this issue May 9, 2018 · 7 comments
Assignees
Labels
A/V Approved-by-TRC Issue has been approved by the TRC normative presentation

Comments

@azaroth42
Copy link
Member

Should the audio of the poster be played while the main content is buffering, or should it be played as ambient content while the user interacts with the main canvases?

Seems like we need a behavior on the canvas? Or ( 😖 ) two separate properties?

@zimeon
Copy link
Member

zimeon commented Jun 26, 2018

Hmm... and should a video poster repeat, etc.? I note that this would seem to be an exception to any idea of inheritance of behaviors in #1612 if resolution of #1602 ended up with timeMode rolled into behavior

@azaroth42
Copy link
Member Author

After the call on 2018-06-26, my feeling is now that we should have two properties (with all the 😖 that results in).

Rationale:

  • We have agreed that both pre-play or during-play use cases are in scope (image while buffering, background music while playing) so can't solve it by saying it's one or the other alone
  • If we solve it with a behavior on the canvas, then
    • posterCanvas needs to be an array for the situation when there's both ...
    • If the behaviors aren't present, then either there would need to be a default or an exception handling routine. This seems complicated
    • If the same behavior is present in multiple canvases, a client would need to distinguish which to use somehow based on other metadata ... in a presentation driven environment. This seems very difficult, if not impossible.
  • If we solve it with multiple properties, we document two relationships each of which can be present and has exactly one Canvas. That seems cleaner for everyone.

@tomcrane
Copy link
Contributor

placeholderCanvas and accompanyingCanvas...

with sensible observations or rules about where each of these make sense.

@tomcrane
Copy link
Contributor

And clearly showing through recipes the difference between accompanyingCanvas and the together behavior.

@azaroth42 azaroth42 removed the discuss label Aug 29, 2018
@zimeon
Copy link
Member

zimeon commented Aug 29, 2018

Discussed on 2018-08-29 Technical Community Call - noted that proposal #1605 (comment) was outcome of A/V group discussion. Consensus in favor of using placeholderCanvas and accompanyingCanvas, with good explanation and recipes

@azaroth42
Copy link
Member Author

Closed by #1658

@azaroth42 azaroth42 added the Ready-for-TRC Normative changes ready for TRC review label Feb 6, 2019
@zimeon zimeon added Approved-by-TRC Issue has been approved by the TRC and removed Ready-for-TRC Normative changes ready for TRC review labels Mar 12, 2019
@zimeon
Copy link
Member

zimeon commented Mar 12, 2019

Approved by TRC, already merged into image-prezi-rc2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A/V Approved-by-TRC Issue has been approved by the TRC normative presentation
Projects
None yet
Development

No branches or pull requests

3 participants