search

w3c / svgwg

SVG Working Group specifications
Other
698 stars 132 forks source link

Develop a new standard for describing "layers" in SVG authoring tools #68

Open AmeliaBR opened 8 years ago

AmeliaBR commented 8 years ago

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 uses inkscape:groupmode="layer" and inkscape: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:

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.

BigBadaboom commented 8 years ago

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.

nikosandronikos commented 8 years ago

@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). Off the top of my head, it seems that if separate layers and animation groups are needed, the layers should be in the defs section, then the objects are pulled into animation groups via the use element.

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).

Emasoft commented 8 years ago

@AmeliaBR Thank you again for opening this issue after the long discussion in the other thread. For years I worked in a role of interface between graphics artists and programmers. I developed countless tools and converters to solve the issue of making the output of graphicians to pass through the technical limitations of various software platforms and standards. So I have a good understanding of what artists consider essential and what not. Grids, rulers and scales for examples are not essential. Layers instead are something you cannot leave, because professional artists "think" images in terms of layers. It is their main composition tool, like a grand map of the image that they are working on. Layers data cannot be "dropped" for publishing, because vector graphics is built to be rendered at maximum quality on every device, and that is true for all the blending effects between the layers. You cannot "flatten" a vector image like you do for butmaps. Those metadata are not there for decoration. They are there because they define the image as a multi layer document with very specific ways to compose those layers. Also SVG can be animated. And to animate a layer I need to have the layer as a real entity, not just some metadata that you can discard. If you toss out the metadata linked to the layers, you are not able to animate the image as the author intended. Layer needs to be first class citizens of the SVG format, not just attributes of the existing group element. Artists use groups in a very different way from layers. They cannot be forced to remove an element from a group just because it needs to be in the foreground layer. Groups define things, and the elements that compose those things. Layers instead are about z-ordering. Two things that are completely different for an artist, even if for a programmer such distinction can appear not evident and hard to grasp. Also groups have a big role in animations. They links elements that animates together. They define the hierarchy of such animations. And things on different animation groups can be at the same time on the same layer. It is useless to mix those two. It would complicate both the work of the application developers and of the artists. A clean separation of concerns is what works best.

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 (see: https://svgwg.org/svg2-draft/single-page.html#render-ZIndexProperty )

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 All the attributes that are animatable for groups, should be also animatable for z-index layers. The position attribute it is also animatable with the restriction of having only integers as values. For example a fog layer moving toward the observer can be moved as a layer from background to foreground passing trough all the other layers. But you can also decide to move an object from a layer to another. And each layer must have its unique position. No two layers can be at the same position at the same time. So we have this kinds of animations:

jarek-foksa commented 8 years ago

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>
BigBadaboom commented 8 years ago

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:

<svg>
 <defs>
 </defs>
 <g id="Document">
  <g id="Spread">
   <g id="Layer 1" display="none">
   </g>
   <g id="Layer 2">
   </g>
  </g>
 </g>
</svg>

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 id attribute. There is always at least one layer - called by default "Layer 1". Like many vector editors, Xara lets you toggle layer visibility and also whether the items on the layer are editable. The visibility setting gets reflected in exported SVGs using display="none" (if the layer is hidden). The layer's editability status is not reflected in exported SVGs.

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 id attribute due to illegal characters such as space. This may have been fixed in more recent versions. I use the older Xara Xtreme 4.

AmeliaBR commented 8 years ago

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.

Emasoft commented 8 years ago

@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.

AmeliaBR commented 8 years ago

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 <g> elements for both groups and layers. The idea of groups that cross layers was something you had brought up in the other thread, and is something unrelated to the basic need for layering and z-index control.

Emasoft commented 8 years ago

@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 But as I said, whoever introduced the z-index feature in the SVG2 specs, god bless him, already knew this, because that is exactly how z-index works. Z-index works across groups, and allows to manage svg layering without destroying group hierarchies. All we need to do is to formalize this, promote z-index to the status of entity, and add some common attributes to it. Why is this so difficult to do for the SvgWG? Is there a reason I'm missing here?

tabatkins commented 8 years ago

PROPOSED SPEC for an improved z-index

What you are calling z-index is a <g> element (+ the z-index property, which is defined to work on SVG elements now). It groups things together, allows them to be transformed together, filtered together, put into a particular z-plane together, etc. This is precisely what image editors call a "layer".

What you're calling "groups" is the class attribute. That lets you refer to disparate things all at once. You can't apply any "group operations", like transforms or filters, to them, but you can apply them to all the individuals in the group, and set a bunch of other properties all at once to all of them. (Or, if you want elements to belong to at most one "group", then a custom attribute containing the group name does the same thing.)

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 <g> element, which implies that you think the <g> element currently does something else. This is confusing to us! Since we actually already have layers, please list what it is about "groups" you care about and think is necessary, so we can see what we might want to add to the language. What do "groups" allow you to do, in Photoshop/etc?

Emasoft commented 8 years ago

@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". This is the illustration I made from the other thread: image

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...

jarek-foksa commented 8 years ago

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 visibility, opacity, pointer-events, mix-blend-mode, filter and clip-path / mask.

@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 <title> or <desc> elements could be used for that purpose, but now I'm not sure whether the layer name should be read by the screenreader or shown as a tooltip. I guess it might be the reason why there are no authoring tools using this approach, instead resorting to various hacks.

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 layer attribute that takes a human-readable layer name as a value would be enough? I would also add "Implementation notes" section outlining best practices for authoring tools so that they don't end up doing something silly like putting human-readable layer names into ID attributes as mentioned by @BigBadaboom.

tabatkins commented 8 years ago

@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 <g> element provides. It's what lets you set group opacity (all the objects paint together, then become partially transparent, rather than all becoming partially transparent and then overlapping visibly), do group filtering, etc.

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.

AmeliaBR commented 8 years ago

@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 <svg> (which have a defined width/height and x/y position distinct from their child content). The you could use a filter with userSpaceOnUse units to have it apply to the nested SVG region instead of to the bounding box created by child graphics.

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 <svg> as well as to <g>.

(FYI, implementations are currently buggy with userSpaceOnUse features and nested SVG. For best support, you'll need to define the <filter> as a child of the relevant <svg>. According to the spec, that shouldn't be required, but Firefox is the only major browser that implements it correctly.)

Emasoft commented 8 years ago

@tabatkins Let me explain the problem using the illustration above.

As you can see there are two groups defined, with 4 objects each: GROUP 1 : (A,C,E,G) GROUP 2 : (B,D,F,H)

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: LAYER 1 : (A,B) LAYER 2 : (C,D) LAYER 3 : (E,F) LAYER 4 : (G,H)

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): TWEEN TRANSFORM LAYER 4 from Y1 to Y2 and back TWEEN TRANSFORM GROUP 1 from X1 to X2 TWEEN TRANSFORM GROUP 2 from X3 to X4

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 B belongs to LAYER 1 and GROUP 2 ...etc

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.

tabatkins commented 8 years ago

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 <g> element represents.

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?

Emasoft commented 8 years ago

@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: https://github.com/w3c/svgwg/issues/68#issuecomment-196142990

jarek-foksa commented 8 years ago

@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.

tabatkins commented 8 years ago

@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 <g> does - it allows "group opacity", "group filtering", etc. In other words, they entire contents are rendered into a buffer, which is then opaqued/filtered/etc.

(This is why it's important to distinguish between what we might call "strong" groups - the <g> element - and "weak" groups - classes or attributes, that let you write a selector to apply properties to all of them at once. An element belong to exactly one "strong group", but can belong to as many "weak groups" as you want.)

jarek-foksa commented 8 years ago

@tabatkins Right, I have just tried applying filters to "layer groups" in Photoshop and they seem to work exactly as SVG filters applied on <g>. I'm sorry for introducing unnecessary confusion.

Emasoft commented 8 years ago

@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.

tabatkins commented 8 years ago

Once again, the <g> element exactly captures the "layers" concept from image editors.

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.

Emasoft commented 8 years ago

@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.

jarek-foksa commented 8 years ago

@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.

tabatkins commented 8 years ago

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 <g>, will "flatten" the layer's contents, so they're no longer sharing a 3d stacking context with their surrounding elements, so this is somewhat fragile.)

But you're saying "get effects exactly like groups". What "effects" do you mean, besides transforms?

Emasoft commented 8 years ago

@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.

Emasoft commented 8 years ago

@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 Adds a shadow that falls behind the contents on the layer.

Inner Shadow Adds a shadow that falls just inside the edges of the layer’s content, giving the layer a recessed appearance.

Outer Glow and Inner Glow Add glows that emanate from the outside or inside edges of the layer’s content.

Bevel and Emboss Add various combinations of highlights and shadows to a layer.

Satin Applies interior shading that creates a satiny finish.

Gradient and Pattern Overlay Mask Blend the layer’s content using a patterned or gradient overlay mask.

Stroke Outlines the object on the current layer using color, a gradient, or a pattern.

Alpha Channel Mask Image Blend the layer’s content using a custom 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.

tabatkins commented 8 years ago

Okay, again, those are all layer effects. In SVG, <g> represents a layer, and allows all of those effects.

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?

nikosandronikos commented 8 years ago

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:

<rect fill="cyan" layer="3" />
<rect fill="green"/>
<g isolation="isolate" transform="translate(20,20)">
  <rect fill="red" layer="2" />
  <rect fill="blue" layer="4" mix-blend-mode="multiply" />
</g>

Here you want to insert the cyan rect in between the red and blue rects. But the red and blue rects are in an isolated group. The result of rendering this group is already defined and is that the blue rect blends (using mulitply) with the red rect, the result is treated as one and is then blended with what is behind. Inserting the cyan rect in the middle breaks the definition of the isolated group.

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:

Emasoft commented 8 years ago

@tabatkins Nothing to add. As I said, layers are just like groups, their only differences are:

Emasoft commented 8 years ago

@nikosandronikos I agree on the use of z-index. That is exactly the way I suggested above. I do not agree on using standard CSS classes as a way to allow animations of Layers. Implementing a CSS interpreter above the existing SVG interpreter is too much to ask to developers of graphic tools. SVG should be self-contained and XML based to be used in the world of the graphic artists and their tools.

tabatkins commented 8 years ago

No, once again, layers are not "just like" groups. Layers are the <g> element. The Photoshop concept of "layer" is precisely and completely handled by <g>. (It only sorta handles z-ordering in SVG1.1, but SVG2 adds the z-index property, so we're completely good there.)

You are not talking about layers. You are talking about something else that you're calling "groups". These are not the <g> element; they can't be, because the <g> element represents layers, and you keep saying that "groups" is something orthogonal to layers.

What, precisely, do you mean by the term "group" here? As in, what precise abilities do you gain by putting things into "groups"?

Emasoft commented 8 years ago

@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. As for the term group, I mean "set". Layers and Groups are two overlapping sets of elements. Like this: image

AmeliaBR commented 8 years ago

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.

Emasoft commented 8 years ago

I found a solution to this. To make layers and groups independent we can just expand on the weak-groups concept proposed by @tabatkins . All we need is to separate the two issues:

ISSUE 1 : TO STANDARDIZE LAYERS Groups can be used as layers by adding a standard metadata specification for apps to use, as @AmeliaBR original proposed in opening this thread.

ISSUE 2 : TO MAKE POSSIBLE TO APPLY PROPERTIES AND ANIMATIONS TO MANY SVG ELEMENTS AT ONCE ACROSS LAYERS USING A SINGLE REFERENCE ID A new entity can be introduced in the SVG specifications, called SET. A SET is just a named set of svgelements. For example: SET id="Train" members="Car1, Car2, Car3, Car4, RestaurantCar, Locomotive, smokeTrailsGroup" Properties are:

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.

tabatkins commented 8 years ago

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 <g> to group them in the document is one. If they already exist in different <g>s, then applying a class or attribute to them and then using CSS to style them is the second.

Notice that SETs are different from CSS classes.

No, they aren't. They're exactly functionally identical. In particular, every single property you listed for "sets" is shared by using a class.

Emasoft commented 8 years ago

@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.

AmeliaBR commented 8 years ago

@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.

Emasoft commented 8 years ago

@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.

tabatkins commented 8 years ago

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 <g>-as-layer to help with interop across image editors) is of course still valid.

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.

Tavmjong commented 8 years ago

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.

dirkschulze commented 5 years ago

@Tavmjong For backwards compatibility, I think a documentation à la "best-practices" might be preferable. We could suggest the attribute data-groupmode with the attribute value layer and data-name for the label (Adobe Illustrator) for instance (similar to microformats).

@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.

speleo3 commented 4 years ago

@jarek-foksa wrote:

Below is the output I got from various vector graphics editors after exporting a document with two layers to SVG.

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>
wangyoutian commented 2 years ago
  • ave layers in SVG as independent entities from groups.
  • that such format should be standard, so that artists can use the files made with my editor in many different applications (video composition apps, videogames sdk, mobile apps frameworks, web apps, presentations apps, etc.).

This is MY problem, if you want to call it in this way. B

Re: the illustration, We can consider to define "layer" as a STYLE, as CSS "z-index" in HTML. In so doing, we can put elements from different groups into a same layer, and toggle their visibility altogether, and this doing is unobtrusive to current SVG practices. After all, "layered" display is a style, thus should be cared about by CSS; the "group" responsibility taken by "layer" in some software shall still be taken on by the "g" element. Or should we consider introducing a pseudo-element as layer?