- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Wed, 19 Oct 2005 17:51:47 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style@w3.org
Hi Boris, On Oct 19, 2005, at 16:29, Boris Zbarsky wrote: > Robin Berjon wrote: >>> I believe that many issues have been raised over the years along >>> these >>> lines (e.g. the fact that 'font' in SVG 1.0 is not compatible >>> with 'font' >>> in CSS1 was raised many years ago -- still not addressed, by the >>> way). >>> >> To the best of my knowledge this specific issue was never raised, >> despite at least three formal reviews of the SVG specification by >> the CSS WG. >> > > It's been raised a number of times just in the time I've been > watching the www-svg list, by multiple people and in formal CSS WG > comments. One issue is that the treatment of line-height in 'font' > is different in SVG (where unitless line-height means user units) > and CSS (where unitless line-height means multiplier by the font- > size). This has definitely been raised quite recently. Sorry, I was quite unclear when I wrote "this specific issue". The "this" in there didn't point to the unitless font issue, which indeed has been reported more times than I could possibly count, is a major cock-up, and hasn't been solved due to the petty animosity of a variety of people. I was talking about the issue of other W3C specifications not being allowed to add CSS properties without changing the media type of CSS style sheets. > I'm not trying to start a thread here on whether SVG should be > using unitless lengths, but the impact of using them is that > parsing CSS "the SVG way" is not the same as parsing it "the CSS > spec way". AFAIC SVG should indeed keep using unitless values because they make a lot of sense there, but there should be a way to ensure that they don't occur where they can create issues (how that is done, by introducing a "uu" unit or some such, I really don't care). >>> Consider. Would the SVG working group object to the CSS working >>> group >>> introducing an <svg:flow> element to the SVG namespace? >>> >> If done in coordination and with review from the SVG WG, no, >> probably not. > > And if done over the objections of the SVG WG? This applies to the unitless font issue, but not to the issue I'm interested in. > I'm sorry to see you trying for the moral high ground on the > subject of interaction between CSS and SVG; I don't believe there > is any moral high ground to be had on this sordid topic. I'm not taking the moral high ground, I know I've done my share of cock-ups. I am however objecting to what I can only call a technically inept decision. Please also keep in mind that I am objecting in my own name (as well as that of the company I represent), not representing the SVG WG, and that my objection is not about CSS vs SVG, but in fact about CSS vs pretty much everyone else since other specifications should be allowed, in coordination with the CSS WG (which I note again has indeed happened, though insufficiently), to add properties that they need. That's why I'm asking that this issue be resolved through coordination (which likely means that it should be discussed in the HCG). > -Boris (who is not a member of either of the working groups > involved, but just trying to implement the broken result of many > twisty specifications, all conflicting). My heartfelt compassion... Assuming that we would follow the CSS WG's notion of what can be put in a text/css resource so that the SVG or CDF WG would come up with a new media type (say application/cdf-css), how would you see that being implemented? Given an XHTML document with inlined SVG, if a property is defined on an XHTML element through a linked in text/css resource, would it be allowed to cascade into the SVG? Would it be easy/pleasant to branch the parser? Are there benefits that you see to compensate the cost of introducing one (or more, if other WGs imitate the CSS WG's approach) more media type? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Received on Wednesday, 19 October 2005 15:52:45 UTC