[whatwg] Processing the zoom level - MS extensions to window.screen

[Charles Pritchard]

On 11/23/2010 6:46 PM, Robert O'Callahan wrote:
> On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard <chuck at jumis.com 
> <mailto:chuck at jumis.com>> wrote:
>
>       SVG is a document format. It is not reliably implemented. It's
>     far more expensive to implement SVG on a new environment than Canvas.
>
>
> So? You don't have to implement it.
Google, Microsoft, Apple, do, have to implement it.

As an app designer, my app should work on ~ four different browsers. I 
need my app to work, with what's out there in practice.

And for other environments, I would have to. I've implemented for JVM, 
Active X (thanks Vlad/Mozilla), Flash and .Net.

>     I can't do much for you here other than explain to you what I'm
>     hearing.
>     a) Why are you using our Canvas implementation instead of our SVG
>     implementation.
>     b) Why are you using ctx.fillText('Test') instead of
>     element.appendChild(document.createElement('text')).textContent =
>     'Test'.
>
>     For answers
>     a: I'm using it because I work across a variety of browser
>     platforms. Canvas is far better supported.
>
>
> It doesn't make sense to request entirely new features (that by 
> definition aren't currently supported) because existing features 
> aren't widely supported.
>
It's currently supported by Microsoft, and to a lesser extent, WebKit. 
It's not features, it's one feature.
And as you pointed out, it may be supported in FF4; though it's behavior 
is not standardized.

> Anyway, I'm not sure why you think <canvas> is far better supported 
> than SVG. What browser supports <canvas> but not SVG?
AFAIK, FF is the only to support SVG FE.

SVG is a large spec, even SVG Tiny is unevenly implemented.

WebKit had terribly slow SVG support; IEs was non-existent, though it 
was a reasonable task to bring canvas in. I can barely do a nice thing 
in SVG on the iPhone. It takes 20 seconds to load a rendering that takes 
less than one in canvas. These are the reasons why I think canvas is 
better supported. Further, when there are holes, it's easier to work 
around them in Canvas than SVG.

One gaping hole in SVG is repeated elements. I can not reasonably 
implement InkML rendering in SVG. I need David Dailey's replicate tag to 
do it with any real performance:
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm

In many ways, SVG has some of the same shortcomings as VML.

When it comes to the canvas standard, there are a few holes, no doubt, 
but they are minor. There are some globalCompositionModes that aren't 
touchable, text support needs a backup library for legacy clients, 
shadow isn't a reliable module. That's what I work with.

Again, I don't see SVG/Canvas as at all exclusive. One is high level, 
one is low level, and the high level work takes quite a bit of work.

>
>         Sure, but there are plenty of canvas uses that aren't
>         animating all the
>         time (I've seen image editing apps, sites that use canvas as their
>         _input_, not their output, etc).
>
>     1. Name one.
>
>
> http://arewefastyet.com
Uses a second canvas layer for animation.
> http://www.simile-widgets.org/timeplot/
I don't know what was meant by "sites use canvas as their _input_, not 
their output", but anyway, it does fit the challenge.
Here's a case where no Canvas animation happens. The state is retained, 
but all the repainting is done by either clicking a link to go to a new 
page, or by abusing HTML DIVs.

It has inefficient use of DOM+HTML. The doc is a lot heavier than it 
needs to be. For their code setup, SVG is a better use case. They do 
support VML. They're only using Canvas to draw lines, likely for 
compatibility reasons. Thus the VML hooks.

They do keep a state, and setup to plot live data. They don't use it, 
they have separate links instead. Turning their "Live Examples" links 
into a select element would have made good sense.

Here's a better implementation of a time plot. Hold shift to click+drag.
http://timepedia.org/chronoscope/

Anyway, I agree, you've named an example.

> http://jwf.us/blog_apps/mandelbrot_canvas/
Re-draw button, right there. State vars in private zoom variable. It 
outputs to Canvas.

>     Robert's suggestion would radically alter the existing
>     functionality of canvas
>
>
> Only in a way that maintains compatibility with existing content. 
> Otherwise I wouldn't have suggested it.
Existing apps targeting mobile devices (android/iphone) and scaling for 
those devices with the pixel ratio / dpi density variables would be 
broken. It violates a clearly defined separation of roles with CSS and 
Canvas.

>     and require a whole lot of work from other vendors.
>
>
> Not really.
Implement it as an extension, let us know how much time was involved. It 
may help other vendors budget their resources.

I'm very uncomfortable with it being used as the standard behavior for 
the existing HTML Canvas element.


-Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101123/6bad7cc5/attachment-0002.htm>