What do you mean with won't cause major problems? If the canvas is specified in CSS units but the browser chooses the backing store in device units then every sample on http://glsl.heroku.com breaks on an HD-DPI system because gl.FragCoord will be in device units and "resolution" will be in CSS units (since it's set by canvas.width and canvas.height) currently.

No breakage is good, but it's not in the same league as *every* (nearly) application being broken, which is what will happen if viewport takes backing store pixels and it starts to make a difference. If it takes CSS pixels, then most applications will continue to work as-is, in both the texture size limitation and HD backbuffer cases.

Now, another option is to make gl.viewport and friends take backing store pixels (skipping the CSS pixel compatibility stuff), and to make HD backbuffers opt-in, leaving canvas.width/height alone. This essentially means that the opt-in declares that your program has been adjusted to send backing store pixels (you've made the necessary s/canvas.height/gl.drawingBufferHeight/ adjustments). This means fewer programs will support HD rendering (which, by Canvas's design, is supposed to be implicit), but it's much saner than trying to changing what canvas.height and canvas.width--parts of an API that WebGL doesn't own--mean.

(In that case, most applications would still end up broken in the reduced-backing-store scenario. It's certainly a lower surface-area approach, since it doesn't introduce any new methods or resampling algorithms.)

By the way, that aside I agree there are certain cases where it's
useful to say "don't use a different size backing store unless you
absolutely have to", eg. when using WebGL for image processing or
computation, which will never be displayed in a document. This could be done with either an opt-in or an opt-out.

If you want it 1x1 with an HD-DPI display you set it

canvas.width = desiredWidth * window.devicePixelRatio

canvas.height = desiredHeight * window.devicePixelRatio

and everything just magically works.

That seems the far saner way to go.

It's not how Canvas works. If you want Canvas to change, then feel free to propose it on webapps or whatwg. I doubt this will get traction; it would break the use case of laying out <canvas> elements as part of markup. I assume you're not suggesting that canvas.width/height change meaning when canvas.getContext("webgl") is called--that would cause the visible size of the canvas in the document to change (and it'd be very bizarre and inconsistent behavior).

It'll work just fine if the author sets canvas.style.width / canvas.style.height to desiredWidth / desiredHeight at the same time.. If they are changing .width/.height that seems easy enough to ask