Re: 3rd call: CSS2: howto disable audio?


"this is not relevant to the test cases you have posted here."

sums up the issue as well as it could.
the issue is that specifications, whilst not created irrespective of  
each other, aren't necessarily able to foresee usage.

the fact is that without some change it's possible and even likely  
that we could all receive massive amounts of unwanted audio spam on  
spam audio that it seems could be hard to control.
especially given that users may chose to disable client-side script  
for precisely this type of reason.


Jonathan Chetwynd

On 24 Jul 2007, at 09:44, fantasai wrote:

~:'' ありがとうございました。 wrote:
> Fantasai,
> that's all too easy an excuse, aka passing the buck.
> I do take your point, but however dont agree that it's necessarily  
> only a plugin issue.

Then show me a testcase where it's not a plugin issue.

> for instance it's likely the plugin - can - raise an interface that  
> provides a means to disable.
> However the author may chose to make this very small, off screen,  
> or not visible.
> it's also true that the user agent, application or browser may  
> provide an audio interface.
> furthermore client-side script can be used to play audio.
> However as the current functioning W3C specifications are designed  
> in such a way that CSS provides sound on event, which is a  
> reasonable expectation; is it not a sensible expectation that there  
> should equally be a way for CSS to disable or prevent audio?

See, now you're saying that CSS is controlling the sound of your plugin.
This is not the case. The W3C specifications do not say whether the  
provides sound or does not provide sound. The W3C does not standardize
plugins. The CSS specifications talk about whether the 'play-during'
property provides sound, and you can override /that/ in a user style  
but this is not relevant to the test cases you have posted here.


Received on Tuesday, 24 July 2007 20:42:38 UTC