W3C home > Mailing lists > Public > www-svg@w3.org > April 2016

Re: version attribute of svg element

From: Sairus Patel <sppatel@adobe.com>
Date: Sat, 9 Apr 2016 00:45:52 +0000
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <47417B4C-0957-4C3D-A03E-E941DAE53E76@adobe.com>
I appreciate the responses. It seems there isn’t agreement among the responders thus far whether the doc author or viewer should determine what a doc looks like.

Firefox — but not other browsers — honors the transform attribute in an svg element with a version=“1.1” attribute, even though transform in the svg element is a feature of only 2, not 1.1 or 1.2. It has been suggested at https://lists.w3.org/Archives/Public/public-svgopentype/2016Mar/0008.html to log a bug against Firefox, but I’m not convinced anyone has a solid case to do so.

In any case, and more concretely, in a couple of days I’ll be proposing for https://www.microsoft.com/typography/otspec/svg.htm to replace:


>>
SVG documents MUST be interpreted according to at least version 1.1 of the SVG specification. Font engines are not prohibited from interpreting SVG documents according to newer versions of SVG, such as SVG 2, and indeed are encouraged to.
<<

by:

>>
The font engine must support at least version 1.1 of the SVG specification (exceptions are noted in the section on glyph rendering restrictions). The version attribute in the <svg> element is present in the SVG 1.1 and 1.2 specifications, but not in SVG 2. Thus, the SVG document may not always have a version attribute specified. Given this approach to versioning in SVG, and given that not all implementations may support all of SVG (whether 1.1 or 2), font designers should restrict their SVG, as a practical matter, to whatever is supported by SVG-in-OT implementations they care about. Targeting the capabilities of SVG 1.1 would be the approach most likely to result in cross-implementation consistency. 
<<


I think this language offers practical guidance to font designers who are (understandably) concerned about predictable rendering, without trying to clarify the “what does SVG version mean” issue or pass judgement on what some might see as SVG’s “tag soup” approach.

Your feedback is welcome.

I’ll also be adding some actual SVG examples, such as:

<svg id="glyph7" version="1.1" xmlns="http://www.w3.org/2000/svg">
  <defs>
    <linearGradient id="grad" x1="0%" y1="0%" x2="0%" y2="100%">
      <stop offset="0%" stop-color="darkblue" stop-opacity="1" />
      <stop offset="100%" stop-color="#00aab3" stop-opacity="1" />
    </linearGradient>
  </defs>
  <rect x="100" y="-430" width="200" height="430" fill="url(#grad)" />
  <rect x="100" y="-635" width="200" height="135" fill="darkblue" />
</svg>


I’ll probably keep the version attribute in there, but I’ve stripped out the other stuff, e.g. DTD, that doesn’t seem to be required.

Sairus

Received on Saturday, 9 April 2016 00:46:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:04 UTC