Re: [whatwg] Usemap and ismap for canvas tag
On 05/03/2008, Greg Houston [EMAIL PROTECTED] wrote: I really didn't mean to shift the emphasis to SVG at all. I don't think anyone is going to try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap [via] JavaScript on a canvas image. *cough* I think history demonstrates that people will try to do anything they possibly can if the results promise to be cool enough eventually. If something can be done at all with promising results on the highest-end available PC, it would be safe enough to assume it will be common a couple of years later. Fortunately, Hixie is highly aware of the history of the benighted X11 Image extension - which to implement properly would have required the equivalent of an embedded copy of ImageMagick :-) - d.
Re: [whatwg] Usemap and ismap for canvas tag
Greg Houston wrote: I would like to request that the canvas element get the same usemap and ismap properties that the img element has. One way this effect could be simulated is by overlaying a transparent img over the top of the canvas, and appling the imagemap to that instead. Given that it's so trivial to work around it now, are there sites that are actually doing that, or anything else that would indicate some level of demand for this feature? I'm not saying it's a bad idea, I'm just trying to find out how much incentive there is for browser vendors to implement a feature like this. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Usemap and ismap for canvas tag
Hi Lachlan, I am currently implementing the method you describe here: http://demos.greghoustondesign.com/piechart/ Generally, the use of a blank transparent gif seems to me to be the indication of a hack required due to some inadequacy of HTML and/or CSS, e.g. old school table shims which are still often found in HTML emails. Though you can use image files with canvas, part of the appeal of the canvas tag is not having to, and thus not having to make http server requests for images. After making a graphic with the canvas tag, it's a bit disappointing to have to place a gif on top of it. It's sort of like buying a new economy size car only to find out that in order to go anywhere with it you have to tow it with a truck. As far as demand goes, most developers are still unaware of the existence of the canvas tag, and then a large portion of those that have heard of it do not realize there is a semi-functional way to get it to work with Internet Explorer via ExCanvas or Moocanvas (minus several gradient features). A lot of developers like myself will not implement something if it is not supported by at least Firefox, Opera, Safari, and Internet Explorer. There hasn't been a truly cross-browser supported HTML graphics yet. VML, SVG, and Canvas have partial coverage over the various browsers, but once SVG and Canvas are supported without plugins or javascript bridges I think you will see their use increase greatly. General developers don't want to jump through hoops with javascript bridges and they don't want to make their end users jump through hoops with plugins. As the use of the canvas tag increases people are going to want to interact with it. In our Web 2.0 world, if you cannot interact with your dynamic content there is a feeling that something is missing. We like gadgets, widgets, little things with interactive features. We want to unfold layers of information. Charts, graphs, and data visualizations of all sorts are becoming increasingly common on the web. The YUI javascript framework actually uses Flash to make graphs with tooltips, but some of us would like to avoid the use of Flash as much as possible. Giving the canvas tag usemap and ismap properties gives the canvas some small degree of interaction without requiring developers to jump through quite so many hoops. Also, If a new developer starts reading the documentation on the canvas tag and sees the usemap and ismap properties listed it will help clarify somewhat the nature of the canvas tag, that it is flat object, but that you can interact with its parts using an overlay. Here is one last personal example of the canvas tag with some basic interactivity. I wanted to create a cross-browser method to create rounded corners and drop shadows without images, again in order to not have to load so many images. Usemap would have greatly simplified giving functionality to my simple window controls. http://greghoustondesign.com/demos/mocha/ On a side note, I was just glancing over the newly released, Internet Explorer8 Readiness Toolkit, and it says: Internet Explorer 8 offers Web developers the opportunity to write standards-compliant HTML-based Web pages that support features (such as SVG, XUL, and MathML) in namespaces, provided that the client has installed appropriate handlers for those namespaces via binary behaviors. (A binary behavior is a type of ActiveX control.) I am not entirely sure what that means, but it looks like users will still have to install something in order to view SVG with Internet Explorer. There is no mention of canvas. Cheers, Greg On Wed, Mar 5, 2008 at 7:46 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: Greg Houston wrote: I would like to request that the canvas element get the same usemap and ismap properties that the img element has. One way this effect could be simulated is by overlaying a transparent img over the top of the canvas, and appling the imagemap to that instead. Given that it's so trivial to work around it now, are there sites that are actually doing that, or anything else that would indicate some level of demand for this feature? I'm not saying it's a bad idea, I'm just trying to find out how much incentive there is for browser vendors to implement a feature like this. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Usemap and ismap for canvas tag
Dnia 05-03-2008, Śr o godzinie 09:39 -0600, Greg Houston pisze: On a side note, I was just glancing over the newly released, Internet Explorer8 Readiness Toolkit, and it says: Internet Explorer 8 offers Web developers the opportunity to write standards-compliant HTML-based Web pages that support features (such as SVG, XUL, and MathML) in namespaces, provided that the client has installed appropriate handlers for those namespaces via binary behaviors. (A binary behavior is a type of ActiveX control.) I am not entirely sure what that means, but it looks like users will still have to install something in order to view SVG with Internet Explorer. There is no mention of canvas. FYI: It means you use a custom tag instead of OBJECT; the control to embed is determined by the tag name and the binary behaviour provides the associations. It is more convenient when you intend to use several embedded elements or have the element data in-line. The main objection is that such a document is nonconforming. There are two ways to embed foreign content in HTML: the SCRIPT element and a data URI. SCRIPT has its limitations (no decrement operator in JavaScript) and data URIs are cumbersome and unsupported by IE. XHTML is somewhat more flexible but IE offers to save it to disk or displays it as a tree unless you cheat about the content type in which case you break everybody else. (You have to explicitly forbid ASP to cheat if you do not want it to because ASP think and instruct the developer that XHTML is just like HTML, only better.) Looks like a dead end to me. Keep smiling Chris
Re: [whatwg] Usemap and ismap for canvas tag
Greg, I remember seeing the quote here: canvas is designed for creating images dynamically in scripts. SVG focuses on pre-computed image documents, and is more complex and slower to generate dynamically. at some point in time and thinking to myself that it was basically inaccurate. I realize it is probably not you who wrote this delightful aphorism of guidance for the rest of us, so it is not with you that I would raise objection. For me, SVG does not at all focus on pre-computed image documents, but rather it is because of its dynamic qualities that I use it. It is more complex than canvas, that is for sure. I think in terms of speed, though, it all depends on what you are doing. Try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap through your own JavaScript on a canvas image -- then let's talk benchmarks. [references available upon request] But certainly and absolutely I would have never shown SVG more than a passing glance if it had been focused on pre-computed image documents -- how boring! VML was perfectly interactive and canvas-like for most mundane purposes, it just didn't have bitblits. If MS had had the foresight to put bitblits in VML we'd all be using Silverlight now and Microsoft would buy Google. /kidding I think the aphoristic quote may have propagated from the relatively confined arena of WHATWG to the more noticeable archives of the W3C (am not sure about this) but it might be nice for whoever runs the canvas boat to steer the comparison a little more precisely. regards, David - Original Message - From: Greg Houston [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Monday, March 03, 2008 11:40 PM Subject: Re: [whatwg] Usemap and ismap for canvas tag Wouldn't it make more sense just to use SVG? Dynamic interactive charts and graphs seem to fall into the gray area between what is more appropriate for canvas or SVG. canvas is designed for creating images dynamically in scripts. SVG focuses on pre-computed image documents, and is more complex and slower to generate dynamically. So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Greg
Re: [whatwg] Usemap and ismap for canvas tag
David, I really didn't mean to shift the emphasis to SVG at all. I don't think anyone is going to try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap [via] JavaScript on a canvas image. All I am doing here is making simple pie charts, and I would like those pie charts to have simple hot spots, nothing fancy. With hot spots these simple canvas graphics then have very basic interactivity such as links and tooltips without increasing the overhead of the canvas element. Also, implementing this in the browsers should be trivial since the usemap and ismap functionality already exists for the img tag. This is just about very basic functionality and is aimed to benefit simple-minded web developers like myself who are not necessarily trying to perform graphic rocket science. canvas id=myChart width=200 height=200 usemap=#myMap/canvas Greg On Tue, Mar 4, 2008 at 9:47 PM, ddailey [EMAIL PROTECTED] wrote: Greg, I remember seeing the quote here: canvas is designed for creating images dynamically in scripts. SVG focuses on pre-computed image documents, and is more complex and slower to generate dynamically. at some point in time and thinking to myself that it was basically inaccurate. I realize it is probably not you who wrote this delightful aphorism of guidance for the rest of us, so it is not with you that I would raise objection. For me, SVG does not at all focus on pre-computed image documents, but rather it is because of its dynamic qualities that I use it. It is more complex than canvas, that is for sure. I think in terms of speed, though, it all depends on what you are doing. Try running a Gaussian blur of a dynamically generated mouse-driven turbulence displacement of a bitmap through your own JavaScript on a canvas image -- then let's talk benchmarks. [references available upon request] But certainly and absolutely I would have never shown SVG more than a passing glance if it had been focused on pre-computed image documents -- how boring! VML was perfectly interactive and canvas-like for most mundane purposes, it just didn't have bitblits. If MS had had the foresight to put bitblits in VML we'd all be using Silverlight now and Microsoft would buy Google. /kidding I think the aphoristic quote may have propagated from the relatively confined arena of WHATWG to the more noticeable archives of the W3C (am not sure about this) but it might be nice for whoever runs the canvas boat to steer the comparison a little more precisely. regards, David - Original Message - From: Greg Houston [EMAIL PROTECTED] To: whatwg@lists.whatwg.org Sent: Monday, March 03, 2008 11:40 PM Subject: Re: [whatwg] Usemap and ismap for canvas tag Wouldn't it make more sense just to use SVG? Dynamic interactive charts and graphs seem to fall into the gray area between what is more appropriate for canvas or SVG. canvas is designed for creating images dynamically in scripts. SVG focuses on pre-computed image documents, and is more complex and slower to generate dynamically. So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Greg
[whatwg] Usemap and ismap for canvas tag
I would like to request that the canvas element get the same usemap and ismap properties that the img element has. It seems the canvas tag was designed primarily for fairly simple dynamic data visualizations, but even so, having some basic, built-in, intuitive methods for interacting with these graphics would be nice. Beyond, the standard image map, it would also be nice if after closing a path you could add the shape created to the dom and give it an ID, though I a may be pushing it with this request. You don't necessarily need to be able to directly modify the shape itself via the dom (that might be difficult since I think the canvases are drawn flattened on one layer), but merely be able to add event listeners to that shape such as onclick and mouseover. Basically what I am proposing is not much different than an image map, but one where this virtual canvas image map can be created with canvas commands rather than having to draw the shape a second time and add it to the image map separately. ... draw shape ... ctx.closePath(areaID) vs. ... draw shape ... ctx.closePath() ... draw shape again as an image map area ... ... inject newly created area into map So merely giving the canvas element the usemap and ismap properties would be helpful, though better yet if canvas shapes/areas could be added to the dom directly. The following is an example of a canvas pie chart with a dynamically generated image map overlayed on top of it. Since the canvas element does not as of yet have a usemap property I had to use a blank transparent gif for the overlay. http://demos.greghoustondesign.com/piechart/ Also, again realizing I am pushing it, in the modern world it would probably be nice if there was an image map shape type that supported bezier curves. In the example above the circumference of each pie slice is approximated with several vertices. Cheers, Greg
Re: [whatwg] Usemap and ismap for canvas tag
Wouldn't it make more sense just to use SVG? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Usemap and ismap for canvas tag
Wouldn't it make more sense just to use SVG? Dynamic interactive charts and graphs seem to fall into the gray area between what is more appropriate for canvas or SVG. canvas is designed for creating images dynamically in scripts. SVG focuses on pre-computed image documents, and is more complex and slower to generate dynamically. So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Greg
Re: [whatwg] Usemap and ismap for canvas tag
On Tue, 04 Mar 2008 13:40:52 +0900, Greg Houston [EMAIL PROTECTED] wrote: Wouldn't it make more sense just to use SVG? ... So canvas is tuned more for creating dynamic charts and graphs whereas SVG is better apt for static sprites and interface elements with the bonus that it can automatically detect interaction. WHATWG SVG and Canvas Comparison: http://wiki.whatwg.org/wiki/SVG_and_canvas My second idea of being able to add canvas shapes directly to the DOM may be too much. Though since canvas renders onto a fixed-resolution bitmap and is basically a flat image, giving the canvas element the usemap and ismap properties doesn't seem like it would be a big issue. This seems to make sense to me. Browser agents could probably use pretty much the exact same code for both the img and canvas tag where image maps are concerned. The benefit would be being able to add hot spots for links and tooltips to canvas drawings. It seems silly that something as dynamic as the canvas element would have less interactivity than the img element. Right. On the other hand, loading it with a DOM would slow it down to the point that it loses its major benefit over SVG (at least as I see it) - the fact that it is relatively lightweight, ergo faster. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
