W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

Re: [SVG 1.2 Tiny] play, stop, pause, resume on video

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Fri, 19 Sep 2008 20:20:43 +0200
To: Philippe Le Hegaret <plh@w3.org>, www-svg@w3.org
Message-Id: <200809192020.43842.Dr.O.Hoffmann@gmx.de>

Philippe Le Hegaret:
>
> Note that my point wasn't about the declarative methods at all, but
> about the uDOM. 

I noticed this, but if it just has another name in uDOM, I cannot
see the problem. And of course in SMIL audio and video are
'just' specific cases - no reason to invent for any element 
some new wording, the difference in SMIL between audio, video
and some others itself is only the name of the element. 
Unfortunately this is already different in SVGT1.2 and even
worse with 'HTML5'. In SMIL the different names for 
media object elements have mainly a semantical purpose,
but the same functionality - and this is very useful for authors
to express their intentions.

> In fact, in my use case, I need to make the videos 
> disappear after they're done playing or interrupted (and reappear if you
> start playing it again), 

I cannot see a problem to make something (dis)appear using a
declarative method, depending on some syncbase or time offset
or whatever, there are different methods available. And if they
are available with declarative methods, they are available for
scripting too, of course.

> thus I've been using the uDOM and not the 
> declarative approach. In any cause, pause isn't available using the
> declarative approach as far as I know.

SMIL has time containers, they can be combined with media
object elements to pause something for example.

For SVGT1.2 the 'tiny' already indicates, that the selection of
functionalities is restricted. Could be a good idea to adopt all
media object elements and time containers for SVG 1.2 to
get more flexibility for multimedia applications.
But any viewer has a general pause functionality for the
complete document, this is completely under control of the
user, not the author, this is pretty nice and useful.


>> I think, it would be much more useful to use declarative interactivity
>> in 'HTML5' derived from SMIL/SVG to get something more useful for 
>> HTML5:video and HTML5:audio, especially because HTML5 uses already
>> the same element names, what may cause even more problems,
>> if authors start to use compound documents with SVG/SMIL:audio and
>> SVG/SMIL:video inside (X)HTML(5) ;o)
>
> While I agree with you that a declarative approach would be a better, it
> can only get you up to a certain point. The shortcomings can only be
> compensated with scripting in the meantime. 

Not sure, typically I personally avoid user sided scripting and on unknown
pages I have it deactivated by default, therefore I have no practical 
experience with user sided scripting and have never seen an application
or problem that could not have been solved better without. Especially
I typically do not visit a page again, if it does not work - and obviously
for a first visit it is an unknown page, if have scripting switched off by
default - you see the problem with user sided scripting already, if a 
page does not work without anyway? ;o)
However, this might be different for interactive graphics, I don't know ...
Currently I do not look into the source code of any graphics not
looking somehow useful with my default settings, typpically I assume,
that it is arts and the intention of the author ;o)

> After all, that's why SVG 
> 1.2 Tiny has the uDOM, right?

Maybe because it is a chance to provide some additional accessibility
tools for people, who might need additional help and are quite happy
to get some, if they activate user-sided scripting ;o)
But I'm surely no expert for DOM applications ;o)
And it is more a question to accessibility experts how to use scripting
to provide additional tools to help people to get an alternative 
access to an application already working without scripting.

>
> Finally, declarative methods or not, it doesn't change the fact that the
> current definition in uDOM is awkward from a user point of view (note
> that I did not say broken, just awkward). I'm happy to agree that it's a
> minor fact that users will get over relatively easily but, as a user,
> play() is more attractive than beginElement() when doing videos.
>

As far as I understand this, if it is only a question of naming, then it
is a matter of taste and not a real problem.
Maybe some people like to 'play' with audio and video, other prefer
to 'begin' it and enjoy it up to the 'end' or if the do not like it, they want
to make an 'end' to the torture rather than just to 'stop' it ;o)
To cover this, a collection of aliases for the same functionality would
be required, maybe some others prefer to 'start' and to 'finish' or
whatever, and not to forget different languages: 'anfangen' and
'beenden' would be my preferred choice.

Olaf
Received on Friday, 19 September 2008 18:28:02 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:40 GMT