CANVAS element in MozillaAn implementation of the CANVAS element landed on the Mozilla trunk which means that Firefox 1.1 will most likely have support for it unless it is backed out. The CANVAS element is defined in Web Applications 1.0 which will eventually be renamed to HTML5. The element can be used to generate images on the fly using various javascript functions and DOM attributes.
Now I’m not sure if Mozilla’s implementation matches that of Safari. Ian Hickson mentions that Safari implemented a backwards incompatible version using the same model as the IMG element, which means that browsers have to support the element to not support it. (The fallback content is inside the ALT attribute instead of inside the element as the specification suggests.) I hope Mozilla implemented a version with a closing tag and Safari will update their implementation to match the specification.
I guess some people will think FONT is back but let me note that this time the implementation is based on an open specification that everyone can use to implement theirs on. Reverse-engineering is not necessary here as it was in time of the ‘browser wars’. Also, it is very likely that HTML5 will eventually be submitted to the W3C once it is more stable. (I’ll post some information on HTML5 later.)
Update: it appears Mozilla has the ugly (albeit Safari compatible) implementation. See bug 291216 for details.
(I’ll post some information on HTML5 later.)
Give us some links or blog away! I'm sure there are many others who read this blog who want to know more.
This should never have been an element. The best way to do this is to only create a canvas interface, just like the audio interface. With the interface you would have to choose an image in the document to replace. Canvas has no right being an element because it doesn't do anything without scripting.
Sjoerd: You shoulda said something on the WHATWG list. :-) (Unless you did? I don't remember discussing this and can't find any outstanding open issues on <canvas>.)
I don't see why an element should stop being an element just because it is only useful with scripting. I expect plenty of elements in HTML5 to be intrinsincly linked to scripting. They're still elements. We still win by having UAs be able to spot them a mile away.
I guess the real question is: how canvas is pertinent to the content of the page?
As a way to put it in perspective: Is the photo paper part of the picture?
Ian: I hadn't thought of this solution before. On performance: if you put a script element in the head of the document containing var canvas1 = new Canvas(), UAs can initialize a canvas before actually encountering the location in the document where the canvas will be rendered.
Dimitri: wrong perspective. My perspective: the canvas element is like issuing a newspaper with blanks for the pictures, and adding an addendum with drawing instructions.
I've moved this to the whatwg list, and added a reply there. :-)
Sjoerd, thanks for example. After reading through the spec, I agree with your perspectie. I haven't really studied the WA1 document until this morning.
If you wan't dynamic pictures use a server side language... I too can't see the point of the <canvas> tag.
In that mozilla bug posted above, it talks about using the correct <canvas>...</canvas> syntax so that clients that are unable to display the <canvas> correctly can simply show some text instead.
Now, this is a very good idea, but why stop there? Why not do the same with <img> tags? It would be a real boon to be able to drop current image replacement methods and just use <img> tags instead.
Now for a real quick question, are there any standards in the drawing that do exactly that? Or do I have to keep using something like:
<h1><img src="heading_about.png" alt="About" /></h1>
This isn't a bad way of doing things, but in most browsers it makes the heading text unselectable because its part of an image.
The Wolf, have you missed the OBJECT element somehow? It has been there since HTML4.
The Wolf: In XHTML2 you would write that as:
<h1 src="heading_about.png">About</h1>
No, I've not missed it :) I would just like to see the <img> tag work in a similar way. After all, the <img> is for images while the <object> tag is more general.
Sjoerd, nice! I didn't know that you would be able to use src attributes like that, I know that you can use href attributes 'anywhere'.
I'd like to read up more on XHTML2 and other future standards, perhaps someone would be willing to compile a list of usefull links about them? *cough* Anne?
You could use Google. Eventually, I will write something up about HTML5 as well.
Didn't think you'd written quite that much on XHTML2. Thanks :)