21631 2013-04-08 21:03:28 +0000 Clarify the mess in "commit the scratch bitmap" regarding which task source is being used for the tasks 2013-07-15 23:09:34 +0000 1 1 1 Unclassified WHATWG HTML unspecified All All CLOSED FIXED P2 normal Unsorted 1 jmdyck ian ian mike contributor oldest_to_newest 85738 0 jmdyck 2013-04-08 21:03:28 +0000 In 4.8.11.2 "The 2D rendering context", in the algorithm for "commit the scratch bitmap", step 8 says: Queue a task from the canvas updating task source of the output bitmap's canvas element's event loop to perform the following substeps: First, I think the <a ...>output bitmap</a> should be <var>output bitmap</var> i.e., a reference to the variable established in step 7. Second, the 'access chain' in this step appears to be: the output bitmap v a canvas element v an event loop v canvas updating task source and some of the links in this chain are questionable... (a) "the output bitmap's canvas element" It isn't clear from the definition of 'output bitmap' that this is meaningful. Section 4.8.11.2.1 does say: The output bitmap of a rendering context, when it has one, is always just an alias to a canvas element's bitmap. but that's non-normative, and appears later than the step in question. It would be helpful, where the spec says: A CanvasRenderingContext2D object ... can be bound to an output bitmap. to append something like: (the bitmap of a canvas element) (b) "[a] canvas element's event loop" It's not clear what this means. It might mean: the event loop of the browsing context of the document that contains the canvas element but I couldn't find any prose to justify going directly from an element to an event loop. (c) "the canvas updating task source of [an] event loop" It's not clear what this means either. I believe it's the only point in the spec that refers to a task source as being "of an event loop". (The only other place I could find of a task source being "of" anything is in 7.1.4.2's "spin the event loop", which refers to the task source of a task, which makes sense.) The step makes somewhat more sense if you replace the "of" with "to", leading to a slightly different parsing: Queue a task from 'the canvas updating task source' to the output bitmap's canvas element's event loop to perform the following substeps: i.e.: Queue a task to run the following substeps, where the task source of the task is the 'canvas updating task source', and the "relevant event loop" (referred to in the definition of "queue a task") is the output bitmap's canvas element's event loop. But that makes me wonder why this is (I think) the only "queue a task" that specifies the relevant event loop. Is there a general rule for determining the relevant event loop that works for all task-queuings other than this one? If so, it should probably be stated close to the definition for "queue a task". 85912 1 ian 2013-04-10 23:00:54 +0000 Fixed the first part. 88489 2 ian 2013-05-30 23:48:29 +0000 Fixed the second part. 88490 3 contributor 2013-05-30 23:48:59 +0000 Checked in as WHATWG revision r7875. Check-in comment: Fix the terminology for how canvases are committed. http://html5.org/tools/web-apps-tracker?from=7874&to=7875 88491 4 jmdyck 2013-05-31 01:02:31 +0000 You inserted a step to define <var>canvas</var>, but then don't reference it. Presumably, Queue a task associated with <code>canvas</code> element's Document ... should be Queue a task associated with <var>canvas</var>' Document ... Other than that, looks good to me. 88868 5 ian 2013-06-06 21:32:07 +0000 Woops, good catch. Thanks. 88869 6 contributor 2013-06-06 21:34:07 +0000 Checked in as WHATWG revision r7928. Check-in comment: Fix some typos or copypasta. http://html5.org/tools/web-apps-tracker?from=7927&to=7928