W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

SVG 1.2 Comment: Painting enhancements

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 23 Nov 2004 14:39:46 -0600
Message-ID: <41A3A012.7090502@mit.edu>
To: www-svg@w3.org


The error handling when a fill that is not a solid-color operation is referenced 
needs to be defined.


It's not clear to me why we're defining an element targeted at closed workflows, 
primarily ones dealing with print output, in the specification of a vector 
graphics language for the Web.  I suggest that this part be removed, or moved to 
a specific SVG profile for closed non-Web workflows.


I'm not sure what the purpose of this DOM interface is... it doesn't allow 
anything that couldn't be done already (via a getAttribute() call).  Why does it 


"accuraucy" looks like a typo.

I suggest putting more linebreaks in the <paint> definition to make it possible 
to read it without scrolling at typical desktop monitor resolutions. 
Alternately, set the "white-space: normal" property on it to allow the UA to 
line-break it as needed.


It's not clear what a URI value for rendering-color-space does (in particular, 
what if the resource cannot be retrieved or cannot be understood by the UA?).


What are "references media"?


What happens if a <style> element has an xlink:href _and_ also has child nodes? 
  note that this is also not defined for <script>, in either SVG 1.2 or SVG 1.1. 
  Both should be defined by SVG 1.2, and interoperability tests for this should 
be added to the relevant test suites.


"are must always" is not an English grammatical construction.

The isFormatSupported() method needs to be documented.  What does it actually 
return?  Does the return value depend on the SVG element I call it on?  If not, 
why is it a method on SVGSVGElement instead of being a method on document or on 
the relevant part of the DOMImplementation?  If the return value does depend on 
the element it's called on, that dependency needs to be clearly explained.


This section seems to assume that a font-family name uniquely identifies a font. 
  However there can easily be multiple different fonts with the same font-family 
name ("Symbol" and "Times" come to mind offhand; the latter simply exists in 
many variants with rather different metrics).  Given that, it seems that the 
proposed capability is of rather limited utility in addressing the issues it 
attempts to address.  I question whether the added complexity is worth it for 
the possible improvement in results.


The interaction of overlay and overlay-host with CSS z-index should be specified 
(especially in a mixed-namespace context).


This should link to the relevant part of the SVG 1.1 specification, especially 
since "highlight" is not mentioned in the indices of SVG 1.1.


Here the property definition is again putting possible keyword values in quotes, 
which is inconsistent with other property definitions in this specification. 
I'd like to request that a single syntax for property definitions be decided on 
and adhered to.

"how much resources" is not gramattically correct English.

"whether or not" should just be "whether"


"whether or not" should just be "whether"

Received on Tuesday, 23 November 2004 20:45:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC