- From: Shelley Powers <shelley.just@gmail.com>
- Date: Sun, 21 Mar 2010 09:38:57 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTMLwg WG <public-html@w3.org>
- Message-ID: <643cc0271003210738r780a87f0m28a800019eb6a8b3@mail.gmail.com>
On Sun, Mar 21, 2010 at 9:09 AM, Maciej Stachowiak <mjs@apple.com> wrote: > > Consolidating replies... > > On Mar 21, 2010, at 6:36 AM, Shelley Powers wrote: > > Interesting reading the WhatWG IRC messages related to your effort. It > would seem that Aryeh Gregor also asked some of the similar questions Sam > asked: not what is a bug in the validator, or a specific misunderstanding, > but why is something non-conforming? What is the rationale behind the demand > for conformance? > > > I think those are good questions. I am personally more interested in asking > them about specific requirements than in general form. It seemed like Aryeh > at least felt that there may be good reasons for conformance requirements > besides interoperability, namely helping the author by spotting likely > mistakes, and user vigilance for such issues as nonstandard behavior. > > > It's just unfortunate that he picked on the alt attribute[1], which does > have a rationale for conformance. > > > Note that if we remove all authoring conformance requirements, as Sam > suggested would be an acceptable solution, that would include removing alt > requirements too. It also seems to me that the alt requirement does not meet > Sam's standard of affecting interoperability, though violating it will > likely result in a document that is broken for some audiences. > I may be wrong, and it's up to Sam to correct, but I didn't get the impression that Sam's acceptable solution is to remove all authoring conformance requirements. I thought, and Sam correct me if I'm wrong, that he was asking for the rationale behind the authoring conformance requirements. If there is no rationale for some, or many, then the authoring conformance requirement is based on one person's opinion. In particular, Sam wrote[1] "My request is for rationale. I assume there is a coherent strategy behind this, but I don't see it. Each time I take a closer look, I find what appears to me to be glaring inconsistencies." That's not asking for removal, but an understanding of the intent of the authoring conformance requirements, in particular since they seem to be applied in an inconsistent manner. Asking: what was the overall strategy is governing what is and is not listed as an authoring conformance is a genuine question to ask, and does not need to be broken into bits. There must have been some general concept, a basis on which each was defined. If we expect to deliver a rationale, consistent document, it's essential to have this understanding. We can't report what we perceive to be "bugs", if we don't understand what was the underlying basis for these decisions, because we can't determine if the item in question actually met this basic requirement, or not. We have to "guess" what is the purpose and the requirement, and frankly, having to do so is absurd. In the process of fulfilling my change proposals, I discovered there were some basic philosophies behind some additions to the HTML5 spec, such as details, progress, and so on. The philosophy is that using JavaScript is inappropriate, using CSS is inappropriate, and that all of these re-occurring behaviors should be packaged as HTML objects. By knowing this, by having discovered this by researching through way too many emails, WhatWG IRC entries, and the spec, I can then tailor my change proposals to pinpoint the rationale behind the additions. Unfortunately, I had to spend a lot of work doing this, because this rationale was not given when my bugs were declined. Or lets say, the rationale given was anemic, at best, and not reflecting the true philosophy that went into the introduction of these elements. Playing 20 questions is not the best use of this group's efforts. > > > On Mar 21, 2010, at 6:47 AM, Shelley Powers wrote: > > And you missed a reasonably popular site, Maciej: > > http://validator.nu/?doc=http://store.apple.com/us > > > http://www.apple.com/ is included. However, I did not include any deep > URLs (including subdomains) in the study. We could include selected deep > pages if that would be more informative, but I'm not sure I can do much more > than the current list without more help. > > Two other notes: > > 1) That page gets a significantly fewer errors when validated as HTML5: > > > http://validator.nu/?doc=http%3A%2F%2Fstore.apple.com%2Fus&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=html5 > > 2) http://www.apple.com/ also fail to validate, though no one has broken > down its errors in detail yet. > > Seems to me that when most of the web doesn't validate, and most pages generate hundreds of errors, we had better have a good explanation for why we're unleashing this _abundance of helpful information_ on the world, or risk losing credibility. If we don't understand why these items are errors, we're going to look like pedantic idiots. No offense to anyone intended, that's just how it's going to be. > Regards, > Maciej > > Shelley [1] http://lists.w3.org/Archives/Public/public-html/2010Mar/0457.html
Received on Sunday, 21 March 2010 14:39:31 UTC