Re: Comments on new Draft

On Fri 19 Mar 2004, Jan-Klaas Kollhof wrote:

> 
> Hello,
> 
> 5.2.2
> 
> >In the author wishes to change the default tab order,
> they must catch
> > the input event related to the navigation (such as
> the tab keypress)
> > and then cancel the event.
> 
> What if it's not the TAB key that is used for tabbing
> in the desktop
> environment.

That's why I wrote input event related to navigation,
rather than the tab key. I understand your point: there
isn't an input event related to navigation, so it
may or may not be the tab key.

Maybe we need a new event? Maybe DOM 3 Events already
does this (I should check)?


> Wouldn't the keyevent give me the tab
> key(identifyer:
> "U+0009") when TAB is pressed or would it give me that
> identifier too
> when the tabbing key(maybe not the TAB-key, depending
> on setup) is
> pressed ?

Obviously depending on the Unicode Tab character doesn't
work in all situations (such as on a mobile phone).
We'll have to see what else we can do.

> 17.6 SVGTimer Interface
> 
> I still think a timer should be an EventTarget and
> have
> a addEventListener to add a listener which handles
> timer events.
> The SVGRunnable, addHandler, removeHandler should be
> removed.
> 
> This is basically just a renaming thing but I think it
> fits better
> with the rest of the interfaces.(see the networking)

Yep. We've decided to do this already, I just didn't
get time.

> 
> 
> 17.7.1 URLRequest interface
> 
> Why have postURL and getURL in the specs when there is
> a URLRequest.
> I find that a bit redundent. Also the URLRequest
> offers more then
> getURL and postURL.

Yes, but seeing as there is a lot of existing content
that uses them, they are convenient and they can
be expressed in terms of URLRequest calls, it seems
a pity to get rid of them.

> What events will we get. Any PartialDataArived,
> ConnectionClosed,
> Error, ... ?

This bit needs to be expanded, yes.

> There is no word about relative URLs.
> If my document is located at
> http://some.domain/something/mysvg.svg
> will a request to the relative url: ./someresouce.py
> do what I expect,

Yes.

> that is to inherit from the documents base.
> What if the document was loaded over https will my
> request use https
> too then.
> This is the behavior of XMLHTTPRequest in IE and
> Mozilla. They inherit
> properties from the connection the document was loaded
> from.

I would expect the same as you suggest.
Obviously needs to be specified - thanks for raising them.


> 
> 17.7.2 Raw Socket Connections
> 
> What about a ConnectionClosed event?

Yes, we just didn't get around to adding that yet.

> Why not have a Connected event or is connect blocking
> and throws an
> exception when something goes wrong?
> What about Error events or ConnectionClosedByPeer?

All good suggestions.

> What about a recv function?
> DOMString recv(length, [timeout])
> 
> I know there is a data event, I am just trying to do
> some sync stuff
> here. :)
> 
> 
> 
> 17.9.2 Interface FileDialog
> If I can read files and send them to a server, why not
> add the ability
> to save them locally?
> Tell the file dialog to save a file:
> fileDialog.save(fileData, defaultFileName)

What use case do you have for this?
We already added the persistent data store (which has
a size limit).

> This allows the user to decide if he/she wants to
> actually do this or
> not. So no security problems there.

Sounds a little scary to me. I can think of a nice
dialog telling me to save a new copy of my ssh key.


> 
> 
> 17.10 Filtering DOM Events
> 
> Hmm, I don't like the interface very much.
> Can there be a more extensible filtering:
> maybe addMatchCondition(condition)
> 
> condition is an object which consists of:
> propName the name of the event's property
> propValue the value of that property
> 
> example:
> f = createEventFilter();
> c1.propName="target"
> c1.propValue=myRect
> c2.propName="attrLocalName"
> c2.propValue="width"
> f.addMatchCondition(c1)
> f.addMatchCondition(c1)
> 
> This would allow greater flexibility in defining
> filters.
> In my case I would say the event must match all
> conditions.
> They are ANDed.
> To take it one step further one could include AND OR
> condition objects.
> 
> example:
> 
> f = createEventFilter();
> ac = new ANDCond()
> ac.add(new Cond("target", myRect))
> oc = new ORCond()
> oc.add("attrLocalName", "width")
> oc.add("attrLocalName", "height")
> ac.add(oc)
> f.addMatchCondition(ac)
> 
> This would filter all events where
> target==myrect AND (attrLocalName=="width" OR
> attrLocalName=="height")
> 
> I guess there would be other ways to define the
> interfaces.
> 
> f.addMatch(new ANDCond([new Cond("...", ..), new
> ORCond([new
> Cond(...), ...])])
> 
> or simpler but more readable(well, maybe not really):
> 
> f.addMatchCond([["target",
> myRect],"AND",[["attrLocalName","width"],
> "OR",["attrLocalName","height"]]])
> 
> Maybe one could even introduce a filter syntax.
> 
> f.addObject('r1', myRect)
> f.setFilter("target=r1 AND (attrLocalName='width' OR
> attrLocalName='height')")
> 
> now that be fun.

We'll take this as input for discussion. Thanks for the
detailed analysis!

Dean

Received on Friday, 19 March 2004 06:01:34 UTC