Re: [svgwg] Agenda conf call 15-April-2019

Initial thoughts on SVG Static, from an initial scan ahead of the call.

(I will raise any that remain unresolved after the call, as individual 
GH issues)

IN general:
Some notes seem to be normative here. So don't call them notes. As the 
bikeshed-included appendix says, "Note, this is an informative note.".


"SVG Static is a subset of SVG 1.1"
1.1 not 2.0? Needs xlink:href etc?
but later "Note: This spec will likely be rebased on [SVG2] in the near 
future."

"CSS (among others)"
probably means that it removes CSS selectors, CSS stylesheets, and 
cascading. CSS properties and inheritance are still used.

"disregarded"
Clarify. Treated as if it had not occurred.

"should be interpreted as SVG proper"
if possible, ie if there is a choice of SVG Full or SVG Static 
renderers. Needs to say what a Static-only renderer does.

"This matches other static image formats such as [PNG]. A Web browser 
should implement SVG Static by linking with the system’s SVG Static 
facilities. This matches the implementation of other static image formats."
needs to hook up with SVG processing modes.
https://svgwg.org/svg2-draft/conform.html#processing-modes

"The MIME type for SVG Static is image/svgstatic+xml"
Needs a MIME registration appendix

"XSL Processing is forbidden."
Probably means XSL PIs must not be processed, or XSL-FO is not supported..
You can't forbid people using a variety of tools (from text editors to 
XSLT) on any file. You can say that such processing does not get 
triggered automatically.

"XML Entities and CDATA sections may be present."
I wish the "no DTD" subset of XML had been formally defined.
Do we really want to be testing for correct XML entity expansion (which 
is itself a security risk) in SVG Static content?

"All other image formats must be ignored"
Good.

Should therefore say JPEG/JFIF (not, for example, TIFF with JPEG 
encoding, or JPEG2000, etc etc).

"The style element and the style attribute are forbidden."
Should probably clarify that SVG presentational attributes are still 
allowed.

" For example, the [OPENTYPE] spec might allow env() or var() in color 
fonts to support font color palettes."
I'm wondering whether we should instead push for all SVG in OT to use 
either hard-coded colors or to use palette entries, instead of 
inheriting in custom properties by some as-yet unclear mechanism.

"
pt

pc
"
Since these depend on font metrics, check this spec clarifies what to do 
when these are not set anywhere.

"The pathLength attribute on the path element is forbidden."
Maybe a good idea but not sure. It was added in the SVG Tiny 1.1 
timeframe for better rendering consistency on limited devices.

"10. Text

Entire chapter is deleted."

I can see why, and this is probably the bigest saving in implementation 
complexity of the entire subset. Still, there will likely be a11y 
pushback. Needs a good acessibility story. The fact that there is no 
interactivity and thus, any text if present could not be selected, 
navigated to or read, is part of that story.

"Delete section 11.6.2 The marker element.
Yes! I wish SVG2 did that as well :)

"support of the color property to change currentColor is not supported"
Needs to clarify what that means, so it is testable.

"This specification will likely adopt [SVG2]'s syntax for specifying 
colors outside of sRGB.
Which will also include a way to interpolate outside of sRGB, 
contradicting the earlier assertion.

"Because the engine must ignore document constructs that aren’t included 
in this specification, it means metadata is ignored. This may be what 
the author intends."
Maybe. Static raster formats  like PNG and JPEG/JFIF allow metadata 
(ITPC and Exif) for copyright, etc. These also have no effect on 
rendering (mostly: exif rotation is a counter-example).

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

Received on Monday, 15 April 2019 17:36:31 UTC