On Nov 10, 2012, at 10:02 AM, Ian Hickson <firstname.lastname@example.org
On Sat, 10 Nov 2012, Chris Marrin wrote:
Yes, putting this on Canvas would be more sane. My proposal was simply
trying to avoid changes outside WebGL.
(I would encourage us all to communicate so that our organisation into
different working groups do not get exposed in the platform's design. This
is a classic example of Conway's Law. Avoiding changes outside of one spec
is not a good reason to design something. :-) )
My one issue with this approach is that having getContext() fail after
setContext() is confusing. Really getContext() becomes a misnomer used
this way. It is really createContext() or something similar. But since
we can't change that, maybe we can create a new pair of calls:
context = canvas.getRenderingContext();
Then we could leave getContext() alone and use it for legacy purposes.
But I agree that, in this scenario, getContext should fail if you've
ever called setRenderingContext().
What's the use case for getRenderingContext()?
I have a canvas, I want to know what context is currently associated with it. I don't think it would be better to avoid a write-only API for the context.