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

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

SVG 1.1 and SVG Tiny 1.2 both fail to define the lexical space of
presentation attributes in the required detail. For example, for the
"sRGB" value SVG 1.1 states that the keyword is case-insensitive and
goes on to say that only the exact spelling "sRGB" may be used. It
is not clear either what

  <rect height="100" width="100" fill="RED" />

would yield in; it's a red fill in Amaya, Opera, Firefox, ASV, and
Batik, and a black fill in TinyLine.

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

A more complicated case would be

  <rect height="100" width="100" fill="\red" />

which yields in a red fill only in Firefox. Ian already mentioned
comments,

  <rect height="100" width="100" fill="/**/red" />

This is red in Batik, Firefox, ASV, Amaya, and black in Opera and
TinyLine.

The results of using scientific notation in CSS versus presentation
attributes are roughly that implementation that support both means to
set styles support them either in both or in neither. I could go on
and point out that for

  <rect height="100" width="100" stroke-width="20" stroke="red"
        fill="red;stroke:green" />

stroke/fill are green/red in Amaya and ASV, red/black in Opera and
TinyLine and red/red in Mozilla, but by now we should all agree that
these presentation attributes are sort of a non-trivial thing.

I asked the Working Group to address these problems in SVG 1.2 e.g. in 

  * http://www.w3.org/mid/42520ed0.203371218@smtp.bjoern.hoehrmann.de
  * http://www.w3.org/mid/42573ae9.214659984@smtp.bjoern.hoehrmann.de

but so far the Working Group did not formally address my comments or
fix the SVG 1.2 drafts as requested.

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

What's needed for any solution is in my opinion a complete proposal that
shows changes to the SVG 1.1 Recommendation and any other Recommendation
involved at a textual level such that processing of the facilities in-
volved is well-defined. I don't know whether your proposal includes for
example that stroke-width, stroke-dashoffset, baseline-shift, kerning
are modified to allow a <number> in addition to a <length> if <length>
as used in SVG 1.1 is changed to exclude <number>. I do not know either
whether

  <svg:animate attributeName="font-size" attributeType="CSS"
               to="20" ...

would be allowed, and if, what the semantics of

  <smil:animate attributeName="font-size" attributeType="CSS"
               to="20" ...

would be; whether

  <svg:animate attributeName="font-size" attributeType="XML"
               to="20" ...

would be different and if, what

  <svg:animate attributeName="font-size" attributeType="auto"
               to="20" ...

might yield in (all assuming that font-size as defined in CSS continues
to disallow a sole <number>), all in addition to the problems mentioned
above.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 6 January 2006 17:52:19 UTC