W3C home > Mailing lists > Public > www-svg@w3.org > August 2012

Re: SVG 2 FPWD published

From: Chris Lilley <chris@w3.org>
Date: Thu, 30 Aug 2012 09:03:01 +0200
Message-ID: <883599306.20120830090301@w3.org>
To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
CC: Cameron McCormack <cam@mcc.id.au>, SVG public list <www-svg@w3.org>
On Wednesday, August 29, 2012, 3:11:12 PM, Jeremie wrote:

JP> I know it's a very early WD but here are some small quick thought about it:

Thanks, appreciated.

JP> Section 1.6
JP> I'm looking forward for the definition of "lacuna value" but I'm
JP> not sure it is quite différente than "default value" which seams a
JP> bit more easier to understand.  

Yes we probably do need to explain better; the terms are quite different.

In XML, "default" values for attributes define "how an XML processor is to react if a declared attribute is absent in a document".
http://www.w3.org/TR/xml/#sec-attr-defaults

Note that attribute-value normalization may add such default values to the infoset (I say may because it depends on whether external DTD subsets are fetched or not). It turn, this affects what is in the DOM, whether CSS attribute selectors match or not.

In other words a default value is missing in the document and *may or may not* show up in the DOM, etc. This is an undesirable cause of variability in implementations. It can also result in DOM bloat.

The term lacuna value was introduced in SVG Tiny 1.2 to deal with this.
http://www.w3.org/TR/SVGTiny12/intro.html#TermLacunaValue

A lacuna value is missing in the document, is *not* added to the infoset or to the DOM and can *not* be matched by attribute selectors. The specification tells the implementation what to do if tthe value is missing, without needing to sort-of-maybe add the value to the document.


JP> Section 2.3
JP> It is stated that SVG can be embedded in an HTML page using the
JP> img element or throught CSS. Is their a normative reference
JP> somewhere that define the limit of SVG embedded that way?

There is a separate specification that defines how SVG can be integrated into other documents. The hope is that SVG 2 (and HTML5, and CSS) will pick scenarios from that document.
http://dev.w3.org/SVG/modules/integration/publish/SVGIntegration.html

JP>  For
JP> exemple, Firefox does not allow scripts or external ressources in
JP> such cases. If this normative reference exist it would be nice to
JP> have a link to it. If it does not exist, it worth considering
JP> writing it in order to help implementor to define common behaviors.  

Yup. We just need to publish and promote it.

JP> Section 4.4
JP> Maybe it would be worth considering to reference css3-color
JP> instead of having the list of color keywords.

We do reference CSS3 color, in the main Color chapter. I tend to agree that the list of color keywords and their corresponding colors and values from SVG 1.1 (they were the first standardisation of that list) could be dropped for SVG2 in favour of a reference to CSS3 color.

JP> Maybe this should be part of chapter 12.

The list also occurs in  12.7 color syntax, where it is needed to provide a complete syntax, since color values in SVG2 are a significant superset of those in CSS3 Color. So I agree, we don't need the values or swatches anymore.


JP> Section 5.7
JP> Maybe it miss an annotation about
JP> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#.3Cuse.3E_cleanup ?  

Yes.

JP> Section 23
JP> Maybe it miss an annotation about
JP> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Extensibility ?

Yes.

JP> I hope this will help

It does, thanks for taking the time to give this initial feedback.

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Thursday, 30 August 2012 07:03:10 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:52 GMT