Re: SVG 1.2 11.4 Window Object

On Fri, 09 May 2003, Jim Ley wrote:

> defaultStylesheet:
> 
> The defaultStylesheet property, is the stylesheet returned the User
> stylesheet, or the viewers? or some combination of the both (which I don't
> think is possible, as you wouldn't be able to tell if the document
> !importants override the !importants in the defaultStylesheet.)  I also have
> privacy concerns over exposing user StyleSheets to webpages as it does
> reveal rather more information about my abilities that I'm totally happy
> with, that concern is pretty minor though.  If the users is not mentioned,
> what value is there in having the stylesheet available at all?  Would not
> simply mandating a default stylesheet to viewers achieve the same result
> (authors knowing the viewers settings) much more simply and avoid the need
> to turn to scripting to achieve identical rendering - My incomplete
> experience suggests that SVG UA's are all using the same stylesheet
> currently and this is desirable.   It limits UA's in their customisation
> abilities, but I think this can be worked around by having the UA's provide
> "default" user stylesheets which the user can gain their customisations.

Good question and points. This will be raised in the WG.

> getURL/postURL
> 
> On these I would like to add further parameters, this wouldn't break
> backwards compatibility, (in older viewers they'd just be ignored) but would
> be very useful, the parameter I'd like to add would be an object defining
> Headers, either just the Accept header, or if possible all.
> 
> My aim is to not have to have seperate uris for different representations of
> the same thing.  So I can do a getURL request for an XML document, and get
> just the XML document, or I can do the same and get back an SVG document, or
> an RDF document or ...   Setting the Accept header would allow this. Setting
> other headers might also be useful (accept-language for example in a
> switch'd block on language)

There will be a separate message with more details on this feature.

> The callback is defined badly, it says "The argument passed to the function
> is an ECMAScript Object with 3 properties"   ECMAScript is obviously not the
> only language around in the SVG world, and that needs cleaning up to be not
> ECMAScript specific)

Good point!

> printNode
> 
> Is the serialisation going to be mandated in any way, or is any valid
> serialisation going to be legal?

We don't have a canonical version of SVG so I assume any valid
serialisation is legal. If anyone disagrees, speak up now.

This general point is related to signature/encryption of documents
also.

> setTimeout/setInterval
> 
> I'm concerned here with the DOMString parameter, the problems being that
> this by necessity assumes that the method is being called in a dynamic
> environment (a fully compiled language like Java/C#/C++ etc. will not be
> able to implement it)  It's looking scripting-language specific.

We've since changed this feature to a more object-oriented design,
as well as less language specific. Details in next draft (hopefully).

> Also previous small footprint ECMAScript implementations have seperated the
> compile phase to the execute phase, compiling the script on a proxy server
> sending just bytecode to the client device (I'm thinking of AvantGo here)
> and the String setTimeout version removes this optimisation (that said, you
> can't implement
> compliant ECMAScript without eval which also needs a compiler on the
> client - but there are other languages without this functionality.)
> 
> Passing a function reference rather than a string would be more appropriate
> (but less useful) than a DOMString.  Also in ECMAScript the DOMString
> version can be emulated with:
> 
> setTimeout(new Function("a"+"lert('fred')"),1000)
> 
> so it doesn't harm ECMAScript developers.

If you still have these concerns after you see the next version
of the spec, please let us know.

> I'm concerned with the idea of "MODAL synchronous messages", they're an
> accessibility concern for me (they're generally implemented as popup windows
> with their problems - particularly for me getting lost with all the other
> windows.)    Modal within the SVG document, but in window and in SVG
> viewport messages for confirm/alert/prompt will be implementable using
> Animations and XForms so I'm not sure for the need for these in script, in
> the HTML world today alert/confirm/prompt is very misused, and I don't think
> it needs encouraging in the SVG UA world.

Point taken.

> Also I don't like the idea that the timelines would stop while the
> messageboxes were shown (I'm assuming this is part of what modal means) this
> would prevent us from providing SVG animated advice on how to interact with
> the boxes (e.g. what to enter into the prompt).

Another good point taken.

Sorry for the lack of details in the response :)

Dean

Received on Tuesday, 3 June 2003 23:09:58 UTC