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 sort of pre-interpretation parsing of ECMAScript and I confessed to knowing nothing about it. I'm digressing. (folks may have come to expect that from me by now) cheers, David [Non-text portions of this message have been removed] ----- 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/
