- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Sat, 3 Dec 2005 06:38:06 -0500
- To: www-svg@w3.org
- Cc: T Rowley <tor@cs.brown.edu>
[This email on behalf of Andrew Shellshear (speaking for the SVG WG),
it seems several WG members are prevented to post to the list these
days!]
In http://lists.w3.org/Archives/Public/www-svg/2005May/0162.html, T
Rowley said:
> 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'.
> C.3.1
>
> There is text describing an example, but no corresponding example.
We have fixed this, thanks.
> C.5
>
> 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).
> C.7
>
> 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 dependant.
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
background),
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.
Andrew.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
Received on Saturday, 3 December 2005 11:38:09 UTC