Hi, Aaron- I have to respectfully disagree with David (a fine and intelligent man, to be sure), and dissuade you from using <embed>. I use <iframe>, and find it to be robust, as well as standards compliant.
Regards- -Doug Aaron Gray wrote: > Okay, I have settled on <embed>. > > Thanks for the infomation. > > Aaron > > ----- Original Message ----- > From: ddailey > To: [email protected] > Sent: Thursday, January 25, 2007 1:05 AM > Subject: Re: [svg-developers] embed .v. object .v. frames .v. iframes -- > [was SVG in XHTML file] > > > Aaron Gray wrote: > > >This brings up the issue of embed .v. object .v. frames .v. iframes I > would appreciate some pointers and advice here. > > I'll go ahead and make a stab at an answer. If I misstate or neglect > anything, I'll hope others will jump in and correct me. > > Right now, the generally recommended way of doing SVG within HTML in > existing web browsers seems to be <embed>. It works and supports SVG--HTML > (bidirectional) scripting (w JavaScript). This works fine, from my > experience, with Opera 9, Firefox 1.5+ and IE/ASV3.03. I can't speak for > Safari which is probably one of the top 4 when it comes to SVG support in the > browser. > > The problem is that <embed> is not standards compliant. <embed> seems to > have been a sort of historic placeholder for > <stuffThatTheBrowserDoesn'tReallyUnderstandWithoutOutsideHelp/> and has been > inconsistently implemented for different types of content (different > attributes, different purposes, etc.) all depending on who's plugin we're > using. > > The W3C mechanism for importing non-HTML content into HTML documents is the > <object> tag. Unfortunately (as Martin Honnen recently reminded me -- I knew > I had read that once upon a time and then proceeded to forget), Adobe > discovered a security problem with <object> in its 3.03 and disabled > scripting through it (at least when done across domains). > (http://www.adobe.com/svg/viewer/install/) . I've seen some advice that it is > possible to get a document to validate properly with some tricks, using > <object><embed/></object>, but I for one have not been able to pull that off > and still do cross-DOM scripting. Perhaps somebody has an example? > > <object> works quite nicely and simply in FF and Opera, though. > > In some experiments I did with embed object frames and iframes, (see for > example > http://srufaculty.sru.edu/david.dailey/svg/createSVGelementfromHTML.html) I > had some terrible troubles reading the SVG DOM > if it was inside a frame or an iframe. > > Eventually, I was able to solve that problem (see > http://srufaculty.sru.edu/david.dailey/svg/frameSVG.html.) with a peculiar > technique -- in the <svg> tag I placed onload="top.receive(document)" -- that > is, the SVG document sends its own document as a parameter to an HTML > function, thence allowing cross-DOM scripting. A bit kludgy for my taste, but > it gives script functionality to both iframes and frames, and that's what I > was after. Fishing for the SVG DOM inside a frame or an iframe gave me > security blocks at least in IE. Instead I let the fish come to the hook. > > On other fronts, > > a) <image src="doc.svg"> is likely not ever to support scripting, even once > individual browsers come to support that file type. > > b) the inline approach to SVG has been experimented with a good deal and is > likely to become much more convenient in future browsers (right now IE seems > to be the obstacle). The link I mentioned earlier > http://wiki.svg.org/Inline_SVG seems as consise and accurate as on this > subject as any, though I seem to recall that Andreas Neumann had some pretty > extensive stuff on this at his wonderful > http://www.carto.net/papers/svg/samples/ site -- I can't seem to locate it > quickly though. > > c) there is a <foreignObject> tag in SVG1.1 (see > http://www.w3.org/TR/SVG/extend.html#ForeignObjectElement) . It appears to > have the purpose of allowing the embedding of XHTML (and other XML content) > directly into SVG, I suppose somewhat like Microsoft XML data islands in > HTML. I haven't seen any working demos of it, and the example code in the W3C > specs is something I've not been able to make work in any browser (I'm hoping > somebody can set me straight here.) > > d) cross DOM stuff is a major focus of many of the emphases of at least a > dozen major projects at the W3C (it seems to this outsider). So as soon as > the browsers all learn to work and play nicely together, the playground will > become a very fun place with the ability to wrap SVG into alternative XML's > and vice versa using XSLT and so forth. Opera and Firefox already support > XPATH -- if IE did, then we could probably shrink the size of our DOM code by > 50%. That means we could write 200K programs for our fat clients instead of > just 100K programs nowadays. I don't know, does anybody pass more than 100K > of script into the browser at present? Seems like you'd have to get into > incremental loads if you did. While I'm at it, does anyone know if there any > W3C specs for metalanguages that might choreograph incremental loading of > software into the browser? It would be nice to be able to do that without > having to look at the browser's source code: a colleague asked me today about > sor t of pre-interpretation parsing of ECAScript and I confessed to knowing nothing about it. I'm digressing. (folks may have come to expect that from me by now) > > cheers, > David ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
