-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Develop a new standard for describing "layers" in SVG authoring tools #68
Comments
If we are exploring the idea of defining how layers are denoted, then I suggest we also would need to expand the scope to include other concepts such as a "page" and its associated metadata. Possibly also useful would be other common metadata that editors use such as grids, rulers and scales. I don't know whether this is all within the scope of SVGWG consideration though. |
@AmeliaBR I don't think that proposal addresses the problem described in the referenced issue of allowing a shape to be inside two groups (one being an animation group and one being a layer). I also wonder if editor specific data should be defined with CSS rather than in SVG attributes. That way the relationship is such that the SVG doesn't change, and the editor specific data doesn't clutter up the SVG markup (and can also be dropped for publishing). |
@AmeliaBR Thank you again for opening this issue after the long discussion in the other thread. This is my proposal from the other thread. I still think that this is the best for artists and developers according to my experience. Please take it in consideration: PROPOSED SPEC for an improved z-index Features to be added to the z-index:
<z-index ... position="2" ... />
<z-index ... id="background-layer1" title="far mountains" position="2" ... />
<z-index ... visibility="hidden" position="2" ... />
<Z-INDEX ... filter="url(#dropshadow)" ... />
<Z-INDEX ... mix-blend-mode="multiply" ... />
<Z-INDEX ... mask="url(#some_element)" clip-path="url(#some_element)" ... />
<Z-INDEX ... transform="translate(140 105) rotate(60 140 105 ) skewX(60) skewY(30) scale(-140 -105 300 150)" ... />
<Z-INDEX ... opacity="25%" ... /> USAGE Each svg z-index layer should be first declared like this: <Z-INDEX position="4" id="mountains-layer" title="Mountains in background" visibility="visible" transform="translate(140 105) rotate(60 140 105 ) skewX(60) skewY(30) scale(-140 -105 300 150)" opacity="25%" mix-blend-mode="multiply" mask="url(#some_element)" clip-path="url(#some_element)" /> And then used in any svg element (not groups!) like this: <anysvgelementnotgroup ... z-index="4" ... >
...
</anysvgelementnotgroup> The "position" value can be automatically inferred by the order of the z-index declarations in the svg document, so you can avoid to explicitly add it as an attribute. And of course if no z-index entity is declared, a default z-index entity with position="1" should be used for all objects to ensure backward compatibility. LAYERS ANIMATIONS
|
I agree with @AmeliaBR that if layers are to be added to SVG, they should just standardize what authoring tools are already doing using either vendor XML prefixes or custom naming conventions. Below is the output I got from various vector graphics editors after exporting a document with two layers to SVG. I don't have Adobe Illustrator installed on my machine, hopefully someone else will be able to provide the output. I also tried Sketch and Vectr.com, but they don't seem to support export of the whole document (rather than individual slices or pages) to SVG.
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 2481 3508" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:1.41421;">
<g id="Layer1"></g>
<g id="Layer2"></g>
</svg>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0" y="0" width="612" height="792" viewBox="0, 0, 612, 792">
<g id="Layer_1"></g>
<g id="Layer_2"></g>
</svg>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" width="210mm" height="297mm" viewBox="0 0 210 297" id="svg2" version="1.1">
<g id="layer1" inkscape:label="Layer 1" inkscape:groupmode="layer"></g>
<g id="layer2" inkscape:label="Layer 2" inkscape:groupmode="layer"></g>
</svg>
<?xml version="1.0" encoding="utf-8"?>
<svg width="100%" height="100%" version="1.1" viewBox="223.7717 124.5591 289.4646 261.1181" style="background-color:#FFFFFF" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns="http://www.w3.org/2000/svg">
<defs />
<g id="layer1" inkscape:label="Layer 1" inkscape:groupmode="layer"></g>
<g id="layer2" inkscape:label="Layer 2" inkscape:groupmode="layer"></g>
</svg>
<?xml version="1.0" standalone="no"?><!-- Generator: Gravit.io -->
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" style="isolation:isolate" id="svg" width="1024" height="512"><rect width="1024" height="512" style="fill:rgb(255,255,255)"/>
<g>
<g style="isolation:isolate"/>
<g style="isolation:isolate"/>
</g>
</svg> |
I can add some data for the program I use the most, which is Xara. SVG is not its native file format. For interest, its exported SVGs look like the following:
It has a "Document" group which allows for setting coordinate system transform and origin. Xara uses a origin-is-bottom-left and Y-is-up coordinate system. "Spread" is the equivalent of a page, but also covers the concept of a two-page spread. Then it has groups for each layer. Layer names are stored in the The above seems to be the extent of the editor metadata that Xara includes with exported SVG files. Note the bug in that this results in an invalid |
Thanks for the data @jarek-foksa and @BigBadaboom. @nikosandronikos Yes, this proposal is only about standardizing existing behavior, not introducing any new functionality. I intentionally started a new thread because there were too many different requests in the old one. I still believe that the best way to make a "group" of elements that move together across different rendering layers is to use a CSS class. |
@AmeliaBR Are you suggesting that Illustrator, Photoshop, Affinity Designer, Inkscape, Xara, CACANi, Adobe Animate CC, etc. should implement a CSS interpreter to import and export SVG files with CSS defined classes for the layers? I don't think that will happen. My company for example is not going to write a CSS interpreter, the development is too expensive. Adding one new entity to SVG is much easier instead, and I think that all applications developers are going to prefer this route. CSS is too broad in scope for this to be practical. SVG as a graphic format should be kept independent from a web specific language like CSS. Also using CSS classes to define layers is going to get us back to square one: there is no standard way to do that. We need to introduce something standard, an entity called Layer or z-index that can be safely used to save layers informations and to animate them. Layers are very important for artists, and I'm sure that there will be a great positive and enthusiastic reaction if this feature would be announced for SVG, helping boosting the popularity of SVG. |
No @Emasoft, I'm not suggesting that. As far as I know, none of these programs support "groups" that cross multiple layers. (If I'm wrong, please add an example in issue #62.) Therefore, they can use |
@AmeliaBR I can tell you that I worked with countless artists desperate because of vector tools lacking the option to define groups across layers. You should have never worked with graphic artists and designers to think that this is a non issue. All the graphicians I know uses tricks to get this feature anyway. Here is an example: http://www.designgeek.com/group-across-layers-illustrator-0 |
What you are calling z-index is a What you're calling "groups" is the Image editors that want to interoperate with SVG on the web should indeed implement basic CSS functionality. It's not difficult (speaking as someone who has worked on such things). This doesn't need to be any more complicated than an informal standard defining some class-name pattern that is recognized cross-editor as defining "groups". If these are not sufficient, please stop trying to suggest new solutions. Instead, please list the problems you're having, the things you are unable to do with the current functionality. That way we can tell what actually needs to be done, and see if some of your problems are already solved. At the moment, we have to try and divine what you're actually asking for by sifting through your proposed solutions. For example, you keep suggesting adding a "layer" concept that is exactly the |
@tabatkins You may have missed all the examples in the other discussion. But you ask for a practical problem to solve. Ok. Here is my problem. I'm developing an SVG animation application, and I need to save an SVG file that preserves both Layers and groups animations. Groups are defined across layers in my editor, because they are objects with "depth". I cannot flatten a group to put it in a layer, because the group is composed of objects animated that need to be on different layers. So to make animations working, I need to animate layers independently from groups. You can say that what I need are overlapping groups, where the same object can belong at the same time to two different groups, one of which I call "layer" and the other "g". So I need:
This is MY problem, if you want to call it in this way. But it is really the problem of artists and developers using SVG to make and animate something more complex than web icons... |
After some more research, it looks like editors expose some or all of the following layer properties via UI:
Visibility, opacity, editability, blend mode, layer effects and mask are covered by coresponding CSS properties, namely @Emasoft pointed out that the Photoshop layer effects are applied to the layer area rather than the layer contents, thus making it hard to write a proper SVG exporter. I believe the proper solution to this problem should be worked out in the Filter Effects spec (if it's not solved already). The layer name (label) is problematic. I initially thought that SVG It appears to me that the only SVG features preventing authoring tools from generating interoperable layers are a standard way to mark a group as a layer group and a way to assign a human-readable label that won't get picked by accessibility technologies. Perhaps a |
@Emasoft No, I definitely read the previous thread, and this current one. I'm still not getting quite what you're asking for, tho - you continually say it's obvious that I and Amelie aren't Photoshop experts, but then gloss over the details of what you're actually asking for. What do you mean by "groups animations"? What, specifically, does that do? Does it mean that all the elements are transformed together? Or something else? As I keep saying, the concept of "layer" that image editors expose is exactly what SVG's What I'm trying to understand is precisely what this other concept you keep referring to is, and what it lets you do that can't achieve with current SVG/CSS. |
@jarek-foksa Could you elaborate more on "Photoshop layer effects are applied to the layer area rather than the layer contents"? Perhaps photoshop layers need to be represented as nested If nested SVG are required to capture all the features of Photoshop layers, then we would want to make sure that layer-related attributes may apply to (FYI, implementations are currently buggy with userSpaceOnUse features and nested SVG. For best support, you'll need to define the |
@tabatkins Let me explain the problem using the illustration above. As you can see there are two groups defined, with 4 objects each: In the current specifications of the SVG format, an object can belong to ONLY ONE GROUP. Suppose I need to order the elements of those groups according to their z order. I need to assign those to 4 layers as follows: So I can create an animation to TRANSLATE VERTICALLY all elements belonging to layer 4 up and down (a vertical oscillation) and, at the same time, to translate the group 1 HORIZONTALLY at a different speed or in a different direction than group 2. In other words I need to do this (pseudocode): The same problem appears when I try, for example, to animate the opacity of the Layer 1: TWEEN OPACITY LAYER 1 from 0 to 50% But I cannot do this, because SVG currently does not allow an element to belong to more than one group. So I need another entity, called Layer, that is independent from groups, and with that I a can assign elements in this way: A belongs to LAYER 1 and GROUP 1 So when I TRANSLATE the GROUP 1, I do not need to worry about the elements going ABOVE or BELOW some other elements they encounter in the translation in the wrong way, because all objects composing the group have their own z-order defined by the layers they belong to. So I can, for example, move all the leaves of a tree together as a group, and they will behave correctly with the leaves in front passing above the branches, and the leaves behind passing below the branches. This is how the z-index feature works, so I'm not asking for something new. The only thing missing from the z-index is the possibility to treat all elements with the same z-index as a single group, so I can define attributes, effects and animations to all the elements belonging to it. I hope that this time my explanation is more clear. |
You fundamentally cannot have elements belonging to >1 group, for certain definitions of "group". If the "group" allows group opacity/filtering/etc, elements must have a 1:1 relationship with them. (Nesting obeys this, too - an element in a sub-group is only a member of that subgroup; the subgroup itself is a member of the larger parent group.) This is not a limitation of SVG, it's a fundamental limitation in the definition of several of these "group operations" that can't be relaxed. This is the definition of "group" that the If you want some other conception of "group" that elements can also belong to (or can belong to multiple of), you need some weaker definition that excludes a number of operations. It appears that you're thinking of some sort of "transform group", where you can apply a translate to all of the elements at once, or rotate them all together, etc. This happens to be possible! As long as all the elements share an identical transform-origin, they can be independently 2d-transformed, and the result is indistinguishable from a "group transform". (I think this is true for skews; I know it works for translate/rotate/scale.) Right now this can be done with the notion of "group" defined by Selectors; the only difficulty is getting them all to have the same transform-origin, which has to be done manually and can potentially be pretty painful to keep consistent. It might be worthwhile to add something to make this work more easily! Like, maybe we can have a "transform-group" property that takes a name, and the first element in DOM order in that group defines the transform-origin for all of them (that is, it's 'transform-origin' property defines a point, and all the rest in the group automatically compute their 'transform-origin' properties to correspond to the same screen-space point). Would this be sufficient? Is there anything about transforms that we're missing? Is there anything else captured by some notion of "group" that we might be able to address? |
@tabatkins I need a standard solution, and this mean to create a new standard semantic for a new abstraction. Of course you can do all I said animating separately every object with selectors, but it will be unpractical and bloated. This is why groups were invented, as any other abstraction since when we invented programming languages instead of coding in binary. Of course you can program in binary code every thing, but you need the abstraction of programming languages to make possible for people to use a set of standard and shared semantical elements. This is why you can treat the problem in any way under the hood, but I need to save an SVG file with a layering system that any other app can understand. And to do this we need to add a new definition of layers, that looks and behaves like this one I proposed above: #68 (comment) |
@AmeliaBR I'm not a Photoshop user, but from my understanding of what was said in the previous thread, Photoshop allows effects such as inner glow to be applied directly to layers (i.e. first render all object inside the layer, then apply the filter on the result) rather than to objects contained by the layer (i.e. render the first object, then apply the filter to the first result, render the second object, apply filter to the second result, ...). I might be getting this totally wrong though. |
@Emasoft I can assure you that we are not going to go out of our way to define something in "pure" SVG that can already be accomplished in CSS, so it's not very fruitful to continue asking for that. (We generally dislike having multiple ways to accomplish the same thing - it causes code bloat and confusion for authors. It's only worthwhile if there's something that's really common and also tricky to accomplish with the existing tools - for example, we have the 'opacity' property, even though you can accomplish the exact same thing by writing filters.) All I'm asking for is to confirm whether or not my distillation of your request is correct and complete. @jarek-foksa Ah, kk, that's exactly what (This is why it's important to distinguish between what we might call "strong" groups - the |
@tabatkins Right, I have just tried applying filters to "layer groups" in Photoshop and they seem to work exactly as SVG filters applied on |
@tabatkins So you are going to define layers in a standard way using CSS? This may seem a better solution to you, but for me and for all others developers this means that to implement layers according to the standard we should develop a full CSS interpreter on top of our existing SVG interpreter. In other words, you are asking developers of graphic tools to invest money and time on something bloated like CSS, while with adding a single new entity in the current SVG interpreters they could have solved this in a week? You says that you don't like choices that forces the devs to bloat and duplicate code. Ok. Neither us. This is why we don't intend to write an additional CSS interpreter when the current SVG standard is already complete of all the features we need to save vector images. And I suspect that Adobe, Serif, Xara, and all the other developers are going to find it unconvienient too. You are making SVG increasingly a format divided in two: part XML and part CSS. This is forcing developers to do twice the work and manage twice the complexity, this cannot continue indefinitely. A standard format like SVG is supposed to simplify things, not to make them much more complicated. You can't keep your foot in two shoes for long. At some point the svgWG will be forced to choose between the two. So it would be better for developers like us to work on the XML part of SVG for now, that works just fine, while waiting the other shoe to drop. |
Once again, the You are asking for something different than layers, and you're not making it easy to figure out exactly what it is you're asking for. Writing out desired solutions is usually not helpful, because we need to evaluate them against what already exists, and divine what new functionality you're actually asking for, if any. So, once again, is what I said about "transform groups" above correct and complete? Did I make a mistake in distilling your requirements? Did I miss something? I'm not going to get into an argument about whether to duplicate CSS functionality into "pure" SVG. It's not happening, except perhaps for special-cases where it really helps (and those seem pretty rare). SVG is primarily focused on being a web-based image format, and that's not going to change. |
@tabatkins Yes it is correct. Layers should transform and get effects exactly like groups. With the difference that if I assign an element to a Layer, it should NOT be removed from its group, and viceversa. |
@Emasoft This is getting a bit off-topic, but SVG would be dead-end by now if the efforts to integrate it with other Web Platform technologies such as HTML 5 and CSS didn't happen. Some prominent Google developers were very clear about it: https://infrequently.org/2011/09/things-the-w3c-should-stop-doing/ Apple is very bullish on the CSS-everywhere concept as well, though I'm not saying this is a good direction. |
Ok, so that's not what I proposed. I talked about a "transform group", whose sole effect was to let multiple elements share the same transform origin in an easy way, so you could apply transforms to them separately and still have them act like they were transformed in a layer. This only works for 2d transforms, or 3d transforms if all the elements are all in the same 3d stacking context. (Note that a number of things, like applying a filter to a But you're saying "get effects exactly like groups". What "effects" do you mean, besides transforms? |
@jarek-foksa The trouble with the approach described in the article you linked is that is miopic. What google does not understand is that you cannot fence the web like an independent world. The web development is not using XML, yes, but it depends on a world outside of artists, designers, graphic applications, that does use XML and many other standards to work. The web is not an island. If you want it to grow and to improve, you need to ensure the presence of a supply road from the world of artists and graphicians. And such supply road is made of common standards like SVG. This is the reason because the web waited 20 years to wake up and discover vector graphics, while in the mean time SVG was becoming popular with videogame creators, animators and studios and was being used to make the graphics of blockbusters anime and videogames made in singapore and tokyo. If you don't wake up and start to see how it is all connected, you are going to create a web where the graphics is made not by artists but only by css programmers. And that, I assure you, is not gonna make the web a beautiful place. |
@tabatkins All standard effects. Drop shadow, glow, blur, emboss, satin, etc. For example those are the standard ones that Photoshop uses as layer blending effects: Drop Shadow Inner Shadow Outer Glow and Inner Glow Bevel and Emboss Satin Gradient and Pattern Overlay Mask Stroke Alpha Channel Mask Image You should be able to not lose such set of informations when you save in SVG from Photoshop, and preserve it when loading the same SVG file in Affinity Designer or Inkscape for example. Layers should be restored with all their effects and parameters intact. EDIT: Also blend mode and opacity, of course. |
Okay, again, those are all layer effects. In SVG, You're claiming we need some new concept that represents a group of elements that live in different layers, and allows some sort of shared effect. So far, you've provided the example of elements "sharing" in a transform. What other effects do you think that current image editors provide for layer-crossing groups of elements? |
Just re-iterating the point that @tabatkins made about objects not being able to be a member of more than one group, since I think this is what you are asking for: Groups and layers as a separate entity, both having rendering controls such as opacity, mix-blend-mode, etc. For an example of why this isn't possible, consider the following case:
Here you want to insert the cyan rect in between the red and blue rects. This is why z-index requires the concept of a 'stacking context' to allow it to work. You cannot arbitrarily insert elements just anywhere in the document. I think the correct way to do what you're asking is:
|
@tabatkins Nothing to add. As I said, layers are just like groups, their only differences are:
|
@nikosandronikos I agree on the use of z-index. That is exactly the way I suggested above. |
No, once again, layers are not "just like" groups. Layers are the You are not talking about layers. You are talking about something else that you're calling "groups". These are not the What, precisely, do you mean by the term "group" here? As in, what precise abilities do you gain by putting things into "groups"? |
@tabatkins The ability to being orthogonal to groups. That is the most important feature. Also for the reasons Nikos just remembered: as the z-index the layers need a special stacking context, that should be prioritized before the groups hierarchy. In other words, branches belonging to the same layer should not be rendered only in the order or global hierarchy determined by their parent node, but first they should be ordered accordingly with the index of the layer they belongs to and then, for layer indexes being equal, according to their position in the global hierarchy of the document. |
It may be a lost cause at this point, but I created this issue to discuss a very specific, actionable item: standardize the way SVG authoring tools currently implement layers as groups with extra attributes. There's already a thread discussing layer filter effects and the differences between layers and groups, in Issue #62. Copying content from that thread to this one only serves to drown out other information, not add to the argument. You can always link to your previous content if you need to. The datestamp on the comment is a permalink to it. |
I found a solution to this. To make layers and groups independent we can just expand on the weak-groups concept proposed by @tabatkins . ISSUE 1 : TO STANDARDIZE LAYERS ISSUE 2 : TO MAKE POSSIBLE TO APPLY PROPERTIES AND ANIMATIONS TO MANY SVG ELEMENTS AT ONCE ACROSS LAYERS USING A SINGLE REFERENCE ID
This would solve the problem of my illustration above. In fact if you just replace in that illustration the words "LAYER" with "GROUP", and the words "GROUP" with "SET", you'll have an exact rappresentation of my new proposal. This answer to my requisite of having groups across layers. Only this time instead of Groups across Layers we have SETs across Layers/Groups. Notice that SETs are different from CSS classes.
|
If all you're looking for is the ability to apply styles to multiple elements at once, we already have multiple ways to do that. Using a
No, they aren't. They're exactly functionally identical. In particular, every single property you listed for "sets" is shared by using a class. |
@tabatkins I don't understand why you closed this. Even if you use css classes to solve issue 2, you still have to solve issue 1, an issue of paramount importance. |
@tabatkins I'm not sure whether you closed intentionally or by accident, but the main goal of this particular issue still remains open to discussion. @Emasoft Everything Tab said is correct. Your "sets" are essentially CSS classes, except that there are some XML-based functions (such as animation elements) which still require elements to be identified by ID references instead of by generic CSS selectors (including classes). Please try to keep issues on topic. If you have new proposals or issues, open a new issue. The Working Group hoped that moving to GitHub would make it easier to keep track of discussion and to separate active issues from other debates. So far, we have not been editing or deleting off-topic comments, but that is an option we may need to consider. |
@AmeliaBR I agree. In light of the separation between the two issues, I will open a separate issue about my SET proposal. This thread about the standardization of layers metadata can continue on the right track indicated by Amelia. |
Ah, sorry about that Amelia, I was closing it as Emasoft's issue was already solved and didn't need to be addressed. The topic you originally started this on (standardized metadata for Wanna clean up this thread and delete some of the off-topic posts (including this one)? I'll leave it to you to do so, as this thread was started by you. |
The fact that it seems that every SVG creation program has implemented the concept of "layer" demonstrates a strong interest in having a standard way of denoting layers (at least among users). @AmeliaBR Do you have a proposed syntax? I'm not sure if this belongs in the SVG 2 spec or a separate "Best practices" spec. |
@Tavmjong For backwards compatibility, I think a documentation à la "best-practices" might be preferable. We could suggest the attribute @AmeliaBR I'd like to understand the motivation more though. Adobe Illustrator uses SVG primarily for export to web/print for instance. If someone wants to pick up the work then as part of a new W3C Community Group. |
Adding CorelDraw to that list: <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg">
<g id="Layer_x0020_1"><metadata id="CorelCorpID_0Corel-Layer"/></g>
<g id="Layer_x0020_2"><metadata id="CorelCorpID_1Corel-Layer"/></g>
</svg> |
Re: the illustration, |
Many graphical editing programs use the concept of "layers" of content that are distinct from groups. Although the final rendering is the same as if the layer was a group, the behavior within the editor is quite different.
Software currently use custom-namespaced attributes on an SVG
<g>
element to preserve layer-related metadata. For example, Inkscape usesinkscape:groupmode="layer"
andinkscape:label="label given by author"
. But because this is not standard, SVG exported from one program and imported into another loses the layer structure. Since there is a standard concept used by multiple programs, it makes sense to pursue a standard set of attributes for conveying this structure.See past discussion on this and related topics in Issue #62.
Some issues that need to be resolved prior to drafting a spec:
<g>
in exported SVG files, or do some use nested<svg>
elements?And of course, prior to drafting a spec, we'll need some commitments from authoring tool developers that this is something they'd be interested in implementing. If any of those developers want to volunteer to draft & edit the spec, that would be even better.
The text was updated successfully, but these errors were encountered: