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

Hi, Ian-

Ian Hickson wrote:
| 
| On Thu, 5 Jan 2006, Doug Schepers wrote:
| >
| > we should require the casting of a scientific notation in 
| > any offending style attribute to the equivalent decimal 
| > representation in the computed property.
|
| You are confusing two things.
| 
| The _syntax_ being different is a problem for people writing 
| _parsers_. It has absolutely no effect whatsoever on the 
| strongly typed value that is used in the cascade, 
| computation, inheritance, used-value-calculation, and 
| actual-value-calculation steps.

You are confusing two things:

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), with the proviso that
an implementation must supply the 'px' unit to any number attribute value
which has a style property, before passing the value to the CSS engine
(whether that be at the computed style level or sometime before); this
trivially easy operation takes place inside the SVG parsing engine, thus the
CSS engine will never see any unitless length, and should not need any
adjustment at all.

2) Parsers are not inherently difficult to write. Yes, the CSS parser may
be, since there are so many microsyntaces and casting of values, especially
with things like the font shorthand (for example, a raw '400' is always a
font-weight, oddly, though most people use either 'bold' or 'normal',
forcing all other numbers to have units to distinguish them). But any given
browser must already contain several parsers... one for HTML, one for
XML/XHTML/SVG nodes, one or more for CSS (for legacy or quirks mode, and
each with its own microsyntax parser), a few small ones for various
attribute values in SVG (microsyntax for paths, polys, tranformations, SMIL
value lists, and others). But simple and consistent ones are very easy to
modularize, write, maintain, and extend. SVG has done a reasonable job of
keeping these to a minimum, and keeping them consistent.


| Take 'color' for instance. All of the following:
| 
|    color: red;
|    color: RED;
|    color: #f00;
|    color: #FF0000;
|    color: rgb(255,0,0);
|    color: rgb(100%, 0%, 0%);
| 
| ...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, and simply wrong at
worst. There must be a point at which a color keyword is converted (probably
via hash table) to the internal representation (whichever the implementation
chooses that to be); to truly support all those types as internal
representations would result in a hugely bloated implementation, and one
ridiculously difficult to maintain.


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


|  * Numbers can have "e" notation in SVG, not in CSS.

In the proposed solution, only in attribute values, not in CSS properties. 

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.


|  * Lengths can omit the "px" unit specifier in SVG, not in CSS.

In the proposed solution, only in attribute values, not in CSS properties. 

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.


|  * Keywords are case-sensitive in SVG, not in CSS.

In the proposed solution, only in attribute values, not in CSS properties. 

This is a difference, but does not require anything of a CSS parser. In
SVG1.1, section 6.8 (Case sensitivity of property names and values) [1], it
clearly states, "Property declarations within CSS style sheets or in a
'style' attribute must only conform to CSS rules, which are generally more
lenient with regard to case sensitivity." It then goes on to informatively
recommend (not require) that authors use lower-case values.

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?

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


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

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? If so, do you have a proposed resolution?


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


| 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. I am looking for a
solution, while you seem content to merely dwell on the problem. It would be
far more productive for you to propose a resolution that would satisfy you.

I hope that I have clarified the effectiveness of this solution, and
demonstrated that should it be enacted and implemented, it will remove
conflicts between existing CSS parsers and SVG. Please let me know if you
see a flaw with this proposal, as I am eager to do whatever I can to resolve
any discrepancies between SVG and CSS that implementors may feel would
impact their work.

[1] http://www.w3.org/TR/SVG/styling.html#StylingCaseSensitivity

Regards-
Doug

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

Received on Friday, 6 January 2006 10:54:39 UTC