- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 12 Mar 2010 04:03:56 -0800
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Henri Sivonen <hsivonen@iki.fi>, Julian Reschke <julian.reschke@gmx.de>, Ian Hickson <ian@hixie.ch>, HTMLwg <public-html@w3.org>
On Mar 12, 2010, at 3:18 AM, Sam Ruby wrote: > Maciej Stachowiak wrote: >> Putting it in the spec would require a bunch of negotiation over >> the exact set of rules and would likely lead to controversy no >> matter what set of rules is picked. > > As co-chair: I don't believe that such a negotiation is out of > bounds for this working group. In particular, I don't believe that > we are stuck with the set of rules that have been picked for us. > The set of rules are for the group to determine. I'm not saying it's out of bounds. I'm just saying that this particular category of change (making text/html that has an xmlns declaration on the root element trigger different validation rules) does not strike me, personally, as a great use of the group's time. Others are of course free to make their own judgment. I suspect a polyglot validator mode would be more useful for this kind of markup, in addition to being something that can be rolled out without the need for this committee to design it first. > > With co-chair hat off: I am not happy with the current set of rules. > But if you like, we can start the discussion from the other side > then. I would like to ask why the following is considered non- > conforming: > > <a href="http://images.google.com/imghp?hl=en&tab=wi"> > > The above markup causes no interoperability problems. This is a > rule that is commonly, flagrantly, and willfully violated. A number > of similar examples can be found here: > > http://html5.validator.nu/?doc=http%3A%2F%2Fgoogle.com%2F > > Removing all rules that cause no interoperability problems would > also be an acceptable solution to me. I don't have a particular opinion about this conformance rule either way. I don't really see a relation to your other suggestion. Personally, I could see a case for removing all authoring conformance requirements from all of our drafts. Authoring conformance requirements cause a disproportionate amount of controversy in the group, while not having nearly as much effect on what authors can do as implementation conformance requirements. And clearly defined implementation requirements for error handling But it seems to me most people are not satisfied with that approach, for reasons that seem plausible to me. Given that, my preference is to fuss with authoring conformance as little as we can manage. But I'm not going to deny anyone's right to propose changes to it. Regards, Maciej
Received on Friday, 12 March 2010 12:04:31 UTC