- 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
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 UTC