I guess this follows on from my principles of containment (2016) blog entry.

There is an aspect of iFrames that is interesting architecturally: a ‘sandbox’ feature. You can embed an iFrame in a page and have it isolated from the rest of the page, even if all the pieces of the page are served from the “same origin”.

Prototype diagramming tool that uses that sandbox for “tools”

Here statically hosted in GitHub-Pages. Here’s the source for the same. Here’s what it looks like in operation:

In this prototype there are two toolbar buttons that perform changes on the SVG canvas in the main frame. One of those is shown being actioned above. The JavaScript logic for the two buttons are in two different iFrame overlays that are isolated from the main frame that shows the canvas (and the buttons that would launch the toolbar overlays). Acronyms API, WebAPI, and API has some semantic diffusion these days, but in this context there’s an ABI that allows for the sandboxed iframe controls for the toolbar functions to invoke queries and changes on the SVG canvas. It still needs some small security work (see source code for note). Where there are a bunch of open-source RPC technologies GitHub that work via window.postMessage(..) and through the sandbox, I’m not using them for a prototype. Instead, I’m just using JQuery expressions that can be passed to eval(..) in the outer window. The inner sandboxed iframes do not themselves have JQuery in their loaded set of JavaScript libs, but they are able to send strings over window.postMessage() just fine.

Back to the two buttons…

The color picker just changes the color of all the shapes in the canvas. Not a selected subset as yet.
The wire operation is:

window.parent.postMessage("$('#Canvas_Layer_1 [fill]').attr('fill', '" + hex + "');", "*"); 

source

The other tool makes all the stroke widths (line widths) 1 point bigger or smaller. That’s two wire operations. First:

window.parent.postMessage("? $.uniqueSort($('#Canvas_Layer_1 [stroke-width]').map(function(x) { 
    return this.getAttribute('stroke-width'); }).get().sort()).join();", "*");

source

Then some for-loop javascript in the sandbox, then:

window.parent.postMessage("$(\"#Canvas_Layer_1 [stroke-width*='" + w + "']\")
    .attr('stroke-width', " + (w + diff) + ");", "*");

source

Variable w the ‘from’ width in question. Initially that’s 4 then 1 for the line-widths returned by the query operation when making the lines bigger, or 1 then 4 when making the lines smaller. Variable diff is either +1 or -1 for the ‘more’ or ‘less’ functions respectively.

As I say, the JQuery via eval() needs some security work. Maybe some consultation with the JQuery team about suitability via window.postMessage() because there is a possibility it is totally flawed.

Overall experience

A system that delivered an embeddable SVG canvas into a larger editing experience like GoogleDocs would be able to allow the addition of plugins to do discrete operations on the SVG without the elaborate integration work we see today. No SAML, SSO, Consent/Auth, Next->next->next work. That’s all error-prone and frankly confusing even to software developers who make the same technologies. See “rationale” below.

What you could have here is a simple per-document workflow like “Add Corel Shadow Effects (TM) tools to this GoogleDoc diagram”. If those were not free, have Google handle the micropayments on each actual use. Then, remove the same tools another day, but still have the SVG shapes as changed by the same tools had you used them. You’d gain comforts from knowing the resulting SVG source was your guarantee of long-term viability of the diagram. You would gain more comforts knowing that only editors of the SVG diagrams would need the plugins - readers could see the finished result just fine. Heck, document editors who were focussed on the written prose and not the fine-grained diagram editing could still make less fine-grained changes to the SVG diagram and not wreck the changes made by someone else prior to that moment with the tools/plugins installed for them.

Glass Ceilings

Inside the DOM of the browser many straight operations on the SVG representation of a diagram just work. It’s not a perfect world though. If you wanted to make an “align top edges” toolbar item, you would have trouble. As some SVG shapes are made from Bézier curves, it is not clear what the bounding top-left or bottom-right coordinates are until it is actually rendered. You simply can’t pick those details from the implicit <shape/> element like I have done for the two tools already. You could try to run your own engine to render the same shape in an off-screen way, but that seems like folly. Better to query the browser’s own actual rendered view of the shape. That might feel like it is browser-specific though even if there are hints in the browser API documentation: DOMRect vs SVGRect. I tried a little and gave up as a blog entry is my goal not seed funding for a startup that Google would acquire.

History of interprocess communication - ARexx in particular.

JQuery is a very expressive thing over this window.postMessage() ABI/API.

Back in 1987 there was home computer called the Amiga from Commodore that had a language that was installable called ARexx and good for interprocess communication. See AmigaOS Manual: Python Interprocess communication through ARexx ports - even though that’s recent (the Amiga still has fans) and talks of Python too, it’ll give you an understanding of the wire commands that were available for this machine/OS before the world wide web. By version 2 of AmigaOS, it was bundled. ARexx on the Amiga for interprocess-control was an amazing experience. Use of JQuery over this window.postMessage() wire reminds me of that. Sure, ‘eval’ situations for all languages have had their security challenges and ARexx would have had dozens had the Amiga been a contender beyond the 80s. The other problem with ARexx “port” way of connection two process is that the principle of containment didn’t apply - it was wide open - any process could chat to and launch any other.

Rationale

For in-document diagramming, all of Mural, Miro, Diagrams.net, Lucid-Charts (and their GoogleDocs integrations), and are terrible experiences. Microsoft Sharepoint and MsWord don’t have an obvious high-capability diagramming tech, either. On that last, I have access to a version of Visio from 2009 in a corporate setting, but not anything more recent because it is incredibly expensive (and Windows only). Those techs are mostly terrible because of the “integration” setup, but also because of the lock in to the technology after you have committed to it. As you’re going through those integrations steps, your mind wonders what else from your cloud-stored files can the vendor now see or change without you knowing. I mean those doubts that build up and make you wonder if you shouldn’t just read a book made from trees. The lock-in aspects of these tools are also terrible. At least they are from a long term knowledge-management point of view.

We have a standard in SVG and supported in all modern browsers. It is the best interoperable standard for drawing that we have in 2022. Not just for representation in a browser, but for canonical save-state, and rendering into PDF or actual print. You can have a SVG canvas in a page, have that canvas saved/loaded by the underlying platform itself (say GoogleDocs). Then you could have multiple plugins provide editing services for it in-situ in the page. It need not be an either-or choice of which plugin it, could be many of them. They could be free or paid. Either way, an emerging standard that’s needed.

More backstory: Me whining about Miro on Twitter a week ago. About GoogleDocs drawings a few weeks ago, and Chromebook, pens and drawing apps that has videos from a month ago.