Re: High-Quality Dynamic SVG Viewer

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

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

>>  >> - 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"

    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.

Received on Monday, 27 January 2003 10:35:34 UTC