- From: Chris Lilley <chris@w3.org>
- Date: Wed, 10 Nov 2004 17:35:45 +0100
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: www-svg@w3c.org
On Wednesday, November 10, 2004, 3:44:55 PM, Robert wrote: ROC> Chris Lilley wrote: >>perhaps because the focus has moved away from W3C standards and >>more towards replicating a Win/IE clone experience on other platforms. >> ROC> I feel that this comment, and similar comments by Peter, are extremely ROC> unfair. We at Mozilla I wasn't speaking about Mozilla there. ROC> have made massive sacrifices by constantly ROC> choosing standards compliance over IE compatibility*. I know, and I pointed that out throughout my email. >>multiple codepaths; having a MathML implementation and an SVG >>implementation, for example. >> ROC> Are you saying that we should be able to implement MathML and SVG with ROC> the same code path? What does this mean? It means that MathML and SVG and, presumably, XHTML 1.1 are in the standards-based, XML-based codepath while the 'do something with IEWeb pages' is a different codepath. >>On the desktop, because the legacy HTML browsers were not interested in >>adding the newer XML based specifications - SMIL, MathML, SVG - into >>their fragile rendering layers. >> ROC> We've had MathML for about four years. Hardly anyone uses it, but ROC> we tried. I wasn't including Mozilla there, having already noted and favourably commented on the MathML and SVG support that it does have. How do you get usage statistics on MathML use by the way? (perhaps you could respond to that one by private mail, its not really on topic here). >>The decision to not do any SVG 1.2 in Mozilla is also disappointing, >>since Mozilla will not be able to help SVG 1.2 get through CR. Although, >>its not clear if that is a decision of the Mozilla foundation or just >>the policy of a couple of people' I hope that latter and that wiser >>voices will prevail. >> ROC> It's a resource issue. Breaking the IE monopoly and dragging the ROC> HTML+CSS Web towards standards-compliance with our limited ROC> resources is hard enough (but we're doing it). Implementing ROC> gargantuan specs like SVG 1.2 is just too much right now. I can understand that, if resources are a finite sum (add resource here takes away resource there). One of the benefits of open source is that this is not true - people interested in feature X implement feature X regardless of whether people interested in feature Y implement feature Y. ROC> The mobile vendors that you mentioned have only implemented SVG ROC> Tiny for the most part, if I understand correctly, and they don't ROC> even have to deal with the DOM/CSS/HTML integration issues. They have implemented Tiny or Basic as appropriate, so some have dealt with DOM and CSS. XHTML integration, even with Tiny, has been identified as highly desirable by some mobile carriers. ROC> I hope we can turn on some SVG support in default builds soon, but ROC> if we enable an SVG subset that doesn't correspond to a proper ROC> profile or is so broken that it poisons SVG for the Web, then you'd ROC> be the first to demand our heads and rightly so. I understand that and agree with it. ROC> So we have to get that right while also making sure we cover the ROC> features that Web authors want. Of course once it is turned on then it will get used rather more, because content creators can say 'this works in Mozilla/Firefox' rather than 'get your special geek-o-matic build here'. You and I have those builds, the general public does not, by and large. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Wednesday, 10 November 2004 16:35:45 UTC