At 20:45 +0100 UTC, on 2007-02-25, Keryx Web wrote: > Henri Sivonen wrote: >> The semantics for the warnings, errors and fatal errors emitted by >> http://hsivonen.iki.fi/validator/html5/ are as follows:
[...] > A few examples that I think is bad practice (99.9 % of the time it's used): > > - Inline styles > - Empty p-elements, or p elements containing only > - A table within a table cell (Has this ever been used for anything but > layout?) > - Iframes > > Would I get a warning for any of these? FWIW, I wouldn't expect that from a "validator". A validator only checks for validity, not for "good behaviour"[*]. If a spec allows an empty <p>, than an ampty <p> is valid. That's not to say that a tool cannot warn of such things, just that it doesn't fall under "validation". I believe HTMLTidy has something to offer on this terrain. iCab also has. Other than that I can't think of one right now. There is certainly room for improvement in this area. A tool that provides this sort of feedback would be helpful for web publishers, and for teachers/students. Authoring tools could have this sort of thing built-in, to help people avoid the sort of ugly markup you mention (without bothering the user unnecessarily -- an empty <p> can safely be stripped silently, for instance). For a standalone tool, all you can do really is return errors/warnings. But when you embed such a tool in an authoring system, you could make things user-friendlier by having the authoring tool silently take action based on output of the 'validator'. For instance, silently stripping empty <p> elements is unlikely to be a problem. With this approach users wouldn't have to be bothered with at least some category of problems and are thus more likely to accept erros/warnings that do require the user to take action. For a teaching situation OTOH you probably should be confronted with any and all errors and warnings explicitly. -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>