Re: SVGt1.2 Means for the user to communicate?

Hi, Jonathan-

Why did you start up a new thread for this?  That makes it extremely 
hard to track well.  The easier it is for the SVG WG to track issues, 
the better the chance for the issue to be resolved satisfactorily.

~:'' ありがとうございました。 wrote (on 3/18/08 6:38 AM):
> SVGt1.2 Means for the user to communicate?
> 
> What means are provided in the current SVG1.2t draft for the user to 
> communicate?

As I asked before, what do you mean by "communicate"?  Communicate with 
whom?  Communicate for what purpose, and by what means?


> in my brief appraisal, the only means is by selecting and clicking on 
> links**.
> 
> in my opinion this is not reasonable nor sufficient for a web technology 
> at the present time.

Again, I reiterate:  what are the use cases and requirements you are 
requesting?  Without knowing what you are attempting to accomplish, we 
cannot decide if it is scope for our specs or now, nor can we determine 
how to satisfy the requirements.



> **consideration of Xforms rely on assumptions that may not be justified.
> keyboard navigation in SVG1.1 clearly demonstrates the error of relying 
> on other WGs.

I completely disagree.  The whole point of working in different WGs is 
so that no one group is a single point of failure.  In fact, we are 
progressing along well in WebAPI on DOM3 Events, and expect that we will 
be done with keyboard events this year; in addition, we're working 
closely with vendors so that the specification is actually implemented.


> html allows for text entry in forms, as outlined in a previous mail

And SVG 1.2 Tiny allows for text input on any text element, such as 
<textArea> (or in Full, <textPAth> too), without script, by using the 
'editable' attribute.

Using a rather simple script, an author could allow a user to upload any 
changed text to a server.  There's not yet a way to do this 
declaratively, such as HTML forms has, except in SVG+XForms UAs, but it 
would be nice to have.  Perhaps ARIA could allow an SVG element inline 
in HTML to be submitted as if it were any other input in a form.


> javscript allows for XmlHttpRequest.

Yes, and SVG has similar methods, getURL and postURL, which we are 
defining in compatible terms with XmlHttpRequest.  In point of fact, you 
can use XmlHttpRequest in SVG in Opera, Firefox, and Safari, today. 
What's wrong with that?


> Wii allows for quite significiant gestural input

That's essentially mouse events.  In fact, SVG works on the Wii.


> Doug in a previous mail seems to suggest that my query is rhetorical, it 
> is not.  I have serious and real concerns, and intend to voice them.

No, I did not suggest that.  On the contrary, I took your question quite 
seriously, and asked you for use cases and requirements.  Referring to 
rhetoric does not imply that the question is rhetorical; I mean not that 
it's fine to ask for something, but that the request has to explain what 
is needed.  Stop waving your hands, and point.


Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Tuesday, 18 March 2008 12:37:20 UTC