- From: Jonathan Watt <jonathan.watt@strath.ac.uk>
- Date: Fri, 06 Jan 2006 19:07:12 +0000
- To: doug.schepers@vectoreal.com
- CC: www-svg@w3.org, "L. David Baron" <dbaron@dbaron.org>
Hi Doug, Doug Schepers wrote: > | The only problem with having SVG attributes use a different > | syntax than text/css is that you need a different parser. > | There are plenty of differences in the syntax: > > Four plates of rice are "plenty"; four grains of rice are not. I suggest > that the 4 particular issues you raise are on the lower end of the scale, in > terms of difficulty of resolution. You say "before the CSS parser sees it" a lot. From that it seems you believe it is practical for there to be a simple "SVG parser" that adjusts things before turning them over to the CSS parser. I believe the point being made is that this isn't practical: there will need to be a CSS parser for CSS, and there will need to be an entirely different SVG parser for SVG presentation attributes. The two will not interact. They may output the same internal data structures used by the rest of the style system (a single system) which does cascading etc., but there will be two different parsers, neither of which will pass data to the other for a second parse stage. Consider the following as an example: font='ITALIC SMALL-CAPS 4E2 /* 400 */ 20 / 2 CoolT, "Cool TX", serif' The SVG parser would have to be able to tell: 1) the 'ITALIC' and 'SMALL-CAPS' are an error 2) but the case of 'CoolT' and 'Cool TX' isn't important 3) that it has to treat the 20 as if it had 'px', but not the 4E0 or 2 4) that the '/' is allowed, but the '/* 400 */' is an error In other words it needs to know about the structure of expected values, about keywords, when numerical digits are a <number> and when they are a <length>, and so on. And by the time you've parsed all this out, checked it doesn't break SVG's rules (no comments, correct case) and made it conform to CSS's rules (added 'px' to the '20', changed '4E2' to '400'), the suggestion is you turn it back into a string and pass it on to the CSS parser so it can parse everything out again? I'm not involved with the parsing areas of our implementation, granted. However it seems to me if your parser knows about the keywords, the structure of values, etc., then it might as well directly output the data structures expected by the next stage of the style system. You may think that 'font' is a special complex case, but it's not so special. Look at the values accepted by the other properties (link above). Almost all include keywords, different types of numbers, URLs and others. You're talking about implementing a parser for all the possible values for all the properties listed here: http://www.w3.org/TR/SVG11/propidx.html Not quite as easy as eating four grains of rice I'd think. Rules like modifying existing specs to making stuff case sensitive and disallowing comments may be intended to make things easier for implementors. However, in reality it seems you can easily end up unintentionally requiring implementers to create two different implementations. > I'm not aware of any camel-cased property values (indeed, I do not see how a > case-insensitive language could suggest them), CSS doesn't introduce them, it's SVG! sRGB linearRGB optimizeSpeed optimizeQuality currentColor visiblePainted visibleFill visibleStroke crispEdges geometricPrecision optimizeLegibility > so a simple case conversion > will suffice. Do you agree? Nope. > Any parser that can already handle the presence of comments can obviously > also handle their absence. While it is convenient for authors to be able to > comment their lists, I shouldn't think that such comments are carried down > to the computed or presentation level of renderer interpretation. I don't > see a conflict here, do you? The point is that implementations should treat comments in presentation attribute values as an error, not allow them like you imply they could. If you do then you get content portability issues. People write SVG for Mozilla, say, and since it doesn't treat comments as an error they use them. Of course their content breaks in other stricter implementations. So there is an issue. > I am looking for a solution, while ... Knowing you personally, I know that you're working hard to find solutions for all these horrible problems. However please take care not to dismiss the issues people bring up as non-issue brought up by trouble makers. Maybe occasionally that's the case, but I think most often it is not. Some of these people have vastly more experience of writing both specifications and implementing them than you or I. Thanks for your efforts to resolve these issues Doug. They are genuinely appreciated. Jonathan
Received on Friday, 6 January 2006 19:07:20 UTC