Some bugs filed based on conformance error study

I have started filing some bugs based on the conformance error study: <http://www.w3.org/html/wg/wiki/ConformanceErrorStudy 
 >. Though the breakdown of errors on the listed sites is not yet  
complete, a few frequent errors popped out as questionable. I have  
started filing bugs on these.


Since this has been a topic of interest for the group, I'm noting them  
here. Feel free to comment in these bugs, or discuss by email:

- "Make <nobr> element conforming" <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9349 
 >
- "Make <wbr> element conforming" <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9350 
 >
- "Make unescaped & conforming in attribute values in some cases" <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9352 
 >
- "Do not interpret & followed by an entity name followed by = as an  
entity reference in attribute values" <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9351 
 >
(This one is a proposed change to implementation requirements, not  
authoring requirements. It would reduce the possible risk from the  
change proposed in bug 9352.)
- "autocomplete=off should be allowed and should work on non-<input>  
form controls" <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9353>
(Would affect implementation requirements as well as authoring  
requirements.)
- "Leading/trailing whitespace in attributes that take a URL should be  
conforming" <http://www.w3.org/Bugs/Public/show_bug.cgi?id=9354>


Here are some common categories of errors I am unsure about:

- Presentational table attributes. Sam has a bug filed already about  
allowing some of these. It seems to me that cellpadding and the like  
do not harm accessibility, and depending on circumstances may not be  
less compact than the alternative.
- Presentational attributes on the body element. These seem unlikely  
to create accessibility problems. They can also only possibly occur  
once per page, and so  omitting them does not save compactness.
- Presentational attributes on iframe (frameborder, scrolling).
- Content model errors (bad element nesting). The spec does not give  
rationale for these rules, and I do not see a rationale myself in all  
cases, but I also do not see how any of the rules are problematic.
- <center> and <font> elements.
- Unknown <meta http-equiv> (content-style-type, content-script-type)
- img align / input align


Here are some categories of messages that, to me, seemed clearly like  
an error that should be flagged for one of the reasons stated in the  
spec:

- Unclosed tag, in cases where the element is not void and the close  
tag is not implied; these seem likely to indicate an authoring error.
- Almost standards / limited quirks mode doctype - triggers  
nonstandard behavior which may not be fully interoperable in legacy UAs
- autocomplete attribute on <input type=hidden> -- has no effect,  
perhaps contrary to author expectations.
- http-equiv X-UA-Compatible -- directly invokes non-interoperable  
behavior
- duplicate id (highly likely to cause problems down the road, if not  
causing them already)
- Unknown attributes and unknown elements - these have to be flagged  
to detect typos and to protect future extensibility of the language.
- bad attribute syntax - clearly an authoring error in context
- stray close tag - likely indicates an authoring error where the  
result is not what the author intended
- empty value for a@target attribute - has no effect, likely contrary  
to author expectations
- elements after </body> - seems likely to be an error in context,  
will result in DOM that author does not expect, not interoperable with  
UAs that have limited error handling
- Unscoped <style> inside <body> - will result in unexpectedly bad  
performance, since it causes a style recalc of the full page when it  
may have already been incrementally rendered.
- Misnested tags - results in bad performance, unexpected DOM,  
incompatibility with streaming or limited error handling UAs. Results  
in non-interoperable behavior in legacy UAs.
- Whitespace in name attribute - likely results in unexpected  
behavior, since name is treated as a single token with no whitespace.
- Whitespace in the middle of URLs - likely indicates an authoring  
error and/or will give unexpected results.
- charset attribute on inline <script> - has no effect, possibly  
contrary to author expectations


I plan to continue the study by classifying errors on the remaining  
listed sites. I will also continue to ponder the error categories I  
was unsure about. If anyone disagrees with me about any of the items I  
thought were clearly an error, please feel free to file those as bugs  
yourselves.


Regards,
Maciej

Received on Saturday, 27 March 2010 23:14:16 UTC