Re: [whatwg] High-density canvases

On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell <> 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

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w

Received on Monday, 23 June 2014 23:26:17 UTC