Safari the image editor?
Dave Hyatt (a Safari developer) has just made a post about Safari's addition to HTML - the canvas, and the extension of the img tag, which allows the changing of image content programmatically (using JavaScript?).
Well, sounds great. But is it a W3C standard? (I don't think so...)
By the way, the img should be deprecated and replaced with the generic object tag.
8 Comments:
Note that troll and spam comments will be deleted without any notification.
At 7/06/2004 11:37:00 am, Anonymous said…
Of course it's not a W3C standard. That said, I don't have much of a problem with vendors creating non-standard extensions to their rendering engines - so long as these extensions aren't intended for general public-facing internet sites.
From my reading of Dave Hyatt's blog, these extensions are intended to enable functionality used by the new Dashboard utilities, and other non-web (in other words, OS) uses for the WebKit engine - not for websites.
Any web developer misguided enough to use vendor-specific extensions to web standards for public-facing internet sites should be encouraged to do otherwise. Intranets are arguably another story.
Other vendors do this for good reasons - for example, Moz/Firefox etc has XUL & associated technologies for creating rich client applications. There is nothing to stop these being web-based, e.g:
http://www.moztips.com/fortunecookies/
For some reason Apple/Dave Hyatt is copping some flak for the new tech in WebKit, yet the Moz people do not.
At 7/06/2004 12:11:00 pm, minghong said…
I see...
But XUL/XBL is a bit different as it is an application, instead of a webpage. i.e. one cannot use XUL/XBL inside (X)HTML. Safari's change is, however, an extension to (X)HTML. Some authors might misunderstood that it is completely ok to use these features in their webpages (just like the use of IE-specific HTML features).
Anyway, it is the responsibility of web developers to create cross-browser websites...
At 7/06/2004 03:16:00 pm, Anonymous said…
So You would rather let web standards stagnate just for the sake of having browsers only implement what W3C has defined and nothing else?
Imho - as long as browser specific extensions don't directly contradict those standards, let them be - and let the best extensions become de-facto standards...
At 7/06/2004 05:42:00 pm, Anonymous said…
Actually, you can use XUL/XBL in webpages. I've seen it done before.
At 7/06/2004 08:56:00 pm, minghong said…
Of course we can use those "extra features". But it has to be "extra" only: the site should still usable without these features. i.e. it should be degradable.
XUL in webpages? Do you mean .xul (XHTML in XUL) or .xhtml (XUL in XHTML)? I know that the former one is possible, but not sure about the latter one. Don't know I'm talking about? Take a look of XHTML namespace or XML namespace.
At 7/07/2004 06:16:00 am, Anonymous said…
There is a W3C standard that would serve the same purpose: SVG. SVG (Scalable Vector Graphics) allows you to define all sorts of lines, shapes, and Bezier curves in XML, and is completely integrated into HTML, CSS, DOM, and JavaScript, as well as any image format supported by the web browser. SVG even lets you design complex graphics in Illustrator and embed them into your HTML document, then to animate them with JavaScript.
The application that Dave Hyatt mentioned was the rotating arm on the clock widgit. This could be animated by defining a line in SVG from the center of the clock to the second/minute point on the outside , setting its color, line weight, and blend mode in CSS, and using Javascript to rotate it simply by moving the outer point of the line. In SVG, you could even easily create a second line beneath it to be its shadow, make it black, partially transparent, and slightly blury (also with a simple SVG attribute), and rotate that as the main line rotates.
Using SVG, there's a good chance that these graphics will be compatible with other web browsers as they begin to support it. I know Mozilla is working on SVG support. And when enough people start oogling Mozilla and Safari, Microsoft may eventually come around and support it too.
At 7/07/2004 08:40:00 am, minghong said…
Unfortunately the SVG specification is huge and sometimes ambiguous. I don't know about the technical detail because I only played around with some SVG files but never wrote them. But as I know, Adobe SVG is not compatible with Mozilla SVG. IMHO I think Mozilla's implementation is more standard (e.g. inline SVG codes inside an XHTML file is possible).
Hope it won't end up like MNG/JNG (the "animated PNG") which no one is going to support it... e.g. Mozilla had dropped its native MNG/JNG support since June 2003.
At 7/07/2004 07:44:00 pm, minghong said…
Unfortunately the SVG specification is huge and sometimes ambiguous. I don't know about the technical detail because I only played around with some SVG files but never wrote them. But as I know, Adobe SVG is not compatible with Mozilla SVG. IMHO I think Mozilla's implementation is more standard (e.g. inline SVG codes inside an XHTML file is possible).
Hope it won't end up like MNG/JNG (the "animated PNG") which no one is going to support it... e.g. Mozilla had dropped its native MNG/JNG support since June 2003.
Post a Comment
<< Home