Re: Browsers

Chris Lilley wrote:

>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.
>  
>
True, but there are limits to this.  First, if you know of someone 
interested in
"feature X", who has support to work on Mozilla, send them our way.  
I've heard
that Adobe has lots of implementation experience.  Would they like to 
donate some
time?  Seriously, while resources are not limited in the same way, they 
are often
limited in other ways.  I'm a volunteer, for example.  My management is 
aware and
supportive of my involvement, but at the end of the day, its not "my day 
job".
Second, and perhaps more critical, there is a significant resource 
limitation in the
reviewing and superreviewing stages of the development cycle.  There are 
just
not that many people who have spent enough time with the code base to be in
the position to provide r/sr on some of the code that lives down in the 
guts of the
layout engine, for example.  This is a critical stage in the process, 
and the way
in which new people (like me) learn the code base without breaking 
things really
badly in the nightlies or releases.

>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.
>  
>
Great!  Do they want to share?  Seriously, its in all of our interest to 
have Mozilla
support SVG.  Resources would really come in handy.  New SVG developers 
would
be welcome with open arms!  Would it be frustrating for some? Yes.  
Would their
code take a while to get through review and superreview?  Sometimes.  
That's the
process, but at this point, as someone who has "started at the bottom" I 
can testify
that its a good process.   Have them join us on the IRC and tell us what 
they're
interested in implementing.  We'll get them started!

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