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

On Fri, 6 Jan 2006, Doug Schepers wrote:
> 
> 1) In the proposed scheme, there are 2 ways of dealing with the problem:
>    1a) by a clear acknowledgment that SVG must not dictate what behavior is
> expected from conforming CSS implementation, and that therefore all style
> property declaration must be in CSS-sanctioned syntax and format; thus, the
> CSS parser requires absolutely no changes;
>    1b) by allowing authors to use unitless numbers in SVG attributes (even
> attributes that have corresponding style properties)

Those two go hand-in-hand, they are not alternatives.


> |  * Numbers can have "e" notation in SVG, not in CSS.
> 
> In the proposed solution, only in attribute values, not in CSS properties. 

That's what I mean by "in SVG, not in CSS".


> Yes, scientific notation is a very handy feature in a language which is 
> designed to scale from the very tiny to the very large. When an SVG 
> parser encounters an attribute value that is a number in scientific 
> notation, it should convert it to digital notation before the CSS parser 
> sees it. Problem solved.

Conceptually, the CSS parser never sees it.

The model I am working with is this:

   SVG attributes -> SVG attribute value parsers ----->------.
                                                             |
   CSS stylesheets -> CSS parser --------------------->------|
                                                             |
                                                          Cascade
                                                             |
                                                        Computation
                                                             |
                                                        Inheritance
                                                             |
                                                            etc

If in practice only one parser is used, but with two different "modes", or 
if in practice the SVG attributes are "fixed up" before being sent to the 
CSS parser, that doesn't matter. Conceptually, what we would have is what 
is in the model above.


> |  * Lengths can omit the "px" unit specifier in SVG, not in CSS.
> 
> In the proposed solution, only in attribute values, not in CSS properties. 

Again, that's what I mean by "in SVG, not in CSS".


> |  * Keywords are case-sensitive in SVG, not in CSS.
> 
> In the proposed solution, only in attribute values, not in CSS properties. 

Again.


> This is a difference, but does not require anything of a CSS parser.

I agree. It's purely an SVG attribute value parser issue.


> In order to resolve this issue, I propose that we create an informative 
> errata item for implementors that when applying values from a CSS style 
> declaration, an explicit conversion from upper to lower case should be 
> used. I'm not aware of any camel-cased property values (indeed, I do not 
> see how a case-insensitive language could suggest them), so a simple 
> case conversion will suffice. Do you agree?

I don't understand what you are trying to solve. Conceptually there is no 
problem in my mind. The SVG a. v. parser has to be case-sensitive and the 
CSS stylesheet parser must not. It seems very simple.

The only "problem" is that all these differences make the implementations 
more complicated.


> |  * Values in lists can have CSS comments between them in CSS, 
> | not in SVG.
> 
> In the proposed solution, comments would be disallowed only in attribute
> values, not in CSS properties. 

That's what I meant, yes.


> Any parser that can already handle the presence of comments can 
> obviously also handle their absence.

It's not their absence that matters. It's that when that syntactic 
construct is _present_, the behaviour in the CSS parser must be different 
than in the SVG parser. (The latter must drop the entire attribute, the 
former must treat it as a comment.)


> | * etc.
> 
> As meticulous as you are, I cannot think that you would leave off this 
> list of sins any specific particular that you have found, so I will 
> assume that the list stops at four items, and this "etc." is intended 
> for emphasis. I'll mentally cast it as "!".

No, it was an "etc". As I told you on IRC the other day, when I say 
something, I mean it. If I had meant to say "!" I would have said "!".

Bjoern pointed to a series of other things I could have mentioned (e.g. 
character escapes; importance modifiers, trailing semicolons, complete 
declarations, the list goes on). It really is an "etc", there are plenty 
of differences between what a CSS stylesheet parser must do and what an 
SVG attribute value parser must do. There are in fact enough differences 
that it makes it impractical to have just the one parser, and all the 
implementations that have attempted to use just the one parser are 
demonstrably both non-compliant and non-interoperable amongst themselves 
(as noted by Bjoern).

Thus my conclusion in my last e-mail:

> | We are already way past the paint of being able to trivially re-use 
> | the same parser for both.


> I am looking for a solution, while you seem content to merely dwell on 
> the problem.

I have already given a complete solution:

 * SVG should clearly state, independent of any other specification, what 
   the syntax of its attributes are.

 * A CSS module describing how the SVG-specific properties can be used in 
   the CSS lexical space should be published.

See also:

   http://lists.w3.org/Archives/Public/www-svg/2006Jan/0060.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 6 January 2006 21:03:44 UTC