Re: ACTION-924: canvas and SVG draft text / comments

Thanks for the discussion on this. Unfortunately I haven't had chance to
update the document this week as I planned and will be unable to make the
meeting today due to a clash, but it sounds like there is lots to still
discuss here.

Would be good if you can all discuss these points in today's call and pass
an appropriate resolution so I can fold the response into the document
before the end of the week. My tuppeneth worth:

- It would seem remiss not to mention these technologies since they are
significant considerations when building a Web app, but I'm not clear from
this discussion what useful information we're trying to convey.

- To Rotan's point (BPs are contextual) the approach throughout the doc is
to say things like "if you care about..." do X... "if you care more
about..." do Y which would be a reasonable approach here.

- I personally don't buy the edgecase that canvas is useful in order to
reduce roundtrips, that seems like a hammer to crack a nut. But I do have an
issue with not being sure *when* it's useful to use Canvas... We
experimented with using Canvas to save on icon .pngs but decided in the end
the javaScript bloat and processing time wasn't worth it and have ditched
this approach. I'll ask around the office and see when / if we make use of
Canvas/SVG etc.

- When discussing today please consider this BP in the context of the
broader document... e.g. we've used fairly broad strokes throughout so we
need to avoid an inappropriate level of detail here. The goal is to say
something useful so that developers can make a simple / informed decision
about whether this technology is relevant to them and make appropriate
references without getting bogged down with too many contextual details.

Looking forward to your resolutions...

Adam.

On Mon, Sep 7, 2009 at 10:47 AM, Rotan Hanrahan <
rotan.hanrahan@mobileaware.com> wrote:

> > Canvas is therefore best suited for [for what actually? at least one
> good example is needed].
>
> Canvas is therefore best suited for situations where all of the
> following apply:
> - The content in the response requires an image
> - The image must be tailored to the current dynamic context
> - The response needs to be delivered with maximum efficiency
> - The client device does not support multi-part or embedded SVG
> - The client device supports Canvas
>
> An example use case: A commuter bus service that sends you a map showing
> where you are, where the bus stops are and which stop you should run to
> if you want to get to your destination on time.
>
> In this use case, the image is an integral part of the service. The text
> (whether as an accompaniment or an alternative) might take you so long
> to comprehend that you'll miss the bus. The response is highly
> contextual and immediate, and therefore the need for it to be
> discoverable is diminished, especially as such content loses its value
> rapidly with time. The response needs to be fast, under the
> circumstances. Any latency in delivering the image (e.g. because it was
> referenced by the main markup and therefore requires another round-trip)
> would negatively impact the service. Thus sending the image as (part of)
> the response is preferred. If the client supports multi-part then a
> raster image could be included with the response (pre-rendered on the
> server), or if it supports embedded SVG markup then that could be used
> too. The latter is preferred as even a compressed raster could be larger
> than an equivalent SVG. However, if neither options are available, but
> Canvas is supported, then Canvas is the solution.
>
> Now, what you need to ask yourself is whether or not this sounds like an
> "edge case", and whether or not it is worth the effort to support it. Of
> course, it could be that you don't have the resources to support
> anything other than technologies X, Y and Z, but that's a separate
> argument*.
>
> >From my perspective, the statements of best practices regarding visual
> resources are doomed because the actual practices will take into
> consideration far more issues than the technical matters raised in the
> document and this thread. Availability of skills, costs of development,
> maintenance costs, current practices of the graphics design shop used by
> the customer, and many more factors will determine what is actually used
> in practice. While I commend the BPWG for trying to devise some best
> practices regarding graphics, I think it would be far more useful if you
> merely put together some well-researched pros and cons of all the main
> options within your scope (i.e. current open technologies), which we can
> then pile into the melting pot along with the claims from vendors of
> proprietary alternatives so that we can come up with a reasonable answer
> on a *case by case* basis.
>
> You see, the problem is that "best" means different things to different
> people. Instead, perhaps the section on graphics should start like this:
>
> "When devising the practices that best suit your particular
> circumstances, the following technical features of several popular open
> alternatives should be considered:"
>
> Followed by the detailed pros/cons list.
>
> ---Rotan
>
>
> * If you are pressed for resources, you could look into things like
> canvas-to-svg and svg-to-canvas solutions, areas that people have
> already starting tinkering with.
>
>
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On
> Behalf Of Eduardo Casais
> Sent: 04 September 2009 11:04
> To: public-bpwg@w3.org
> Subject: Re: ACTION-924: canvas and SVG draft text / comments
>
> Let me attempt to improve the text directly. Feel free to tear this
> contribution
> apart and condense it.
>
>
> 3.5.12 [the real message we want to convey]
>
> Graphics can be incorporated in a mobile application in several ways.
> The canvas tag
> is a recent markup addition, to be standardized in HTML 5, which
> provides a "blank
> slate" 2D content-drawing capability to be filled in via Javascript
> code. SVG and
> Flash lite have been available for several years in a range of
> terminals, and provide
> extended functions for animation, multimedia, and dynamic manipulation
> of objects,
> besides the definition of structured, scalable graphics.
>
> These various technologies vary in their binding to Web applications,
> with
> consequences on the kind of graphics manipulations they allow.
>
>
> 3.5.12.1 What it means
>
> Canvas is a singular, flat drawing element. Drawing onto a Canvas
> element is performed
> by JavaScript acting on the rendered display. Since graphics defined
> with Canvas
> actually consist of Javascript code, the optimizations described in
> section 3.4,
> notably 3.4.5 "Minimize External Resources", can be applied. Because the
> graphics
> object is procedurally defined, it is not discoverable as such (for
> instance by search
> engines), and entails additional processing overhead on the end device
> compared to a
> pre-defined static graphical file. Canvas is therefore best suited for
> [for what
> actually? at least one good example is needed].
>
> SVG is an XML language; graphical objects are defined declaratively and
> rendered by
> the application context browser. In contrast to Canvas, SVG elements and
> attributes
> become part of a DOM, and can therefore be manipulated explicitly with
> Javascript. Not
> all browsers support inline SVG directly within the main page markup,
> and those that
> do may restrict inline SVG to XHTML pages. This has subtle consequences:
> the DOM tree
> of an inline SVG object is integrated in the main document DOM tree,
> whereas external
> SVG object may have a separate DOM tree. When relying upon AJAX to build
> SVG objects
> dynamically, this is only possible if the browser supports inline SVG
> [AJAX
> specialists, please confirm, but from what I know this is the case]. Of
> course,
> optimizations for SVG as an external resource are more limited than for
> inline SVG.
> SVG is well-suited for graphics that must be inherently scalable and
> whose components
> have to be manipulated directly through DOM. Examples are panning and
> zooming
> geographical maps, or editing structured diagrams interactively.
>
> A proprietary technology such as Flash lite provides rich functionality,
> but, as it is
> meant to be a complete run-time environment, its functionality is closed
> (it does not
> integrate with the enclosing page), and raises additional security
> issues because of
> accesses to device capabilities and such mechanisms as non-standard
> cookies.
>
> 3.5.12.2 How to do it
>
> Canvas elements are typically drawn into at load time, using an "onload"
>
> event-handler. This will require assigning a unique id to any given
> Canvas element,
> and passing that id or set of ids to the JavaScript "onload" drawing
> function or
> functions.
>
> Canvas element width and height should be specified within the HTML, to
> provide the
> browser with sufficient layout information to properly receive the drawn
> contents,
> as well as a fallback in form of a static graphics file, in the case
> Javascript is
> disabled or Canvas insufficiently supported.
>
> For example:
>
> <body onload="drawButton( 'myButton' );">
> [...]
>        <canvas id="myButton" width="150" height="150"
>                onclick="alert( 'clicked' );">
>                <img src="thefallback.png" alt="a nice image" />
>        </canvas>
> [...]
>        <script type="application/ecmascript">
>                function drawButton(canvasId) { [...script code...] }
>        </script>
> [...]
> </body>
>
> While SVG tiny 1.2 is being implemented in an increasing number of
> terminals, the
> safest default with mobile devices is to assume SVG tiny 1.1. SVG can be
> included
> inline directly within markup supporting XML name spaces as follows:
>
> <html xmlns="http://www.w3.org/1999/xhtml"
>        xmlns:svg="http://www.w3.org/2000/svg"
>        xmlns:xlink="http://www.w3.org/1999/xlink">
> <body>
> [...]
>        <svg:svg>
>                [...SVG declarations...]
>        </svg:svg>
> </body>
>
> All browsers supporting SVG allow it to be included as an external
> resource via the
> <object> tag; a fallback should be provided. Support for SVG via
> <iframe> or <img> is
> inconsistent and not recommended. Example:
>
> <object type="image/svg+xml" data="thesvgfile.svg" width="..."
> height="...">
>        <img src="thefallback.png" alt="a nice image" />
> </object>
>
> Events generated by user actions or gestures on a Canvas or SVG element
> may be
> captured and handled. Due to the user-interface requirements of mobile
> devices,
> "onclick" events are probably the only appropriate ones to handle.
> Events such as
> "onmousedown", "onmouseup", "onmouseover, "onmouseout", and so on are
> unreliable for
> cross-platform coding in an enviroment where user-gestures are generally
> confined to
> simple finger- and stylus-taps.
>
>
> E.Casais
>
>
>
>
>
>
>