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

Doug, it seems to me that you're in violent agreement with Ian, for the most 
part.  Details inline below:

Doug Schepers wrote:
> You are confusing two things:
> 
> 1) In the proposed scheme, there are 2 ways of dealing with the problem:

Well, they're both needed to deal with the problem.

> 2) Parsers are not inherently difficult to write.

I don't think Ian said they were...

> | ...have EXACTLY THE SAME internal representation. They are 
> | all EXACTLY the same specified value, computed value, cascade 
> | value, inherited value, used value, etc. You don't have to "convert" 
> | the keyword 'red' to the hex value "#FF0000"; it's the same thing. 
> | The only difference is the syntax that the parser has to support.
> 
> Your statement is implementation-specific at best

Actually the statement that the computed, cascade, inherited, and used value are 
identical for all of those is true by virtue of being a MUST in the CSS 
specification.  So it's not at all implementation-specific.

The situation is less clear for specified values, of course, in view of people 
wanting to edit CSS.

> There must be a point at which a color keyword is converted (probably
> via hash table)

Sure.  That doesn't contradict what Ian said.

> | 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.

The use of the adjective "only" above suggests to me that Ian did not exactly 
view this as a huge problem.


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

Yes.  "attribute values" are defined by SVG.  CSS properties are CSS.  So you 
and Ian are saying exactly the same thing.  So I'm not sure whence the argument 
in favor of scientific notation; no one was claiming it's not useful.

> 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.

I think Jonathan's reply summed up the issues with this approach well.  It's 
simpler to just write a separate parser for SVG attributes (as you pointed out; 
writing parsers for well-specified formats is not that difficult).

> |  * 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 Ian said.

> When an SVG parser encounters an attribute value that is a unitless number,
> it should append a 'px' unit before the CSS parser sees it. Problem solved.

And again, see Jonathan's mail.

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

That's what Ian said.

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

It requires something from an SVG attribute parser, yes.

> 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 sure this would do the right thing with font-family, for example.

> Obviously, since CSS is case-insensitive, so no conversion is needed to go
> from SVG attributes to CSS style properties.

Under what circumstances would one be going from "CSS style properties" (at 
which stage?) to "SVG attributes"?

> |  * 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. 

Right.  That's what Ian said.

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

The converse, however, is not true, nor should it be.

> 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.

They are not.

> I don't see a conflict here, do you?

The only "issue" is that an SVG attribute parser needs to treat comments as 
errors while a CSS parser needs to treat them as comments.  The proposed 
resolution is that there be two separate parsers (or two complicated and very 
separate modes in a single parser).

> | We are already way past the paint of being able to trivially 
> | re-use the same parser for both.
> 
> I know you would like to characterize it that way, evidence to the contrary,
> but I do not understand your obstinancy on this issue.

What issue?  Why is being able or not being able to use "the same parser" for 
two different syntaxes an issue at all?

> I hope that I have clarified the effectiveness of this solution

Which Ian was agreeing with...

> and demonstrated that should it be enacted and implemented

Which Ian was also agreeing with.

> it will remove conflicts between existing CSS parsers and SVG.

Yes.  More precisely, it will make it clear that two separate parsers or two 
separate modes or whatever are needed and that the two should not be mixed (that 
is, CSS should not be parsed in the SVG mode, nor conversely).

-Boris

Received on Saturday, 7 January 2006 00:14:37 UTC