RE: Differences In SVG and CSS (was: SVGT 1.2: !important is an error)

Hi, Ian-

I still welcome feedback and clarification on my other points from other
people, but I'll respond inline to Ian.

Ian Hickson wrote:
| 
| My e-mail was in reply to Robin's e-mail and was covering the lexical 
| space, not the value space. If you grant that there will not 
| be parser re-use, then I don't understand what you are asking.

I'm not speaking for the WG on that point, but I do personally advocate
different parsers. Is it somehow stated or implied in the SVG Spec that
there is no need for a different parser? I'm trying to make sure that I
understand the issue fully.

Would you be satisfied with a resolution that different parsers are required
for presentation attributes and presentation properties?

Finally, what issues do implementors see with this approach? If there are no
significant issues, and if (subjunctive if, not stative if) it is the
general consensus that we need different parsers, what is all the fuss
about?


| The value space is not an issue as far as I know. 

Thanks for the clarification. To further clarify, though, isn't it fair to
say that except for scientific notation and unitless lengths (both of which
could be solved by simple casting to a CSS-supported lexical value), SVG's
value space is compatible with CSS's, even if the converse is not true?

To restate: if a UA had a heavy investment in its existing CSS parser, or
had limited resources, I think the same parser could be used with the minor
addition of a casting mechanism to resolve those 2 issues. Would you agree
with that, Ian?


| (There might be some ambiguity with rgba(), but that is
|  easily solvable by simply defining it one way or another.)

Could you elaborate on this? I'd like to know what the problem is, and what
your proposed solution would be (and whether it should fall upon the SVG WG
or CSS WG to resolve it).

Many thanks for your helpful responses!

Regards-
Doug

doug.schepers@vectoreal.com
www.vectoreal.com ...for scalable solutions.

Received on Friday, 13 January 2006 00:23:17 UTC