- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 21 Jan 2010 16:12:26 -0800
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Matt May <mattmay@adobe.com>, HTML WG <public-html@w3.org>
On Jan 21, 2010, at 6:20 AM, Shelley Powers wrote: > On Thu, Jan 21, 2010 at 2:44 AM, Jonas Sicking <jonas@sicking.cc> wrote: >> I don't understand why we would *forbid* UAs from improving image >> accessibility by whatever means they can. >> >> However I do agree with the change proposal in that I would be fine >> with removing the current text. However I would suggest replacing it >> with a general statement that UAs are allowed to improve accessibility >> in any way it can. Even if that goes against the letter of the spec. >> >> This is similar to how I think the spec should say that UAs should be >> allowed to deviate from the spec for security reasons if the UA so >> desires. >> > > That's a dangerous precedent to take. > > If a UA sees the potential for security risks in any of the specs, it > should be working, now, to ensure the component leading to the risk is > removed, or altered. My own feeling is that what Jonas says makes sense for accessibility, where making the best effort to give meaningful access to the content is more important than exact alignment on behavior details. It might even be worth an explicit sentence or two somewhere. But I'm not sure it makes sense for security to be treated the same way. It seems like having such a requirement would make it almost impossible to have a valid test suite, since there's no way to check whether a UA's intent in breaking a MUST requirement was security. It would effectively turn every spec requirement into a SHOULD. I think the right way to handle security issues with the spec is to violate the spec if necessary (since UAs will do that anyway), and seek a spec change. I don't think it is either necessary or sensible for the spec to grant license to violate itself. Regards, Maciej
Received on Friday, 22 January 2010 00:13:00 UTC