- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 16 May 2006 12:05:29 +0000 (UTC)
This reply covers most of the e-mails regarding the semantics of the
canvas element that were raised around this time last year.
On Wed, 20 Apr 2005, Olav Junker Kj?r wrote:
>
> I don't completely understand the rationale for the canvas-element in WA1.
>
> It seems to overlap a lot with the use case for SVG. Of course WF2 competes
> directly with XForms also, but WF2 has the critical advantage that it is
> backwards compatible, implementable in script (which allows an IE
> implementation), and leverages existing knowledge.
>
> Canvas does none of this
<canvas> is backwards compatible in that it provides a fallback
equivalent, like <object>. It's not ideal, but I can't see a better
solution, assuming we want to provide vector graphics to HTML authors.
Admittedly <canas> is not as good as a system which automatically
generates graphics based on semantic data. I think it would be great for
people to look into designing such a system, but I have no idea where to
even begin in doing that.
<canvas> is implementable in script in IE, see:
http://excanvas.sourceforge.net/
<canvas> leverages existing knowledge in that it uses JavaScript, but I
don't know that we could have done better than that.
> its completely new and has to be implemented by the browser vendors.
It's not available in all four major browsers (with a shim for IE).
(Opera's implementation hasn't shipped out of beta yet.)
> This rules out that it will ever be supported by IE, which in turn means
> that it will not be used on the world wide web in the foreseeable future
> (and most likely never).
Ironically, I think it's being used more than WF2. :-(
> However I dont think it belongs in a spec which is intended to cover
> *web* applications. SVG is at least usable in IE through a plug-in for
> IE, but realistically, anyone who needs interactive vector graphics on
> the web is going to use flash.
Flash is proprietary, and thus not a solution. How would you do games on
the Web without <canvas> and Audio() ?
On Thu, 21 Apr 2005, Dean Jackson wrote:
>
> Furthermore, it's a completely different model to the one that Web
> developers are used to. Why would you go against accepted practise?
Authors seem to understand the canvas API pretty well, for some reason.
> In HTML, you use script to modify the content of the document using the
> DOM.
Actually most authors use script to modify the source, using innerHTML. To
make changes to the underlying data they use the DOM Level 0 and 2 HTML
APIs, which are similar in principle to the Canvas API.
> Obviously this has pretty significant accessibility problems. There is
> no content in <canvas> - it's just script. With document-based graphics
> solutions, such as SVG and even Flash, there is real content in the
> document. Accessibility tools can access that content and provide
> alternate renderings (such as voice).
With <canvas> you can provide as rich an alternate content solution as you
wish, just like with <object>.
> For example, when you draw a circle in SVG you add a <circle> element
> into the document. That element has attributes, such as position, radius,
> fill colour, a textual description, etc. All these attributes are
> part of the DOM and available to accessibility tools. There *really*
> is a circle in the document.
There isn't, however, a table describing the pie chart that is the circle.
_That_ is the real data, and that is the data you can put as a child of
the <canvas> element, for accessibility tools (and search engines, etc).
> Using canvas there isn't a circle. There isn't anything. All that has
> happened is that some pixels on the screen have been coloured in. Those
> pixels don't have any meaning.
Nothing stops an aural browser implementation or other accessibility tool
from implementing the Canvas API, thus gleaning as much information from
the canvas as from an SVG image.
> How do you style a canvas? You can't, because there are no elements.
> Well, that isn't really true. You could, in your javascript code that is
> doing all the drawing everytime you want an update, decide to query the
> CSS OM and work out, in script, whether or not any styling rules should
> apply. But it isn't as easy as doing:
>
> circle {
> fill: red;
> }
Canvas isn't aimed at clipart graphics, logos, or other static imagery
(by "static" I mean unchanging over long periods of time, I do not mean
to preclude animation). Canvas is aimed at dynamic data representation,
like charts or graphs rendered on the fly, games, or other interactive
visualisations. For these, styling doesn't seem useful.
> The canvas model is what we call immediate mode drawing in the graphics
> community. It's popular, but suited to drawing millions and millions
> of objects where it is impractical to keep the content in memory.
Indeed, that is the target of <canvas>. The Web Apps 1.0 abstract even
uses that term.
> There are performance tradeoffs on the graphics side as well. Developers
> will have to implement code in Javascript to do the graphics management
> (redrawing everything all the time is usually a bad idea). I won't look
> forward to coding this again and again. Using a document model solution
> the implementation doesn't need to redraw everything. It knows what
> parts need updating. It can cache renderings of elements that have not
> changed for increased performance, The developer doesn't need to worry.
There are use cases for which SVG is much better than <canvas>. There is
no intention for one to preclude the other; indeed in Safari, Opera and
Mozilla the implementation of both technologies happened in tandem.
> Canvas exists to draw graphics. The workflow of such applications
> typically involves a designer drawing the artwork in an illustration
> tool. How would you get that illustration into canvas? It would be
> pretty difficult, not to mention extremely verbose and unmaintainable,
> to convert the illustration into Javascript commands. Compare this to a
> document model such as SVG where you simply export the illustration. You
> can reuse that illustration in multiple places, in multiple documents.
Indeed, this is one example where you would want to use SVG rather than
<canvas>.
On Wed, 20 Apr 2005, Dimitri Glazkov wrote:
>
> Isn't the main functional value behind the canvas element is the
> rendering context? If so, what is the significance of the canvas element
> itself? Take away the behavior, and you've got yourself another SPACER
> tag.
The significance of the <canvas> element is "here are some elements that
you should not render if you are able to support JavaScript and <canvas>,
because I'm going to replace them with something better".
> Why not allow creating rendering context on all block-level elements?
Because, frankly, this would lead to more bugs. It would probably have
been a better ideda in theory, just like the ubiquitous "src" attribute in
XHTML2, but in practice such a model is a nightmare because it requires
implementations to handle many more combinations, each of which requires
testing, and each of which results in its own bugs.
> Also, I am having hard time the "fallback content" phrase. IMHO, it's
> not the fallback content, it's _the content_ of the element. The
> rendering context is presentation (hopefully, visual interpretation of
> the content), and so are all functional behaviors that come with it.
Yes, that's probably a more strictly accurate way of looking at it.
> However, if the rendering context is available on all block-level
> elements, you can do some really neat stuff, such as using the content
> of a block-level element as arguments for rendering. For instance, the
> markup of an ordered list of links and images is transformed into an
> image gallery.
This sort of thing will probably be achievable using 'content' in CSS3. By
putting the feature at the presentation level, you avoid many of the
aforementioned problems (though not all). For example, you don't have to
worry about every element having DOM-level support for being a replaced
element, you only have to make sure any element in the rendering can be
replaced by a graphic. This compartmentalises the complexity, mitigating
the risk of many bugs being introduced. (It is still more bug prone than
not having it at all, of course.)
XBL and David Hyatt's Web Control Layout extensions (allowing arbitrary
elements to implement their own layout/painting, possibly in conjunction
with XBL) are other ways to address the problem you mention without having
to simply open up <canvas>'s API to all elements.
On Wed, 20 Apr 2005, Dimitri Glazkov wrote:
>
> Instead of this:
>
> <canvas id="weightedTags">A neat, animated graph representation of
> Technorati tags, which you poor slob can't see because your agent
> doesn't support it.</canvas>
>
> I would rather see this:
>
> <ol id="weightedTags">
> <li class="weight-3">Stuff</li>
> <!-- ... more tags -->
> </ol>
>
> with this as bound behavior:
>
> var weightedTags = document.getElementById("weightedTags");
> var context = weightedTags.getContext("CanvasRenderingContext2D");
> // use content of the weightedTags to draw with context
> // ...
>
> Does this make any sense?
Why not do:
<canvas>
<ol id="weightedTags">
<li class="weight-3">Stuff</li>
<!-- ... more tags -->
</ol>
<script>
var weightedTags = document.getElementById("weightedTags");
var context = weightedTags.parentNode.getContext("CanvasRenderingContext2D");
// use content of the weightedTags to draw with context
// ...
</script>
</canvas>
You could also do this with XBL if the canvas rendering really was just a
presentation variant rather than the original intent of the markup.
On Wed, 20 Apr 2005, Sjoerd Visscher wrote:
>
> I think it does, I really like it. It is comparable with allowing the
> src attribute on any element, as XHTML2 is doing.
I hope I've explained why this XHTML2 feature is a disaster.
On Wed, 20 Apr 2005, dolphinling wrote:
>
> I would ask what semantics canvas has. ol means the content is an
> ordered list, em means the content is emphasized, span and div mean the
> content is different, but in a way not associated with any element. Even
> img and object mean the content is external, (usually) with non-html
> semantics.
It means "this is a block of content that I intend to replace with a
graphical representation if you support graphics and scripting".
On Wed, 20 Apr 2005, Dimitri Glazkov wrote:
>
> Take your example with eyes and hair, for instance. This is the markup
> that I would expect seeing instead of a canvas element (I am improvising
> here):
>
> <span class="photorobot">
> <span class="hairColor">green</span>
> <span class="eyeColor">yellow</span>
> <span class="mouthType">puckered</span>
> </span>
>
> Then the behavior would be attached to span.photorobot to create a
> canvas and draw a mug shot.
Your markup has no more semantics (indeed, it has _fewer_ semantics) than
just the string "green yellow puckered" inside a canvas. And you could
always have both yours _and_ the canvas, simply by wrapping yours with a
canvas element.
Note that one thing I'm still looking to solve is how to represent
arbitrary data like you describe here in HTML5. So far, RDF is the only
solution I'm aware of that could even remotely do this, and I don't think
RDF is simple enough. How would you say "a face with green eyes" in HTML5,
in a structured way that XBL/JS/ATs/search engines/whatever could use?
On Fri, 22 Apr 2005, Brad Neuberg wrote:
>
> One thing I'm worried about is if we make canvas too generic, we will
> make it very difficult to implement as well as have all sorts of boundry
> conditions that we won't completely realize until the spec has been
> tested in the wild, leading to bugs. For example, if we allow any
> element to be drawn on, let's say on an absolutely positioned div that
> is located in a relative one, and this absolutely positioned div has
> overflow: auto in it's CSS, and someone uses it as a canvas and draws on
> it in such a way that its content goes beyond the elements containing
> space, scroll bars will have to appear. What if some browsers forget
> this boundry condition? How many other boundry conditions are there?
Exactly.
> In your source you simply have an IMG tag. Then, either through CSS, an
> HTML attribute, or JavaScript you 'turn' this IMG tag into a canvas and
> can start drawing on it. So browsers that support IMGs as canvases will
> get a nice surface to draw on, while those that don't will degrade
> nicely into some already retrieved image.
I don't see the advantage of overloading <img> when you can already do
this:
<canvas>
<img ... alt="35% like peanuts, 12% like chocolate">
<script>
...
</script>
</canvas>
...especially given that <img> is rarely IMHO the best fallback for a
<canvas>.
On Mon, 25 Apr 2005, Olav Junker Kj?r wrote:
>
> First I thought you were joking, but that is actually a great idea! VML
> does integrate with HTML, not just XHTML, which was one of Dave Hyatts
> major criticisms against SVG.
> http://weblogs.mozillazine.org/hyatt/archives/2004_07.html#005928
If people want to standardise VML, we're first going to have to get a more
thorough specification for it. Any volunteers? (I don't have the bandwidth
to spec a vector graphics markup language; if I did, I'd be trying to fix
the mess that is SVG.)
On Mon, 25 Apr 2005, Brad Neuberg wrote:
>
> Here's the VML standard if folks are interested:
>
> http://www.w3.org/TR/1998/NOTE-VML-19980513
This is a very vague spec. It does, however, seem much better than SVG.
> How closely does IE correspond to the VML standard? I love the idea of
> embracing and extending things from Microsoft, co-opting them. ;)
That's what WHATWG is doing quite a lot, actually.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 16 May 2006 05:05:29 UTC