Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier caban...@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. 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? 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.
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Thu, Mar 6, 2014 at 8:31 AM, Justin Novosad ju...@google.com wrote: On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier caban...@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.
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Thu, Mar 6, 2014 at 11:47 AM, Rik Cabanier caban...@gmail.com wrote: On Thu, Mar 6, 2014 at 8:31 AM, Justin Novosad ju...@google.com wrote: On Wed, Mar 5, 2014 at 11:42 PM, Rik Cabanier caban...@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. You were clear, and I think that makes sense because, as Boris stated, elements can be transferred from one document to another. So blocking context creation does not solve the issue unless, as you stated, we also added check at the API method level. So... we really just need checks on the text APIs. 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. Yes, that is what I meant. My only concern is what if future changes to the spec make make other APIs suddenly become dependent on the browsing context? Disallowing all CanvasRenderingContext2D API calls seems safer in this case, or am I worrying too much? 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. Well, the fully resolved path can be cached.
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Wed, 5 Mar 2014, Rik Cabanier 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] The spec actually defines what happens with fonts when you don't have a defined computed style: # If the computed values are undefined for a particular case (e.g. because # the font style source object is not an element or is not being # rendered), then the relative keywords must be interpreted relative to # the normal-weight 10px sans-serif default. This is needed for text rendering in Workers, if nothing else. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Thu, Mar 6, 2014 at 1:17 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Mar 2014, Rik Cabanier 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] The spec actually defines what happens with fonts when you don't have a defined computed style: # If the computed values are undefined for a particular case (e.g. because # the font style source object is not an element or is not being # rendered), then the relative keywords must be interpreted relative to # the normal-weight 10px sans-serif default. This is needed for text rendering in Workers, if nothing else. Ah! So that clears it up... almost. How do we interpret that for Path objects? Does adding text to a path count as a case where font style is undefined, or do we defer and resolve the font style when the path object is drawn to a canvas? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Thu, 6 Mar 2014, Justin Novosad wrote: On Thu, Mar 6, 2014 at 1:17 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Mar 2014, Rik Cabanier 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] The spec actually defines what happens with fonts when you don't have a defined computed style: # If the computed values are undefined for a particular case (e.g. because # the font style source object is not an element or is not being # rendered), then the relative keywords must be interpreted relative to # the normal-weight 10px sans-serif default. This is needed for text rendering in Workers, if nothing else. Ah! So that clears it up... almost. How do we interpret that for Path objects? Does adding text to a path count as a case where font style is undefined, or do we defer and resolve the font style when the path object is drawn to a canvas? Depends on the Path object. There's a font style source object defined for anything that might draw text (if I didn't screw it up), and that's what decides what you should be rendering relative to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Thu, Mar 6, 2014 at 1:45 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 6 Mar 2014, Justin Novosad wrote: How do we interpret that for Path objects? Does adding text to a path count as a case where font style is undefined, or do we defer and resolve the font style when the path object is drawn to a canvas? Depends on the Path object. There's a font style source object defined for anything that might draw text (if I didn't screw it up), and that's what decides what you should be rendering relative to. Ok, I see it now. A lot of jumping around the spec is required to get the complete answer, but it is clear now. Thanks. So basically, if the 'styles' parameter is a DrawingStyle object, then the object passed to the DrawingStyle constructor is used as the font style source object, and if none is specified we take the Document object of the active document of the browsing context of the Window object on which the interface object of the invoked constructor is found. Alright. I think we're good here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Mon, Mar 3, 2014 at 9:57 AM, Justin Novosad ju...@google.com wrote: Hello whatwg, Say you create a new document using document.implementation.createHTMLDocument(), you get a document without a browsing context. This means that style and layout will never be calculated on the document. Some of those calculations are context dependent, so they can't even be resolved. Now, what about canvas elements? If JS code draws to a canvas that is in a document with no browsing context, what should happen? Should the draw calls produce pixels? Even though the canvas is not displayed, it can still be used as an image source. So technically, as currently specified, such canvases should be rendered. Drawing to a canvas in a context-less document is unfortunately a little bit problematic because some aspects of canvas painting (drawing text in particular) are affected by the browsing context. For example, there is no locale for font family resolution and it is not possible to resolve font sizes in physical length units unless the document is associated with a view. My 2 cents: specifying fallback behaviors for all use cases that are context dependent could be tedious and I have yet to see a real-world use case that requires being able to paint a canvas in a frame-less document. Therefore, I think the spec should clearly state canvas elements that are in a document without a browsing context are unusable. Not sure what the exact behavior should be though. Should an exception be thrown upon trying to use the rendering context? Perhaps canvas draws should fail silently, and using the canvas as an image source should give transparent black pixels? 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] Since this is such a small edge case, it seems reasonable to disallow the creation of a 2d context and throw an exception. Going through all the APIs and flagging them as suitable for a context-less environment is not really worth the effort. I'm curious how you found this. Was this reported by an author? If so, why was he trying to do it this way? 1: http://codepen.io/anon/pen/tsemK
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On 3/5/14 11:42 PM, Rik Cabanier wrote: Since this is such a small edge case, it seems reasonable to disallow the creation of a 2d context and throw an exception. Going through all the APIs and flagging them as suitable for a context-less environment is not really worth the effort. What happens if I create a 2d context while in a document and then adopt the canvas into a document that has no browsing context? -Boris
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Wed, Mar 5, 2014 at 8:48 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/5/14 11:42 PM, Rik Cabanier wrote: Since this is such a small edge case, it seems reasonable to disallow the creation of a 2d context and throw an exception. Going through all the APIs and flagging them as suitable for a context-less environment is not really worth the effort. What happens if I create a 2d context while in a document and then adopt the canvas into a document that has no browsing context? As soon as the context is adopted, you get the same behavior [1] when you draw text. It seems that we need to go call-by-call after all. Maybe just text APIs should be disallowed for context-less canvas? Quickly skimming the spec, I can't find other instances where this would be a problem. As an aside, won't the text APIs [2] on Path2D have the same issue? They are not connected to a browser context so how will they work? 1: http://codepen.io/anon/pen/gcqet 2: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-path-addtext
[whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
Hello whatwg, Say you create a new document using document.implementation.createHTMLDocument(), you get a document without a browsing context. This means that style and layout will never be calculated on the document. Some of those calculations are context dependent, so they can't even be resolved. Now, what about canvas elements? If JS code draws to a canvas that is in a document with no browsing context, what should happen? Should the draw calls produce pixels? Even though the canvas is not displayed, it can still be used as an image source. So technically, as currently specified, such canvases should be rendered. Drawing to a canvas in a context-less document is unfortunately a little bit problematic because some aspects of canvas painting (drawing text in particular) are affected by the browsing context. For example, there is no locale for font family resolution and it is not possible to resolve font sizes in physical length units unless the document is associated with a view. My 2 cents: specifying fallback behaviors for all use cases that are context dependent could be tedious and I have yet to see a real-world use case that requires being able to paint a canvas in a frame-less document. Therefore, I think the spec should clearly state canvas elements that are in a document without a browsing context are unusable. Not sure what the exact behavior should be though. Should an exception be thrown upon trying to use the rendering context? Perhaps canvas draws should fail silently, and using the canvas as an image source should give transparent black pixels? Cheers, Justin
