W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2010

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

From: <bugzilla@wiggum.w3.org>
Date: Mon, 22 Mar 2010 18:07:21 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Ntm25-0006Wj-Aa@wiggum.w3.org>

--- Comment #34 from Sam Ruby <rubys@intertwingly.net>  2010-03-22 18:07:20 ---
(In reply to comment #33)
> See 
> http://masinter.blogspot.com/2010/03/browsers-are-rails-web-sites-are-trains.html
>  for a take on why document and authoring conformance requirements are useful
> and what purpose they serve.

Conformance requirements that prevent trains from going off the rails are
clearly useful.  I will assert that not a single one of the following "errors"
fall into that category:


Example: google.com uses the "align" attribute on "td" elements.  More than a
few people use this site.  If this were to cause real-world problems, you would
think that there would be some evidence of this.

I believe that every single "error" reported on that page falls into the RFC
2119 definition of SHOULD: "there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different course."

I further believe that HTML5 could be significantly improved if the "errors"
that have nothing to do with keeping the train on the rails were removed from
the HTML5 specification, and placed into a separate specification.  The IETF
has an entirely sane process for this, it is called "Best Current Practices" or
"BCP". I believe that such a document could include "don't use presentational
markup, use CSS" as well as "explicitly close all open non-void tags".

These two documents could also proceed on entirely different schedules.

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 Monday, 22 March 2010 18:07:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:48 UTC