- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 6 Mar 2014 08:47:36 -0800
- To: Justin Novosad <junov@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>
On Thu, Mar 6, 2014 at 8:31 AM, Justin Novosad <junov@google.com> wrote: > > > > On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> >> Testing all browsers (except IE >> since document.implementation.createHTMLDocument() doesn't work) they seem >> to handle canvas contexts with no browsing context except when you use text. >> Chrome crashes, firefox throws an exception and Safari draws the text >> with a very small scale [1] >> > > Thanks for checking. The reason I started this thread is that I just > recently solved the crash in Chrome, and I wasn't satisfied with my > resolution. I just added an early exit, so Chrome 35 will fail silently on > calls that depend on style resolution when the canvas has no browsing > context. So now we have three different behaviors. Yay! > > I don't think the Safari behavior is the right thing to do because it will > never match the developer's intent. > Basically it boils down to two yes/no questions: > 1) exception or no exception? > 2) block all canvas APIs just the text APIs? > > I think that throwing an exception makes sense in this case because it > would provide meaningful feedback to the developer. I was reluctant to do > that when I fixed the crash in Chrome because there is always a chance of > breaking working apps/sites when you add exceptions where there weren't > before or where there aren't in other browsers (not to mention the spec). > But since Firefox is already throwing an exception in this case, I would > feel comfortable doing that in Chrome as well. > Maybe I wasn't very clear. The exception on Firefox happens when you try to use the text API, not when you try to create the context. For question 2) I really don't have a strong opinion. On some level, being > more restrictive feels safer and more future proof, but would it be > overkill in this case? > Since the canvas element can be transferred to a browser context-less document, throwing an exception at creation time won't work. It seems best to disallow the API that rely on the browser context which as far as we know are the text APIs. > As far as Path2D text methods are concerned, I don't see any problems. the > resolution of CanvasDrawingStyles can be deferred to rasterization time, at > which point we can use the browsing context of the canvas to which the path > is being drawn. > Maybe... the point of the path API is to help with performance. If they are designed in such a way that the actual processing happens when they are used, performance will be impacted.
Received on Thursday, 6 March 2014 16:48:03 UTC