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, 15 Mar 2010 01:42:11 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1NqzJr-0006EY-FR@wiggum.w3.org>

--- Comment #25 from Maciej Stachowiak <mjs@apple.com>  2010-03-15 01:42:10 ---
(In reply to comment #24)

> 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.

It would definitely be helpful to have at least one bug per "class" of proposed
removals, additions, changes, or modifications of status from mandatory error
to optional check.

> > 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.

OK, sounds like we need more details on what conformance criteria you propose
adding, removing, or making optional. If there are thematically related sets
(like "all presentational attributes and elements" or "proposed optional checks
for stricter XML-like syntax") then one bug per set would be fine, but ideally
it should still define what's in it.

Note: I have no particular interest either way in any of the types of changes
you have described. I simply want bugzilla to end up with well-defined,
actionable bugs. Right now this bug report amounts to "please add and/or remove
some conformance criteria" with hints of the kinds of changes to make, but not
enough detail to determine what set of changes would be sufficient.

> 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

Out of the issues that deal solely with document conformance, it doesn't seem
to me that any fall into the categories you described above. (Out of the 12
issues that are purely about document conformance, I see 2 about making HTML4
accessibility features conforming again, 4 about making legacy metadata
conforming, 2 about changing the mechanics of registries from wiki to something
else, and 4 that propose adding new more restrictive conformance requirements
on content models.)

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, 15 March 2010 01:42:16 UTC

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