« Call for opinion: text-zoom interaction with SVG | Main | 2005-06-01 Weekly Update »
June 1, 2005
Call for opinion: <foreignObject> in Firefox 1.1
In the recently released Firefox 1.1a1 there is a restricted implementation of SVG's <foreignObject> element. It can only do translations, not guaranteed "live" with respect to its contents, and behavior with respect to z-ordering and clipping is undefined.
Some people think that this rudimentary <foreignObject> should be removed for Firefox 1.1 because content written for a future full implementation of the feature will fail ungracefully on Firefox 1.1. Are any content developers out there working on content that uses the existing <foreignObject> and would be disappointed in it being removed until the next major version of Firefox after 1.1?
Posted by tor at June 1, 2005 7:33 PM
Comments
For me, I'd rather have something done right even if it takes months, than end up with having to support working and buggy implementations of the same thing forever (hello box model).
That's just my opinion though, I can't think of what I could use this element for yet.
Posted by: Ant at June 1, 2005 10:04 PM
Well, i dont think it will matter to most/all of the users. I dont know of any SVG editors that surport the object ~(other than text based ones), its not like its widely surpported, it just seems unnessasery to provide a BUGGY implmentation of it, which is basicaly eye candy. MUCH better to wate for a propper implimentation so it can be used proppaly + behave like it should
Posted by: tom at June 1, 2005 10:38 PM
It's not just eye candy - it's currently the only way to create a mixed namespace document with svg being the parent of elements from other namespaces.
Posted by: tor at June 1, 2005 10:45 PM
Does this mean that we couldn't make an SVG-document with HTML tags in an HTML-namespace (your previous comment seems to suggest this) ? If that is the case, I'd like ForeignObject support to stay.
By the way, if you have time, is there any reason why the following code would not work in Firefox SVG? Here it is:
...
#wrap {
background-image: url('svg-file.svg') no-repeat fixed center;
}
(Div with id wrap and some content)
...
I would expect svg-file.svg to show up as a background, but it doesn't.
Posted by: Foxtrot at June 1, 2005 11:41 PM
Correct, xhtml (or any other non-svg namespace) elements as direct children of svg elements will not be shown unless contained in a foreignObject.
Your example will not work because currently we don't support SVG as a target of [x]html or for css properties accepting an image.
Posted by: tor at June 2, 2005 12:20 AM
Thanks for the reply! :-)
If this only disables (x)HTML within SVG and not opposite, I would think disabling it will be a good idea. I don't think either that editors generally support it, and it's better to discourage of it at this stage and allow it to degrade gracefully later than to try to force the future upon the user and fail.
Posted by: Foxtrot at June 2, 2005 1:12 AM
I think it’s a good idea to disable it then. I am experimenting with some SVG, but although foreignObject is cool, I don’t really need it. So I wouldn’t mind not being able to use it until Firefox 1.5.
~Grauw
Posted by: Laurens Holst at June 2, 2005 2:21 AM
Yeah, I believe as others, disable it as it won't be of much help - but can potentially cause some harm (increased bug report, 'ad-hoc' implementation that would crash when the spec will be implemented, ...)
Posted by: franCk at June 2, 2005 4:39 AM
I think the right approach is to disable it on the branch. By the time the final release comes out, the trunk will have reopened, and anyone wanting to play with or hack on it can get a build from there.
Posted by: Gerv at June 2, 2005 9:41 AM
> background-image: url('svg-file.svg') no-repeat fixed center;
as far as mozilla is concerned, SVG isn't an image. it's a document format like HTML or XUL, and because of that, SVG is not supported where an image is expected.
(this is the current state, at least)
Posted by: christian biesinger at June 2, 2005 12:10 PM
I'm not working on any content with foreign objects at the moment, so my opinion is introduce it when it works properly and its behavior is well-defined.
For the side-track issue of "as mozilla is concerned, SVG isn't an image", I REALLY think Moz should work on changing this because being able to set the background of an HTML document as an SVG image would be a killer feature. This guy apparently agrees with me: http://blog.steeleprice.net/archive/2005/03/17/594.aspx
Regards,
Jeff
Posted by: Jeff Schiller at June 2, 2005 3:55 PM
Without foreignObject, is it possible to embed multimedia content (QuickTime movie, etc) within an SVG document?
Posted by: Mo at June 2, 2005 4:19 PM
Without foreignObject, you're restricted to only SVG elements in an SVG document or fragment. The closest you could get to a movie would be an animated gif, or possibly a multipart/replace jpeg stream (latter untested).
Posted by: tor at June 2, 2005 4:31 PM
Every implementation I've seen has some quirks. Why not to do it in a really standarts-compliant way and do implement some condition or capability string?
Posted by: gsm at June 2, 2005 5:17 PM
"I REALLY think Moz should work on changing this because being able to set the background of an HTML document as an SVG image would be a killer feature. This guy apparently agrees with me: http://blog.steeleprice.net/archive/2005/03/17/594.aspx"
The SVG specification also agrees with you :)
http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#ConformingSVGViewers
If the user agent includes an HTML or XHTML viewing capability or can apply CSS/XSL styling properties to XML documents, then a Conforming SVG Viewer must support resources of MIME type "image/svg+xml" wherever raster image external resources can be used, such as in the HTML or XHTML 'img' element and in CSS/XSL properties that can refer to raster image resources (e.g., 'background-image').
Posted by: Chris Lilley at June 2, 2005 5:54 PM
Without foreignObject, in SVG 1.1, you can't do video, correct. In SVG 1.2 you can do video (using the video element).
I think that disabling foreignObject is reasonable if there are going to be problems with rotation, content update, or interactivity.
Having it disabled by default and enablable at user option would be another possibility to permit experimentation and testing.
Posted by: Chris Lilley at June 2, 2005 5:58 PM
Disable it. If you enable a buggy or incomplete version, then developers will always have to code to that lowest common denominator. You'd be introducing another quirk for everyone to handle forever.
Posted by: Rob at June 3, 2005 4:06 PM
Rob: if we were going strictly on that metric of "if a feature is incomplete, don't ship it" we wouldn't bother enabling SVG at all, as many elements are partial implementations (noticably the text ones).
Posted by: tor at June 3, 2005 8:16 PM
tor: But the difference is that for things like text-based features most developers have other SVG implementations to test and compare against (ASV for one). Isn't Moz the only implementation that would currently support some form of foreignObject? If so then, as Rob states, you WILL be setting a bad precedent that will be a harder habit to break for developers later (as compared to other features in different SVG implementations that work properly).
I admit that foreigObject is a great feature to have but SVG needs to find inroads into the web in smaller avenues (like the simple ability to load a SVG image anywhere you can load a jpg/png image in a HTML doc as we've discussed in this thread). My opinion is that Firefox should get THAT to work first and show people the benefits of scalable backgrounds, icons, buttons, etc. You'll create quite a stire when you do...
Posted by: Jeff Schiller at June 4, 2005 6:12 AM
On the other hand: "Having it disabled by default and enablable at user option ... to permit experimentation and testing" is just fine...
Posted by: Jeff Schiller at June 4, 2005 6:13 AM
I'd wait with enabling it to some later releases, 1.1 without foreign object should be nice enough...
Posted by: Marek Raida at June 6, 2005 9:37 AM
I must agree with the others. I'd rather wait for Firefox 1.2 or 1.5 for working than a broken half implementation now. Yes, it's a VERY nice feature, and apparently needed for SVG to be treated equally with (X)HTML and friends. Still, we can wait until it works. Please, I beg of you and your team not to include a broken feature. Content developers, book authors, tutorial writers, and the general public do not need this AGAIN. Fixing it in 1.1.1 or 1.1.4 won't help either because you have NO guarantee that everyone has been keeping their patches up to date. We all can wait. Heck, there's not even that much SVG content ON the public internet so it would be best to force content developers to do it right or don't do it at all rather than having to write two versions of SVG markup for "broken" Gecko and "working" Gecko.
If you must include it, make it a "super-s3kret" option in about:config disabled by default in all releases in the FF 1.1.x branch. A previous poster said essentially this. That way, devs and the brave can test it, and the general public can blissfully do without. If it's fixed in an update or backported from the trunk, don't re-enable it and don't remove the about:config option entirely just to keep things consistent within that branch's feature set.
Thank you.
Posted by: jamcnair at June 13, 2005 2:30 PM
Please keep the <foreignObject> in Firefox 1.1
I can't see another way to use dropdown menus etc. in our SVG apps and am really tired to build those from scratch in JavaScript or else. I can hardly see any need to rotate a dropdown menu other than for the fun of it. But it would be very helpful to advertise Firefox's native SVG support with working examples of mixed namespaces.
Given the difference between ASV3 and Firefox' SVG implementation, today's SVG examples will have to be tweaked constantly with regard to emerging user agents, so I wouldn't mind if "content written for a future full implementation of the feature will fail ungracefully on Firefox 1.1"
Posted by: Michael N at June 22, 2005 2:12 PM