version attribute of svg element

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

version attribute of svg element

Sairus Patel

Can the version attribute validly be absent in an SVG 1.1 document? Is your answer documented in the SVG spec anywhere?

I’m aware that https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/version says the attribute is “purely advisory and has no influence on rendering or processing.” Is this a way of saying that the attribute can validly be absent in an SVG 1.1 document?

I’m also aware that the attribute has been removed in SVG 2.

The context: We are crafting a few SVG doc examples for the SVG-in-OpenType specification. I’d like not to include the version attribute (smaller SVG docs are a good thing).

Thanks,
Sairus

Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Nikos Andronikos

> On 8 Apr 2016, at 9:36 AM, Sairus Patel <[hidden email]> wrote:
>
> re. https://www.w3.org/TR/SVG11/struct.html#SVGElementVersionAttribute
>
> Can the version attribute validly be absent in an SVG 1.1 document? Is your answer documented in the SVG spec anywhere?

I would say it is not required, but I don’t believe it is documented anywhere.

In XML the version attribute is recommended but not required.
See https://www.w3.org/TR/xml/#sec-prolog-dtd
It’s likely that the version attribute on the svg element was influenced from XML so that is probably a reasonable definition to fall back on.

>
> I’m aware that https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/version says the attribute is “purely advisory and has no influence on rendering or processing.” Is this a way of saying that the attribute can validly be absent in an SVG 1.1 document?

kind of?
It’s all a bit vague really.

>
> I’m also aware that the attribute has been removed in SVG 2.
>
> The context: We are crafting a few SVG doc examples for the SVG-in-OpenType specification. I’d like not to include the version attribute (smaller SVG docs are a good thing).
>
> Thanks,
> Sairus
>


Nikos.



The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Manuel Strehl-3
>> Can the version attribute validly be absent in an SVG 1.1 document? Is
>> your answer documented in the SVG spec anywhere?
>
> I would say it is not required, but I don’t believe it is documented
> anywhere.

If the SVG 1.1 DTD is of any authoritative answer here, there it's
defined as:

     <!ATTLIST %SVG.svg.qname;
     ...
         version %Number.datatype; #FIXED '1.1'
     ...
     >

(https://www.w3.org/Graphics/SVG/1.1/DTD/svg-structure.mod)

Remembering from the Olden Days that #FIXED in DTDs means, that an
#FIXED attribute is not literally required in the XML source, the DTD
says you can omit it.

-Manuel

Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Dr. Olaf Hoffmann
In reply to this post by Sairus Patel
Manuel Strehl:
>Remembering from the Olden Days that #FIXED in DTDs means, that an
>#FIXED attribute is not literally required in the XML source, the DTD
>says you can omit it.

Obviously this counts only, if this DTD is referenced with a doctype.
If both are missing, we only have a document without version indication,
not wrong, but one cannot say, what is a right or wrong interpretation of the
document - 1.0, 1.1, 1.2, 2.0 - everything might be possible.
And because all of them have smaller or bigger differences, it will be a
problem to get the right interpretation without version indication.
One has only SVG tag soup without a precise meaning, if the different
recommendations differ.
This problem occurs already with the second edition of SVG 1.1, it has no
own version indications, but differs in some points from the first edition.
For such points there is not really a defined interpretation of affected
documents or document fragments.

Looking at the date of production of a document will not be possible as well
always or is not sufficient


Olaf



Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Tab Atkins Jr.
On Fri, Apr 8, 2016 at 12:45 PM, Dr. Olaf Hoffmann <[hidden email]> wrote:

> Manuel Strehl:
>>Remembering from the Olden Days that #FIXED in DTDs means, that an
>>#FIXED attribute is not literally required in the XML source, the DTD
>>says you can omit it.
>
> Obviously this counts only, if this DTD is referenced with a doctype.
> If both are missing, we only have a document without version indication,
> not wrong, but one cannot say, what is a right or wrong interpretation of the
> document - 1.0, 1.1, 1.2, 2.0 - everything might be possible.
> And because all of them have smaller or bigger differences, it will be a
> problem to get the right interpretation without version indication.
> One has only SVG tag soup without a precise meaning, if the different
> recommendations differ.
> This problem occurs already with the second edition of SVG 1.1, it has no
> own version indications, but differs in some points from the first edition.
> For such points there is not really a defined interpretation of affected
> documents or document fragments.

More correctly: it doesn't matter what version you indicate, because
user agents don't contain multiple rendering engines to support
different versions.  Whatever you put there (or if you omit it),
you'll get the latest version of SVG.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Dr. Olaf Hoffmann

Tab Atkins Jr.:
>
> More correctly: it doesn't matter what version you indicate, because
> user agents don't contain multiple rendering engines to support
> different versions.  Whatever you put there (or if you omit it),
> you'll get the latest version of SVG.
>
> ~TJ

Versions of user agents change almost every month now.
But the meaning of a SVG document with some version indication
does not change at all, no matter, how they are currently interpreted or
presented.
Their meaning is not time dependent.
Current viewers still have many gaps and bugs, therefore their
presentation is often/typically a wrong interpretation of non trivial SVG
documents using features they get wrong or  they do not interpret at all.
Therefore what current user agents do or not, is not a measure.
But of course, without a version indication no interpretation can be really
wrong, just because the document is only arbitrary tag soup - exaggerated
of course, for those features, defined exactly in the same way in all
recommendation versions, there is no conflict and the interpretation is still
defined.
If the document is simple enough, the version indication does not matter, as
long as new SVG versions do not create new conflicts in the future.
But how knows the future?
In practice we know - new versions will create new conflicts with older
versions, not just new features.

Olaf


Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Tab Atkins Jr.
On Fri, Apr 8, 2016 at 1:24 PM, Dr. Olaf Hoffmann <[hidden email]> wrote:

> Tab Atkins Jr.:
>> More correctly: it doesn't matter what version you indicate, because
>> user agents don't contain multiple rendering engines to support
>> different versions.  Whatever you put there (or if you omit it),
>> you'll get the latest version of SVG.
>
> Versions of user agents change almost every month now.
> But the meaning of a SVG document with some version indication
> does not change at all, no matter, how they are currently interpreted or
> presented.
> Their meaning is not time dependent.

In practice, yes, it does change, and yes, it is time-dependent.

Pretending otherwise does not help the question-asker.  We should not
give people the false impression that adding a version="1.1" attribute
to their page will have some effect.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Dr. Olaf Hoffmann
Tab Atkins Jr.:

> > Their meaning is not time dependent.
>
> In practice, yes, it does change, and yes, it is time-dependent.
>
> Pretending otherwise does not help the question-asker.  We should not
> give people the false impression that adding a version="1.1" attribute
> to their page will have some effect.
>
> ~TJ

The attribute does not matter for presentation in current user agents, but
it clearly has a meaning for the document and authors intends and
for archivist in the future, just in case the document survives.
It is always more information about the document as any meta information,
and it is up to future consumers of the document, what to do with it.
Obviously without such an indication, future consumers will have less
information about the intends of the author.
If the intention is to provide so vague tag soup, it is ok not to drop it.
It the document is only for today and it is ensured, that it is removed
from existence tomorrow, the attribute is of no importance.
Else it has some function, but surely not for the rending in known current
viewers.

Already for HTML5 we have the problem, that authors need to use other formats
like Dublin Core to indicate, what version they use.
There is no need to have this complication for SVG as well.

And clearly no - authors intends and meaning of documents do not change
due to current interpretations of viewers.
Only authors decide  about intends of their documents, not such viewers or
implementors of such programs or authors of future versions of a format.

Olaf

Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Sairus Patel
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

Reply | Threaded
Open this post in threaded view
|

Re: version attribute of svg element

Robert Longson
In reply to this post by Sairus Patel
If you raised a bug about version="1.1" and transform on the <svg> element I'd close it as INVALID or WONTFIX.

Firefox will not read the version attribute and do different things depending on its value.

Best regards

Robert.