Re: Proposal for unitless lengths (Was: Is the px unit equivalent to user units?)

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