Re: [SVGMobile12] Comments: Basic Data Types and Color Keywords

Boris,
This email is the official SVG WG response to your email
(http://lists.w3.org/Archives/Public/www-svg/2005May/0037.html).

>4.1
>
>What happens if an integer is outside the "32,767 to 32,767" range?
Does it 
>wrap?  Is it "clipped" to the range?  Are these behaviors allowed, or
required?
>
>More simply, if a UA claims to implement SVG Tiny 1.2 and allows 32-bit

>integers, is that UA compliant?  That's not clear from this section.
>
>Similar issue for <number>.  It is further unclear whether the "fixed
point 
>number in the range '-32,767.9999 to +32,767.9999'" precision is
required, and 
>if so how many digits of precision are being required here.

After subsequent email discussion on www-svg, with
(http://lists.w3.org/Archives/Public/www-svg/2005May/0041.html) you sent
the following comment:

-------------
My point was that it's not clear from the specification that this is a 
restriction on the _content_ and not on the _UA_.  This should be
clarified.

Further, just because content is non-conformant does not necessitate 
user-agent-specific behavior (though I would be ok with it in this case,
I 
think, since detecting non-conformance on the part of the UA may be
impossible). 
-------------

We agree. As a result, the SVG-t 1.2 specification has been changed to
clearly indicate that the number range restriction is a content issue.
For example, it now says:
 
"Conforming SVG Tiny 1.2 content must use <integer> values with a range
of -32,768 to 32,767."

>
>
>"SVG Tiny 1.2 only supports CSS units on the the 'width' and 'height'
attributes 
>on the outermost 'svg' element." -- does that mean that lengths using
said units 
>elsewhere must be ignored by a conforming SVG Tiny 1.2 UA?  If so,
what's the 
>rationale, given that you're effectively requiring support for these
attributes 
>in one place (which means that one place has to use special-purpose
code now).

The above restriction is a carryover from Tiny 1.1 and thus is not a new
issue with the Tiny 1.2 Last Call. 

Nevertheless, here is the explanation. Back when Tiny 1.1 was defined,
the SVG WG felt that it was an appropriate tradeoff to simplify
implementations such that CSS units were not available inside the SVG
file but that we would require special attribute handlers for the
'width' and 'height' attributes on the <svg> element. CSS units on a
universal basis are a large implementation burden for a seldom-used
feature even on desktop computers. We retained units on the 'width' and
'height' attributes because the supplied an essential feature and
special implementation logic on these two attributes was not considered
an implementation burden. We felt (and still feel) that this was an
appropriate tradeoff for a Tiny profile targeting highly constrained
devices.

>
>"Percentage values (e.g., 10%) on the width and height attributes of
the svg 
>element represent a percent of the viewport" -- That's not really
consistent 
>with Chapter 7, where these attributes are used to define the size of
the 
>viewport.  Please make this consistent.

Thanks for pointing this out. We have removed the above sentence from
4.1 and added clarification text to Chapter 7 in the section on "The
Initial Viewport", where the clarification text aligns with the new CSS
2.1 write-up about computing width & height of replaced elements.

>
>Is there a reason that vertical tab is not included in the list of
characters 
>considered "white space" in lists?  (Note that I just raised the same
question 
>with the CSS Working Group regarding the grammar of CSS.)  Also, the
prose and 
>the grammar don't match here -- the grammar doesn't allow form-feed,
while the 
>prose does.

Note that SVG's <list of xxx> data type was designed way back in SVG 1.0
and thus is not new with SVG-t 1.2. 

This data type is independent of lists in CSS or any other language. The
data type is not used for any styling properties and thus has no effect
on any parsers that might be associated with CSS logic. 

This construct is used primarily for lists of numbers, so in most cases
all that was really needed was space (U+0020), but back in SVG 1.0 we
wanted to allow long polyline and polygon specifications to include
CR/LF/FF sequences as a convenience to hand-coders. Because the list
construct is mainly used for lists of numbers, we did not feel (and
still do not feel) it appropriate to take into account vertical text
space characters.

But most of all, we do not want to consider any changes here because
dozens of existing SVG implementations already conform to the rules for
this data type, which as I mentioned earlier, goes all the way back to
SVG 1.0. 

>"color keywords names" should be "color keyword names".

Thanks. Fixed.

>
>Note that the definition of rgb() color specification in CSS2 has been 
>effectively errata-ed by the CSS Working Group in CSS2.1; as a result a
UA that 
>wishes to support both SVG Tiny 1.2 and CSS2.1 must either have two
separate CSS 
>color parsers (and somehow decide when the use the "svg" one!) or must
fail 
>conformance to one specification or the other.

In subsequent email, you withdrew this comment:
http://lists.w3.org/Archives/Public/www-svg/2005May/0234

>
>"SVG Tiny 1.2 does not support percentage values except for the 'width'
and 
>'height' attributes on the outermost 'svg' element. Each attribute or
property 
>that allows percentages also defines the reference distance measurement
to which 
>the percentage refers." -- I don't follow what this is saying.  Why is
the 
>second sentence needed in its current form if the first is true?

Based on other Last Call feedback, we removed the definition of
<percentage> as unnecessary because <length> includes percentages in all
cases, which caused the second sentence to be stricken from the
specification.

>
>Is there a good reason to allow unitless time values?

We have removed the <time> data type entirely - Tiny doesn't use them.

>
>-Boris

Please let us know within 2 weeks if this does not satisfy your last
call comment.

Regards,
Jon, on behalf of the SVG Working Group

Received on Monday, 28 November 2005 13:32:06 UTC