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

SVG 1.2 Comment: API enhancements

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 25 Nov 2004 01:04:32 -0600
Message-ID: <41A58400.6070309@mit.edu>
To: www-svg@w3.org

B.1:

May I request that all interfaces in this specification be documented the way 
SVGTimer is?  I could actually take a crack at implementing this one!  ;)

That said, what does a negative delay mean?  Should that be unsigned long?

What do negative values that are not -1 mean for interval?

B.2:

What protocols does URLRequest suppport?

Why is the status code limited to three digits?

What happens if "only in COMPLETED state" are accessed in the PENDING state? 
What are the exact exceptions thrown?

Is the implementation expected to convert header values into Unicode using the 
relevant RFCs for the protocol?

Where is NameValuePair defined?

What exceptions would abort() throw?

What exceptions would submit() throw?

Is there any handling of multipart responses?

What happens if the response data is not text?  How is it to be represented as a 
DOMString?

What happens if the response data is XML?  What encoding is to be used to 
convert it to DOMString?  What about other text-based protocols?

This last point makes me much prefer the DOM that one can get off an 
XMLHttpRequest...

B.2.3:

DOMString is not an acceptable type for random byte data, which is what this 
interface would need to pass around.

I still feel that this interface does not belong in a vector graphics 
specification.  I would prefer it moved into an "applications profile" or some 
such, with the understanding that the Web Applications WG would take over that 
profile once it got going.

B.4:

Given that the file selector is asynchronous, what happens if the document is 
torn down (eg window closed) while the file selector is up?

What happens if multiple file dialogs are posed at the same time?  Note that in 
many operating environments file dialogs are window-modal.  That makes it 
difficult or impossible to pose more than one, and it may even make it difficult 
to impossible to pose them asynchronously.  Or is there no expectation that the 
OS-native file selection dialog will be used?

While it is true that ECMAScript uses 16-bit byte arrays, the DOMString type is 
defined to be UTF-16.  As a result, even when calling getDataAsString from 
ECMAScript it is possible that garbage will result if the data has to cross 
language barriers to get into ECMAScript (eg if the ECMAScript implementation is 
not doing file access itself).  This should be clearly documented.  The text as 
written makes it sound like it's reasonable to expect something sane out of 
getDataAsString in ECMAScript implementations, which is a bad expectation to 
give people.

Again, the selective quoting of interfaces is confusing.  Just say that there is 
an addContentFromFile method on URLRequest.

Note that addContentFromFile takes an SVGFile, while the interfaces in this 
section refer to File.

Again, this functionality would do better in a separate profile that is to be 
passed off to the Web Applications WG.

B.5:

It should be made clear that UAs may expire the data any time they see fit 
(especially at UA shutdown, as a privacy option); the "60 days expiration" 
language obscures that.

B.6:

The "location" property is inconsistent with what is commonly implemented as the 
"location" property in desktop browsers (where "location" is an object, not a 
string).  This makes it impossible to implement this property while keeping 
their existing set of properties on the global object.

printNode and parseXML are redundant with the relevant DOM3 Load/Save 
interfaces.  I suggest they be removed.

What happens if mouse capture is started on multiple global objects at once? 
Say I have 3 SVG images inserted in an XHTML page via <object>?

What happens if startMouseCapture is called while mouse capture is active?

-Boris
Received on Thursday, 25 November 2004 07:04:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC