export without style=, xlink:href on gradients
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Inkscape |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
Using the style attribute to serialize SVG is a bad idea: using
attributes instead is far better. While even for Full viewers it has
the downside of being more painful to script, the biggest problem
is that it gratuitously makes the content unusable on SVG Tiny
implementations, even though the rest of the content may be
perfectly Tiny-renderable. It's a pity that one can't use Inkscape to
create mobile content simply because Inkscape picked the wrong
serialization!
There is no good reason to use the style attribute, and in fact an
upcoming Authoring Guidelines document from the SVG WG is
likely to advise strongly against its use. I wouldn't be surprised if it
were deprecated in a future version of SVG (eg 1.3).
Likewise, xlink:href on gradients has very small advantages
(though a little more than the style attribute which has none) but it
similarly makes content that could easily be valid Tiny 1.2 (or even
1.1+, the intermediate version used by some vendors) unusable on
those devices. Tiny 1.2 has most of gradients, but not xlink:href.
Similarly, the Authoring Guidelines document will likely
recommend against it (especially as it was introduced before
gradients changed to become what they are now, and was created
for a use case that is no longer relevant) and it might be
deprecated as well.
Thanks for the cool stuff!
| Buliabyak-users (buliabyak-users) wrote | #1 |
| Buliabyak-users (buliabyak-users) wrote | #2 |
| Changed in inkscape: | |
| importance: | Undecided → Wishlist |
| status: | New → Confirmed |
| tags: |
added: gradient styles svg removed: saving |
| jazzynico (jazzynico) wrote | #3 |
I agree on style attribute, but hreffing gradients has a
very practical use in Inkscape. It is the only way to share
gradients between objects. E.g. if two objects share the
same color transition for gradient but use different vector
coordinates, you cannot have them use the same gradient.
Doing so will prevent gradient from transforming in sync
when an object is transformed. Using bbox gradient
coordinates (which seem to have been invented for keeping
gradient in sync automatically) is a stupid idea, because
bbox changes unpredictably for rotations and shears.
Therefore we always use userSpaceOnUse coordinates and apply
the same transformation matrix to both the object and its
gradient vector. And this is why we need a two-step gradient
definition: the gradient referenced by the object (called
its "private") holds only the vector coords and hrefs the
actual gradient with stops, which may be shared by any
number of objects via their privates.
Though, of course, there's no reason not to provide an
export-to-Tiny command which would flatten the gradient href
chains and move style to CSS attributes. I therefore move
this to RFEs.