- From: Chris Lilley <chris@w3.org>
- Date: Thu, 30 Aug 2012 09:03:01 +0200
- 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 UTC