On Mon, Jun 23, 2014 at 4:25 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell <k...@google.com> wrote:
>> It's hard to predict. A more general API would be better than a
>> canvas-specific one, assuming it solves the problem. getBoxQuads can
>> return different types of CSS boxes (content, padding, border, margin)
>> -- will it be obvious to web developers which to use, and is it more
>> likely all implementations will handle them all correctly rather than
>> a couple of new properties on the canvas?
>> Could you suggest a name for the new API? getBoxQuadsInDevicePixels?
>> getDevicePixelBoxQuads?
> AFAIK all we need from this API is device pixel sizes. Extending getBoxQuads
> with an option to return geometry in device pixels doesn't really make sense
> to me since it doesn't make sense to ask "what is element A's quad relative
> to element B in device pixels". So a general, dedicated API would probably
> look something like:
>   interface DOMSize {
>     readonly attribute unrestricted double width;
>     readonly attribute unrestricted double height;
>   };
>   dictionary BoxSizeOptions {
>     CSSBoxType box = "border";
>   };
>   sequence<DOMSize> getBoxDevicePixelSizes(optional BoxSizeOptions options);
> So "renderedPixelWidth/Height" on HTMLCanvasElement is definitely simpler. I
> have no strong opinion about which way to go, but I lean towards the
> attributes unless someone has a good use-case for the general API. We could
> add the general API later if we need to, the duplication would not be a big
> deal.

If there's no concern about potential duplicated functionality then
let's add the attributes to the canvas element. They'll be easier for
developers to understand and easier to verify as obviously correct.

How should we proceed? Would you add an entry to
http://wiki.whatwg.org/wiki/Category:Proposals ?

Reply via email to