Re: Browsers

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