Hi, Ruud-

steltenpower wrote:
|
| Imagine you have built an application with XBL cause that is a great
| clean way of working with you data. While using the application you at
| some stage get such a nice picture on screen that you want to save it,
| maybe edit it with Inkscape and then use it for a PDF business report.
| Or less lucky; you get such a weird picture you expect something's
| wrong and like to use SVG debugging tools to figure out if or what is
| wrong in the SVG picture.
|
| To my surprise with MozXBL1 there is not a SVGDocument instance you
| can somehow get to. Also the DOM inspector doesn't offer a way. I'm
| now clumsily adding things in my bindings to still get to a
| SVGDocument, or rather construct it from ShadowContent bits (i'll post
| code when i'm done/stuck). Some helpful Mozilla people explained that
| MozXBL isn't designed for such a use case, that the Gecko rendering
| engine is not well fit for it and that it won't be possible at all in
| MozXBL2 for security- and DOM-limitation reasons.
|
| Do you think XBL is the right principle/way to go to implement this
| use case scenario, and if not please tell why and describe the mix of
| specifications that you think would better fit ?
|
| Am i missing or mistaking something in this message?


I think this is a perfectly valid use case, though I certainly can't speak
for the MozXBL guys, nor can I suggest a workaround (other than building a
"static" copy when you are constructing the elements via script). I will
suggest to the sXBL TF that there is a way to serialize the shadow content
en masse, such that it would be easier to save the output. The
presentational view of the data can be as important as the data itself.

The rationale "for security reasons" doesn't ring well with me, personally.
It always sounds like the politicians who say, "Think of the children." The
fact is, there are secure implementations of DOM3 Load&Save, and WebAPI is
addressing the issue of sandboxed file access.

Regards-
Doug