- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 28 Nov 2005 16:39:50 -0600
- To: Jon Ferraiolo <jonf@adobe.com>
- CC: www-svg@w3.org
Jon Ferraiolo wrote: >> "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? > The above restriction is a carryover from Tiny 1.1 and thus is not a new > issue with the Tiny 1.2 Last Call. I'm sorry that I did not get a chance to participate in the 1.1 Last Call, yes. ;) > 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. Perhaps my concern was not clearly stated. It's not clear to me whether the specification, as written, states that a conforming SVG Tiny 1.2 UA MUST NOT interpret CSS units anywhere except these two attributes. Or is this again a restriction on content (that is, conforming SVG Tiny 1.2 content MUST NOT use CSS units anywhere except these two attributes)? Or both? It seems to me that the intent of the working group given the explanation you sent is that CSS units MUST be supported for width and height on <svg> and MAY be supported elsewhere, but that's not what the specification says. > 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. Again, I'm quite sad that I was not able to participate in the Last Calls for earlier SVG versions. > 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. My comment had nothing to do with CSS; the mention of CSS was a parenthetical in that CSS had a similar vagueness issue). > 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. That's fine. Please make the grammar and the prose match each other. As my comment said, they currently do not. > 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. I don't see how they can conform to the rules if the rules are self-contradictory, as I pointed out above. > Please let us know within 2 weeks if this does not satisfy your last > call comment. That's pending replies to this response. -Boris
Received on Monday, 28 November 2005 22:39:58 UTC