W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: Streaming

From: Jim Ley <jim@jibbering.com>
Date: Tue, 30 Nov 2004 18:25:18 -0000
Message-ID: <009401c4d709$f223da90$d8bec350@Snufkin>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: <www-svg@w3.org>

"Boris Zbarsky" <bzbarsky@MIT.EDU>
> Jim Ley wrote:
>> There's not really a concept of background colours in SVG to date, so I'm 
>> not sure of the relevance, my use of  background is not in the technical 
>> CSS sense here, but in the general case.
> I'm not sure what this sentence means.  Could you please explain?

"background" the parts of the image not in the foreground, unimportant to 
the content etc.

>> Certainly this is a problem HTML authors have
> If we're talking about implementing SVG in web browsers, that goes hand in 
> hand with those same HTML authors starting to author SVG (and do so badly, 
> most likely).

If HTML authors start authoring SVG in the same techniques then certainly 
it's a problem that could be addressed then with

>> I don't think it's a good example.
> That's ignoring a target market.  There are lot more people our there 
> capable of poorly authoring SVG than there are capable of authoring it 
> well.

I'm sorry if the aim of SVG or XHTML or CSS for that matter is incompetent 
authors, then they have all failed miserably, equally I don't believe that 
incompetent authors are relevant to the technical quality of those techs for 
any of those technologies (the well-formedness constraints on XHTML are 
definately not tailored to incompetent authors.)

> Mozilla does not, and doesn't really have much in the way of plans to in 
> the near future (say in the next year).

Mozilla SVG is not even beta product, let alone a shipping user agent, there 
are lots of SVG user agents that are, and I think their full life cycle 
experience showing it's possible is more valuable than Mozillas.

> Part of my point was that for a UA that chooses to NOT do progressive 
> rendering, which is not prohibited by the specification, the timeline part 
> of the specification is underdefined.

Oh sorry, I'd certainly missed that was your point, yes it does appear 
poorly defined here, but I'm not sure of the relevance to what we've 
previously been discussing.

Received on Tuesday, 30 November 2004 18:25:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:01 UTC