svg 1.2 comments

Hi

> 3.2 Editable Text Fields
> Implementing such a feature in SVG 1.1 with the DOM is nearly
> impossible without restricting functionality, such as only allowing
> latin left-to-right text.

But only nearly ! :)
http://jan.kollhof.net/projects/svg/examples/gui/textbox.svg

right to left I have not tried and with SVG1.2 coming up I doubt I will :)


> 5.1 XForms
> At the time of publication, the Working Group is undecided as to
> whether or not the SVG specification
> should describe a default rendering and behavior for some form
> elements, such as buttons and sliders.

No. Widgets change and people like to have them look according to
their page design.
Have a look at a nicely designed HTML page with form controls. They
can really destroy the whole look. :)
At least now one can style them using CSS but it was not always so.

> Would a simple set of form widgets be sufficient in most situations,
> or would authors prefer to always create the SVG rendering and
> behavior for every element?

People will start writing little widget libs using RCC and scripting
which can then be used by the "end" user/developer of the SVG page.
And if someone does not like the widgets offered by others he/she can
write their own widget set.
I think this allows greater flexibility yet keeping ease of use.

Looking at what is already impl. in pure SVG I see no problems.

> ...by adding a small number of low-level widgets to the SVG language
> (such as text-entry)

I think the editable and focusable attribute is sufficient for
creating widgets using SVG alone or in combination with RCC.


> 5.2 Focus
> API to get focus? (SVGElement::focus() or special interface)

Yes, that would be needed.

> 5.3 Tool tips

Please try to hover with your finger over a touchscreen to make the
tool tip appear.
Same for pen based devices. (Graphic tablets actually do support hovering)


> 7.1 The audio element

Make OGG/Vorbis mandatory to be implemented.
It is a quite versatile format.

> 7.2 The video element

I wish the Ogg people would get there Video codec finished. That would
be a good choice.
Other than that I'd say Mpeg Video/Divx in an ogm container with
ogg/vorbis audio. Hoping that someday the free codec
is finished.

I like the rendering into an offscreen buffer so that the video
behaves like any other element.

I have played with the ASV6 impl. and noticed that it is difficult to
use large videos due to the fact
that the viewer loads the whole file first before playing it.
An SVG viewer should be required to start playing the video with the
least prebuffering needed. And should not necessarily
download the complete video file.
This also will save bandwidth when videos are viewed partially and it
will save resources on the client side.

> 7.3 Media Properties

What about changing the volume of separate channels in an audiofile.
This would allow to control for example surround or stereo sound or
mixing of different audio tracks in an audio or video file.
What about rerouting of each audio track to an output. For example
choosing to have channel1 output to front-left and channel2 to
rear-left ...

> 8.4 Navigation
> It is also suggested that user agents bind input methods, such as
> the PageUp and PageDown keys if available, to page navigation.

There should be a way (scripting or using attributes in the root
element/pageset element ...) to disable this behavior.

It should actually be possible to disable all key bindings so one can
use the keys inside the SVG.

> 15 Extended links.
> activating an extended link causes a menu to be displayed

I personally don't like the idea of a UA to pop up a menu for either
links or a context menu or ...
What would be nice is to allow the SVG to handle these things through
events.

Example:
A link is clicked which fires an event which can be handled by a
script
if evt.preventDefault() is called then the UA should not display a
menu.
The script should have the possibilities though to activate the
links(menu entries),
resulting in the same behavior as clicking a menu entry.
The same should apply to the context menus too.

This would allow greater flexibility for UI design but not making
it more complex.


> 17.8.3 Security
> most do not allow access to hosts other than the host from which the
> document was retrieved.

a connection to "www.some-outher-domain.net/somescript.py?somedata..."
is not ok
but for example:
<image
xlink:href="www.some-outher-domain.net/somescript.py?somedata..." > is
ok !?

I do understand the reasoning behind not allowing cross domain access.
But is this really what the Internet is about?
I once understood it was about exchanging information, linking
documents...
I want to create a page which maybe loads a bunch of news feeds from a
bunch of news services using XML-RPC or SOAP or whatever.

These security guidelines somehow seam to me as if they are doing
exactly the opposite.
Which results in having to have a proxy for everything I want to do on
the server the SVG is served from...

> 17.10.4 Interface FileList
> Is there any need to provide for adding to the list?

<jk>Yes there is, so I can add files which the user did not select
(address book files, system files, ...) :) </jk>

> 17.10.8 Connection additions
> How does this interact with the encoding set on the Connection?

I consider a file to be binary data. Therefore the file's bytes should
just be sent to the socket as they are, no recoding should be done. I
guess.



Jan

Received on Monday, 1 March 2004 08:28:54 UTC