Native profile of SVG

[litherum]

The SVG Charter lists Native SVG as a deliverable for this working group.

This deliverable (once it exists) describes a profile of SVG, and its associated file format, that is suitable for native apps. In particular, it's designed to be a wire format, similar to jpeg or png, designed to represent 2D images. The idea is to be a strict subset of the existing SVG specification, and is designed to be written and read by automated systems instead of humans.

Here is an initial draft of the specification. It is provided as a delta spec from SVG 1.1, where the section listing matches the sections in the SVG 1.1 spec.

The document is named "SVG Static" as this name fits the design principles well.

We'd love to hear any and all thoughts and feedback about this initial draft!

index.html.zip

[AmeliaBR]

Hi Myles,

I have many thoughts, but I think the first priority should be to get this hosted in the repo properly.

I'm assuming the HTML file you attached is the result of rendering Bikeshed source code, as previously discussed. Have you talked with @tabatkins or @heycam about getting svgwg.org set up to build & host bikeshed specs? I could probably eventually figure out the necessary tooling scripts myself, but I'd be happy to let anyone else take the lead & it's possible some work has been done on it previously.

Regardless, I think we could probably add the .bs file to the repo even if we don't yet have a host URL for the built draft. Probably in specs/svg-native/.

[dirkschulze]

@litherum @AmeliaBR I uploaded the HTML file to specs/svg-native/ and cherry-picked the commit to gh-pages.

The draft proposal can now be reached with the link: http://w3c.github.io/svgwg/specs/svg-native/index.html

Hopefully that simplifies the review process.

Edit: Of course, this is just a temporary solution.

[dirkschulze]

My initial review of the document:

General comments

That is a really great write up of the proposal! Thanks a lot @Litherium!

• I am used to SVG Native already so the new name is a litte confusing. I personally prefer the old name but also do see why you think a different name could be more descriptive.
• I personally would prefer if the document is not a diff-spec but rather builds on top of SVG (regardless of the version) with a mixture of a black and white list approach. SVG but with the following limitations. This would make the spec more readable IMO.
• Maybe this is in one of the deleted sections but I don't see anything about the <use> or <symbol> elements. Do we support them? Do restrictions apply to them?
• I'd propose that elements that get referenced should be specified before they get referenced the first time. If they are not, the behavior is unspecified. This makes it easier for SVG viewers that render while they parse. Otherwise the document must be parsed first and it would be required to have an internal DOM. Example:
  • <rect fill="url(#gradient)/><linearGradient id="gradient"/> unspecified.
  • <linearGradient id="gradient"/><rect fill="url(#gradient)/> works.

Scope of the spec

I think we already agreed that SVG Native will be a strict subset of SVG 1.1 and SVG 2.0. Based on this discussion I think the following restrictions are to restric:

• SVG Native should not require a viewer/renderer to a more restric rendering engine. The spec rather should put up requirements for a compliant SVG Native document! As a result, any SVG viewer today would be compatible with SVG Native.
• SVG Native is an XML format. XML formats are designed to be part of other documents. Requiring SVG Native to be stand-alone doesn't make sense to me.
• I do not think that baseAttribute should be required or is actually needed. We define a subset of SVG. If the document is not following the subset, it is not SVG Native. It rather hurts the standard since it falls back to an older era. It also makes all SVGs from SVG OT invalid to SVG Native. I do not think that this is a good idea.
• Don't use "forbidden". If SVG Native is required as input, all not supported elements, attributes or CSS properties will be ignored.
• What do you mean with "reference depth"? How many further documents can be loaded? I think this should be equal to 0.
• XML entities and CDATA in general are not allowed in SVG OT fonts. I strongy oppose to allow them for SVG Native.
• We should explicitly disallow (you have done most of the listed items):
  • Interaction
  • Scripting
  • Events
  • Hit-testing
  • Animation

image element

• SVG OT only allows PNGs as raster images. We should not be less restrictive than the current SVG OT spec or we won't reach one of the goals of the spec.

styling

• The style attribute should be allowed. It is in SVG OT and we also agreed that we would support it earlier. Did you mean class maybe? I'd be opposed to remove support for it.
• Even w/o style attribute, the fill* and stroke* properties will stay inherited properties. (In case this was a reason for removing style.)
• IMO var() is essential for SVG Native. That allows theming support that we need in SVG OT and applications! But we should add restirctions:
  • Only on the fill, stroke, stop-color, color properties.
  • Only valid Color values excluding new color values introduced with CSS3 Colors or later. So restricted to: color keywords (but system colors), HEX strings (with 3 or 6 values), rgb() and (possibly) var().
• Why disallowing to set the color CSS property? How would you be able to use currentColor if you can not set color?
• I think we should explicitly list supported properties. I propose supporting the following properties (presentation attributes):
  • clip-path
  • clip-rule
  • color
  • display (values other than none ignored)
  • fill
  • fill-opacity
  • fill-rule
  • opacity
  • stroke
  • stroke-dasharray
  • stroke-dashoffset
  • stroke-linecap
  • stroke-linejoin
  • stroke-miterlimit
  • stroke-opacity
  • stroke-width
  • stop-color
  • stop-opacity
  • visibility (values other than visible, hidden ignored)

basic shapes/paths

• To make sure: We support all path commands and all shapes of SVG?

Text

Not sure if it is enough to say that the chapter was deleted. I suppose this depends how the spec itself sees itself.

Painting

• Why is display forbidden? It is not in SVG OT and implemented on the Windows platform.

Gradients

• The default if gradientUnits is not set is objectBoundingBox. I think we rather want to disallow units other than userSpaceOnUse and make the behavior of missing gradientUnits unspecified. (It would be invalid SVG Native anyway.)
• I think supporting xlink:href is straight forward w/o objectBoundingBox support and would strongly advocate leaving it in! Otherwise, authors can not share color stops between multiple gradients. W/o objectBoundingBox this would be a major drawback and blow-up SVG files.

Clipping

I most definitely support the approach you take here!

• We should not disallow clipPathUnits but rather only support userSpaceOnUse. Same rationality as for gradients above. Fortunately, userSpaceOnUse is the default for clipPathUnits!
• Remove overflow. No current SVG viewer supports it reliably anyway.
• Do we want to to restrict the children to only be basic shapes? <use> still supported?

Metadata

At Adobe we would like to keep metadata for the purpose of XMP (or a future alternative). Viewers should ignore it and its child elements.

[jarek-foksa]

Another name idea is "Encapsulated SVG" (ESVG), in a similar fashion to "Encapsulated PostScript" (EPS). The file extension could be .esvg.

Only the following units are supported: (unitless), px, pt, pc, mm, cm, in

I would go even further and restrict the allowed units to (unitless) and px. The only exception would be the "width" and "height" attributes on the root <svg> element which could be defined with actual physical units.

The style element and the style attribute are forbidden.

The "style" attribute should be allowed since the SVG 2 spec states that "(...) in the future, any new properties that apply to SVG content will not gain presentation attributes. Therefore, authors are suggested to use styling properties, either through inline ‘style’ properties or style sheets, rather than presentation attributes, for styling SVG content."

IMO var() is essential for SVG Native. That allows theming support that we need in SVG OT and applications!

Yeah, I think it's worth checking which features are supported by Android's VectorDrawable file format as it had very similar design goals (security, performance, ubiquity). VectorDrawable does support basic theming and even animations (which are used extensively by modern native UIs).

I'd propose that elements that get referenced should be specified before they get referenced the first time. If they are not, the behavior is unspecified. This makes it easier for SVG viewers that render while they parse. Otherwise the document must be parsed first and it would be required to have an internal DOM.

I would additionally require all referenced elements to be placed inside the <defs> element which is a child of the root <svg> element (rather than scattered around the document).

[frivoal]

As it has been renamed from "Native" to "Static", it looks like the document was run through a search and replace that was too aggressive. "Static" is a better word to talk about the svg profile, but "static apps" isn't better than "native apps", and actually downright confusing.

[BigBadaboom]

Just wanted to point out that there is already a precedent name for a cut-down version of the spec with a subset of features. The SVG 1.2 Tiny spec was intended for devices with limited processing and memory resources. It seems a comparable purpose to me.

So why not "SVG 2.0 Tiny"?

[svgeesus]

So why not "SVG 2.0 Tiny"?

Probably because Tiny 1.1 and Tiny 1.2 had animation, for example (and text) while this is a more aggressive subset and does not.

[litherum]

The WG accepted the initial editor's draft. I tried to migrate everyone's thoughts to other issues on the issue tracker, so I think this issue can be closed.

If I missed someone's comments, please feel free to either 1) re-open this issue so I can migrate it, or 2) just open an issue directly.

Thanks!

[heycam]

Sorry for the delay in setting up the build scripts, I was on PTO. Pushing to the repository should now automatically build the svg-native spec with Bikeshed.

[AmeliaBR]

And there it is: https://svgwg.org/specs/svg-native/

Thanks @heycam & everyone else who helped figure out the logistics!