addition of developer "best practices" statement to document about webmediaguidelines

[mavgit]

I think that, likewise, we should have a reference to these developer guidelines in the "Web Media APIs 2017" spec. I see the Web Media APIs 2017 spec as targeted at device platform developers, not app developers. But it would make sense to point from Web Media APIs 2017 to this document for readers of Web Media APIs 2017 who are app developers. Make sense?

[boyofgreen]

I agree, we want to be clear in both documents who the audience is for that document. We should link the docs so the right audiences get to the right doc. When I turn this into a PR, I'll add text and links in for that.

[squapp]

This allows a developer to implement EME when supported, and not execute code that will generate errors in browsers that do not

For this particular example, we could also reference existing/working code from open source players, e.g. dash.js
It also handles different versions of EME that can be found on various platforms

[joelkorpi]

I agree, we should have a best practices section as well as an introduction describing the target audience (with links to Web Media APIs 2017). I can also obviously provide examples for use with JW Player and any other open source video player.

[boyofgreen]

that makes sense. I am going to put this into a PR, but I would be happy to have one of you update the sample.

[joelkorpi]

This was discussed today at the F2F and the concern was brought up that we want to produce code examples that have the longest shelf life possible and do not want to increase the scope of these guidelines to move beyond a few examples. Describing best practices for every technology/standard/format/codec would expand the scope of the guidelines beyond our initial target.

I propose that we include examples and a best practices section, as suggested, but limit it to psuedo-code or limited examples to cover the main important best practices.

[joelkorpi]

Issue has been closed