Differences In SVG and CSS (was: SVGT 1.2: !important is an error)

Hi, Ian-

While my replies are to Ian, I'd appreciate feedback from others as well,
particularly implementors (especially on my proposal for unitless lengths,
below).


Ian Hickson wrote:
| 
| On Thu, 12 Jan 2006, Robin Berjon wrote:
| >
| > You're in a terminology disagreement. In the CSS grammar, 
| the thing on 
| > the right of the colon in a CSS declaration is "S* expr 
| prio?". Drop 
| > prio and exclude comments, you've got an SVG attribute 
| property value.
| 
| Except you really don't, as Bjoern and I have pointed out 
| several times. 

Well, actually, it's pretty close... I'll give details on a point-by-point. 

Please note that I'm doing this as much for my own clarification as to give
my opinion, so correct me if I've made a mistake. Note also, I'm operating
under the assumption that there will need to be a separate parser (or
subparser) for presentation attributes and presentation properties, which
somewhat reduces the burden of total compatibility.
  

| Case-sensitivity, 

This doesn't seem to be an issue. Since SVG is more strict, CSS can happily
deal with SVG values as regards case-sensitivity.


| scientific notation,  

I agree that this is an issue. The SVG WG has asked the CSS WG to allow
scientific notation before, but they declined. I will submit another request
to the CSS WG with our explanation of need. 

I think that this is solved on SVG's end by recommending a casting of values
into whatever internal representation the UA favors. Do you see any problems
with this approach?
 

| the infamous lengths without units, 

As with scientific notation, the SVG WG has asked the CSS WG to allow this,
but we understand that there are legacy issues that prevent CSS from being
flexible enough to accommodate extensibility here.

Obviously, this is not strictly an SVG Tiny 1.2 issue, since Tiny doesn't
call for integration with CSS, and does not allow units on any lengths in
content other than the root element. Nonetheless, it is a pertininent issue
that has undergone much discussion in the SVG WG of late, and we hope for a
quick and mutually satisfactory resolution.

There seems to be some dissatisfaction that CSS and SVG define <length>
differently. Just as a point of curiousity, would people prefer to see SVG
instead define and use <svg-length> and <css-length> (where <css-length> is
a pointer to the CSS Spec definition of <length>) throughout the Spec, where
appropriate?

At another level, there is the proposal to recommend the appendation of 'px'
to unitless lengths derived from presentation attributes, in cases where the
UA uses the same parser or processor for both SVG and CSS. What do people
think of this?


| escapes

While I agree that this is a distinction, I fail to see a compelling
use-case for escapes. Can you enlighten me here?

In any case, this is another issue where CSS is less strict than SVG, so
SVG-supported values should work fine with CSS in this regard.


| support for IRIs as opposed to URIs, 

I understand (through Jon Ferraiolo's explanation) that CSS 2.1 is just a
subsetting exercise of CSS 2, so it may not be appropriate to move from URIs
to IRIs, but as this seems to be the trend in other Specs, I think it would
be a positive step for the CSS WG to consider doing so anyway. If not, this
should definitely be brought up in the scope of the next CSS Spec.

Since SVG is not merely a subsetting exercise, but is a forward-looking Spec
that attempts to integrate with both existing W3C technologies and the
requirements of the fast-moving mobile market as they move toward
convergence, it would be inappropriate for SVG 1.2 to limit values to URIs,
particularly in the modern climate of internationalization.


| there are many differences.

Out of courtesy for those of us who have just joined this debate, and since
you are well-versed in the differences, I would respectfully ask you to
state all the issues explicitly, rather than alluding to them. Merely noting
that there are many differences prevents us from taking everything into
account, and results in a suboptimal solution. 

Also, I don't want people who aren't as well-informed on the issues to have
the impression that there are more problems than there really are.


Regards-
Doug

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

Received on Thursday, 12 January 2006 23:20:21 UTC