- From: Jim Ley <jim@jibbering.com>
- Date: Fri, 9 May 2003 08:48:49 -0000
- To: www-svg@w3.org
Hi, 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. 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) 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) printNode Is the serialisation going to be mandated in any way, or is any valid serialisation going to be legal? 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. 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. 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. 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). Jim.
Received on Friday, 9 May 2003 07:42:46 UTC