- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 24 Jul 2007 04:44:51 -0400
- To: ~:'' ありがとうございました。 <j.chetwynd@btinternet.com>
- CC: www-style@w3.org, Bert Bos <bert@w3.org>, public-cdf@w3.org
~:'' ありがとうございました。 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 plugin 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 sheet, but this is not relevant to the test cases you have posted here. ~fantasai
Received on Tuesday, 24 July 2007 08:45:01 UTC