Re: issue-30 and author conformance requirements

On Tue, Jul 13, 2010 at 1:46 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> In [1], I note that you close your objection with:
>
>> By making longdesc non-conforming in this version of HTML, we can
>> likely remove it in future versions, thus freeing up implementors time
>> to work on other accessibility features, as the usage out there is
>> doesn't seem to be large enough that it will forever be unfeasable to
>> remove it from HTML.
>
> I'd like to hear how you reconcile this with your prior (and repeatedly
> stated opinion), such as [2]:
>
>> My personal opinion, which I think I stated a long time ago when Rob
>> Sayre first brought up this topic, is that I'd prefer to get rid of
>> all the authoring conformance requirements.
>>
>> There simply is too much controversy for too little value to make this
>> worth it for us. Instead we should leave it up to lint tools to create
>> best practices.
>
> I can speculate a number of ways to reconcile these two statements, but I'd
> rather not speculate.  I would prefer to actually hear from you how these
> statements relate.  If you think that others could benefit from this
> clarification, you are welcome to copy public-html on your response.  In
> fact, I encourage you to do so as I would also be interested in whatever
> discussion your response may spark.

The short answer is: If we're going to define what is valid HTML and
what isn't, then we should make it a useful definition. But in the
interest of saving ourselves time, I'd prefer to remove the concept of
'valid HTML' from the spec.

The somewhat longer answer is: As long as we define a "valid HTML"
mechanism, we might as well take advantage of it and use it when we're
going through the process of deprecating a feature. In the process of
telling authors that they no longer should use the given feature, we
can point to the HTML5 specification and tell them "see, the web is
moving away from this feature, you should too".

Conversely, if HTML has a definition of "valid HTML", and that
definition includes a feature that we want to deprecate, we'll have a
harder time doing so. Then authors are going to point to the spec and
say "see, HTML5 has this feature, you should add support for it. In
fact, I'm going to go write a HTML5 test suite and add this feature to
it and deduct points for not supporting it". This isn't a theoretical
problem, the main argument that we hear for adding SVG Fonts support
to Firefox is "It's needed for the last acid3 points" and "It's in the
spec, you should support the spec".

Note that none of the above contains any technical arguments. In
neither of the two "longer answer" paragraphs. It would be much better
if people said "This feature is useful as it's the best way to do X,
you should add support for it. In fact, going to go write a HTML5 test
suite and add this feature to it and deduct points for not supporting
it". But that's not what currently happens.

This is why I'd like to remove the concept of "valid HTML" from the
spec, and instead explicitly say that some features are in the spec
purely for backwards compatibility. That would give us an easier time
to argue on technical grounds that some features should be deprecated
and eventually removed. This would also give us an easier time to
produce lint tools which warns about features that, while still
supported by the spec, should be avoided. Right now that is more
politically charged since many times they would diverge from the
recommendations of the HTML specs.

Hope that answers your question?

/ Jonas

Received on Tuesday, 13 July 2010 21:08:31 UTC