[whatwg] Canvas and DOM elements
Having dedicated DOM element () for drawings looks a bit strange as a design decision. Logically any block DOM element can provide graphics. Ideally getContext method should have one more parameter - layer - background/content/foreground - so graphics could be mixed with the content of the element, drawn on top and/or below the content. Only as an example, Sciter allows to draw on any block element: http://terrainformatica.com/sciter/sciter.zip at http://terrainformatica.com/sciter/ Samples are in /samples/graphics/*.htm Andrew Fedoniouk. http://terrainformatica.com
Re: [whatwg] proposed canvas 2d API additions
On 4/28/06, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote: interface ImageData { readonly attribute string format; /* only "rgba" is valid for now */ readonly attribute long int width; readonly attribute long int height; readonly attribute Array data; } Actually, let's step back a second; this may be massive overengineering. What if we simply had: readonly attribute float deviceScaling; on the 2D context, which would give the scaling factor between canvas-space pixels (that is, the space that the width/height attributes are in) and device-space pixels (the pixels of the actual backing store). So if was represented with a 300x300 backing store, deviceScaling would be 1.5; if 400x400, it would be 2.0. (If necessary, we can have deviceScalingX, deviceScalingY.) Then getPixels is defined to take parameters in canvas pixel space, and returns the ARGB array in device space; if you ask for a 50x50 region, you'll get back 100x100x4 samples, with a deviceScaling of 2.0. putPixels would take coordinates in canvas pixel space again, but would take the appropriate device-pixel-sized ARGB array. This becomes tricky with non-integer deviceScaling; that is, if a 2x2 region becomes a 3x3 region with a deviceScaling of 1.5, what do you return when you're asked for x=1 y=1 w=1 h=1? I'd say that you end up resampling and shifting over your 3x3 device space backing store by .5 pixels so that the region would start on a device pixel boundary. This would obviously not be a clean round-trip, but the spec can inform authors how to ensure a clean round trip (only request regions where your x/y * deviceScaling are integers). This removes the need for a separate ImageData object and all the extra gunk necessary there, but still maintains full resolution independence. Any thoughts on this? - Vlad
Re: [whatwg] The embed element
On May 4, 2006, at 06:28, Peter Hall wrote: In the case of Flash, at least, it's possible to get good browser coverage, while avoiding using the tag altogether (http:// www.alistapart.com/articles/flashsatay/), but I'm unsure of the value of doing that, compared with the "weirdness" of it. According to the Macromedia post I referenced http://weblogs.macromedia.com/accessibility/archives/2005/08/ in_search_of_a.cfm Flash Satay does not work with JAWS. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] [wf2] Filtering datalist with pattern
The WF2 spec does not say anything about filtering autocomplete lists on pattern and Opera 9 does not do it. However, autocomplete entries that would fail form validation are not particularly useful. I suggest saying that potential autocomplete items (whether supplied by the UA itself or read from a datalist) should be tested against the datatype and the pattern of the form field being filled and should only be shown if they match both the datatype and the pattern. (Real-world case: The autocompelete menu for the document field at http://hsivonen.iki.fi/validator/ shows ftp and file URLs in Opera 9 even though the pattern only matches http and https URLs.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/