Re: [svgwg] Native profile of SVG (#657)

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.


-- 
GitHub Notification of comment by dirkschulze
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/657#issuecomment-482778343 using your GitHub account

Received on Saturday, 13 April 2019 05:33:53 UTC