One motivation to implement
include has been reuse of images. For example, reuse of illustrations across an organization by inclusion of images made by others. With Adj that implies pretty good automatic adjustment.
include copies all or part of another document into the current document.
More than with other Adj commands, with
include there can be significant difference in verbosity and size between the same document without (before) or with the result of (after) invoking Adj: In this example 13 versus 42 lines. That difference is between the sources of the documents as stored. In contrast, once processed by Adj then the two documents will be identical in browser memory – then their DOM trees should be identical.
If so stored then Adj will display the stored result of inclusion of an earlier invocation until a current inclusion completes successfully. This gives greater certainty something useful will be displayed even in case the origin of an inclusion becomes unavailable.
include has to read other documents, which may come across a network, some applications may want to invoke
Adj.doSvg() with a callback function.
include is capable of nesting, like many other features of Adj.
Authors and users working with local files, with URI scheme
file, possibly should consult documentation. Ask questions if not clear. It works.
You could ignore implementation details, and simply use
include is covered by several test cases in the Adj test suite. Look for test cases having the word “include” in the file name.
Dealing with SVG inline in HTML to make
include work has been an effort possibly larger than making
include work with plain SVG. Pesky details abound when allowing inclusion either direction between those two formats. Hopefully covering all cases, or at least all cases that will occur in real use.
Writing one more auxiliary Firefox add-on was an additional effort. Someone porting it to a Chrome extension would be a welcome contribution.