W3C home > Mailing lists > Public > www-svg@w3.org > December 2005

Re: [SVGMobile12] Comments: Implementation Requirements

From: Andrew Shellshear <shellshear@gmail.com>
Date: Fri, 2 Dec 2005 22:57:39 +1100
Message-ID: <8466a1620512020357m51b1c821x7dbb84e7fb9cc0f3@mail.gmail.com>
To: www-svg@w3.org
 In http://lists.w3.org/Archives/Public/www-svg/2005May/0162.html, T Rowley

C.2 "Unknown elements ... and their descendant elements are not rendered."

This seems to rule out the use of SVG in a mixed-namespace CDF document.

We have reworded C.2 for clarity.  The relevent new wording is:

Within an SVG document fragment, unknown elements, including unknown
elements in the SVG or XML Events namespaces as well as known elements
in the SVG or XML Events namespaces occuring in unexpected locations,
and their descendant elements do not participate in SVG rendering and
are not processed beyond their contribution to the construction of the
DOM. The processing model for unknown elements is equivalent to an
<svg:g> element with the 'display' property set to 'none'.


There is text describing an example, but no corresponding example.

We have fixed this, thanks.


Not defining where clamping must take place for colors and opacity means
that different implementation can generate different output for out-of-range
values.  This is bad for interoperability.  Clamp point should be specified..

We have reworded section C.5 to include the following:

User agents should clamp color values to the nearest color value (possibly
determined by simple clipping) which the system should process as late as
possible (e.g., presentation time), although it is acceptable for user
agents to clamp color values as early as parse time. Thus, implementation
dependencies might preclude consistent behavior across different systems
when out-of-range color values are used.

Opacity values out-of-range are not in error and should be clamped to the
range 0 to 1 at the time which opacity values have to be processed (e.g., at
presentation time or when it is necessary to perform intermediate filter
effect calculations).


Text selection implementation notes omit mention of visual feedback of
selection, and how to accomplish this in the general SVG environment.

We have added wording to the section indicating that visual feedback is UA
This is because it is very difficult to define what visual feedback to use.
XOR of selection is common, but not always useful (eg. with a noisy
and other common options equally have problems in specialist situations.

Thank you for your feedback. Please let us know if this does not address
your concerns.

Received on Sunday, 4 December 2005 02:12:15 UTC

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