Re: High-Quality Dynamic SVG Viewer

On Mon, 27 Jan 2003, Thomas E Deweese wrote:

> >>>>> "DJ" == Dean Jackson <dean@w3.org> writes:
> 
> DJ> As Tobi notes, we're crossing messages here. I hope this one makes
> DJ> sense.
> 
> DJ> On Tue, 21 Jan 2003, Chris Lilley wrote:
> 
> >> >> Of course, the specification has to be clear on a few >> things,
> >> such as (but not limited to): >> - what to do with required
> >> children
> >> 
> >> They have no effect at all - they never affect well
> >> formedness. They do affect validity, though.
> 
> DJ> Right. However I think it would be valuable if the specification
> DJ> say what *should* (ie. maybe not *must*) happen in such cases.
> DJ> (e.g. missing missing-glyph in a font)
> 
> DJ> On closer inspection it might be better left up to the
> DJ> implementation.  After all, this isn't something we can test
> DJ> easily, nor does it have an impact on the rendering of a
> DJ> conformant document.
> 
>     I would actually tend toward limiting the types of tags that the
> 'auto-close' trick happens for.  Generally what we want is for this to
> happen for the grouping elements:
> 
>        svg, g, defs, switch, symbol...
> 
>     I would say that if there are any open elements other than these
> (and symbol is a little questionable) then progressive rendering
> should be inhibited.

I would add path and polyline in here.
Imagine downloading a huge path that is the outline of 
Russia or Norway. It would be nice to render something if
possible.

>     Thus you can never have 1/2 a gradient definition (which BTW would
> theoretically work in lots of cases since we have rules to fill out
> the gradient space - but I just don't think it's a good idea).

Thinking about it a little more, I feel that it should be left
up to the implementation in most cases. The SVG spec can just say
how we expect things to happen, but not place any requirements
on the techniques.
> 
> >>  >> - what to do with currently invalid references
> >> 
> >> There are always cases where the currently downloaded document
> >> fragment cannot be rendered (or parts of it cannot) because it is
> >> blocking on some other thing it references. Allowing progressive
> >> rendering does not guarantee that it can be done in all cases.
> 
> DJ> Yes. Maybe hints to say "render using default fill" if the fill:
> DJ> url(#gradient) isn't available yet.
> 
> DJ> Again, I reserve the right to retract all this when it's proven
> DJ> that this is just a silly idea :)
> 
>     I think this is a silly idea :)
> 
>     If you wanted to allow people to say:
> 
>     fill="url(#myGradient), slateBlue"

Sorry, my wording was unclear. I thought about this case but
accidentally excluded it by leaving a word out. I meant to say 
"render using default fill rules" if the url(#grad) isn't 
available yet. That way the slateBlue is used.

>     So the implementation could fill with slateBlue if it couldn't
> find myGradient (or perhaps in Tiny didn't have gradient support).
> Then this makes some sense but rarely would filling with black be
> desirable over waiting on the element (especially since they should
> put the gradient early in the file or shortly after the rect).  I have
> no problem requiring some work from authors/authoring tools to get
> high quality progressively rendered content.

Dean

Received on Monday, 27 January 2003 18:39:47 UTC