[Bug 7034] authoring conformance requirements in the spec should either be removed or replaced

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034





--- Comment #24 from Sam Ruby <rubys@intertwingly.net>  2010-03-14 20:49:59 ---
(In reply to comment #21)
> (In reply to comment #20)
> > At the present time, the only effective means by which a working group
> > participant can obtain a rationale for why any given restriction is included in
> > the spec is to file a bug and ask for that restriction to be removed.  In this
> > case, we have a large number controversial restrictions for which there is no
> > single place that a person can go to find the answer as to why those
> > restrictions were put in there in the first place.
> > 
> > I'm open to proceeding with a separate bug or change proposal for each
> > attribute or element that is commonly used, or with a single omnibus bug report
> > such as this one, or with escalating this as a single issue.
> 
> My recommendation:
> 
> At the very least you should list the specific changes you're proposing.
> Ideally a separate bug for each (so we can have a clear record in bugzilla of
> which were accepted and which were reected)., but listing them all in this bug
> would still be an improvement on the current state. Given the current contents
> of the bug, it's not possible to tell what kinds of changes would satisfy your
> request.
> 
> However, one bug per issue is even better than an "omnibus bug report". One bug
> per issue is good because the requests can be fielded individually, and we end
> up with a clear record of which requests were accepted or rejected and why, and
> which change was made for each.

I think that there are at least two "classes" of bugs.

One deals with using conformance criteria to selectively prefer stricter syntax
in order to reduce errors.  Always quoting attributes, always explicitly
closing open tags, and always escaping ampersands in content are three examples
of such features which have been requested, only one of which has been adopted
by the current specification.  The number of such cases to consider is quite
small.  (Another example would be the fact that double dashes are not allowed
in comments).

A second deals with using conformance criteria to enforce one common approach
to style, namely CSS.  In total, there are literally dozens of attributes
and/or elements which are deprecated for this reason.

> (In reply to comment #20)
> > I will suggest that http://google.com/ as a starting point.
> [...]
> > At the present time, the HTML5 validator produces 47 messages -- some of them
> > warnings, most of the errors -- on that page.  I believe that the optimum
> > number is zero.
> 
> Would turning all of these errors into non-errors be necessary and sufficient
> to satisfy your request? If so, that should be sufficient information, and
> there would be no need to list which rules you think should change in more
> detail (though it would be useful to paste in the current error log in the bug
> for reference).

Google is just one example of a high profile site, though it is one that has
chosen to adopt the HTML5 Doctype and has yet to adopt the conformance
criteria.

So: necessary?  Probably, though there may be one or two cases that can be
defended.  Sufficient?  Unlikely, but I do believe that a point of diminishing
returns would occur after the first few dozen sites.

The goal would be to make HTML5 an inviting place, where the actual error
messages produced by the validator indicate places where something unlikely to
be intentionally done was encountered in the document.  Over top of this can be
additional checks that the author can opt into should they desire, and we could
discuss various alternative methods by which one could opt in.

Finally, by making the controversial checks opt-in, we have the possibility of
significantly reducing the number of open issues:

http://lists.w3.org/Archives/Public/public-html/2010Mar/0314.html


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 14 March 2010 20:50:01 UTC