- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 08 Jul 2009 00:13:52 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Ian Hickson <ian@hixie.ch>, public-html@w3.org, wai-xtech@w3.org
- Message-id: <41ACB343-CA2F-4EC8-8072-08076D7E7467@apple.com>
On Jul 8, 2009, at 12:00 AM, Henri Sivonen wrote: > On Jul 7, 2009, at 03:10, Maciej Stachowiak wrote: > >> The actual material difference between different diagnostic classes >> is not friendliness in the validator, but rather whether authors >> can still use the feature if they have a requirement (self-imposed >> or otherwise) to produce fully conforming content. >> >> Thus, I think a suggested non-error diagnostic would be better than >> a requirement for a down-played error, in that it would give the >> advanced experts who choose to disregard the warning the >> opportunity to have their content be conforming. > > > I don't really like spec-prescribed warnings, either, because I fear > that if we start doing normative warnings, people start wanting to > make failures to adhere to their code style aesthetics as normative > warnings when the discussion won't affect valid/invalid. I think that would be a bad way to use warnings, and I hope that won't happen. If we do introduce them, they should be reserved for things where there is a strong reason to discourage a practice or alert authors to pitfalls, but there are sufficient exceptions that making such content blanket invalid would be excessive. Basically the rough equivalent of a SHOULD NOT. Matters of aesthetics would not qualify. I would hope there is broad agreement on this. I also think validators should be free to have ways to turn off some of the otherwise mandatory or spec-suggested warnings, or alternately to treat warnings as fatal at the request of the user - the rough equivalent of -Wno-foo and -Werror in gcc. I think this will further reduce the temptation to use warnings for inappropriate purposes. Regards, Maciej
Received on Wednesday, 8 July 2009 07:14:38 UTC