Re: issue-30 and author conformance requirements

On 07/13/2010 05:07 PM, Jonas Sicking wrote:
> 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?

Very much so.  Thanks!

Pressing forward, I'm reasonably confident that what I am about to say 
represents your opinion -- not necessarily anybody else's in the working 
group, but quite likely yours, based on your previous posts to this 
mailing list.  I say the following in the spirit of seeking the minimum 
necessary to achieve victory, where victory is amicable consensus:

(1) If instead of simply removing the concept of 'valid HTML' from the 
spec currently named HTML5, A vocabulary and associated APIs for HTML 
and XHTML; if this information were placed into a separate spec you 
would not object to that movement, whether that be a new spec entirely 
or be it one of the other specs that the working group is producing.  In 
fact, if it were to be a new spec entirely, you would not object to a 
FPWD of that spec.

(2) Without assessing the strength of your stated objection, it would be 
fair to observe that the objection only applies to whichever document, 
if any, actually defines the concept of 'valid HTML'.  In particular, in 
the scenario described by (1) above, you would not longer see issue 30 
as being a blocker of http://dev.w3.org/html5/spec/.

(3) Should you happen to agree with (2) above, it seems reasonable to 
infer that this may apply to others issues currently in the system.  To 
take two examples from the list that Paul Cotton recently published as 
"issues ready for survey processing", it seems reasonable to me to 
assume that you would not see issues 4 (html-versioning) nor issue 84 
(legacy-doctypes) as being blockers of any version of 
http://dev.w3.org/html5/spec/ that does not attempt to define 'valid HTML'.

At this point, I should probably pause.  I've made a fair number of 
assumptions.  I'd like to ask Jonas first if this matches his opinion. 
If not, I would be interested in hearing how your opinion differs. 
Alternatively, should it match Jonas's opinion, I would then be 
interested in hearing what other people think.

The background is that the HTML co-chairs and W3C staff are discussing 
potential schedules for last call.  Given current course and speed, and 
taking into consideration various blackout periods and holidays, getting 
to last call for this document in this calendar year seems unlikely.

What I am wondering and would like to explore is any alternative that we 
may have to waiting until each and every issue is resolved before 
proceeding to last call.  In particular, I am wondering if we can find a 
split of the spec (not necessarily the one described above) that lets us 
focus on a subset of the issues.

I'll note that the split above does not address all of the issues.  Even 
with this split, there still remains issues such as issue-9 
(video-accessibility) that will need to be resolved prior to last call. 
  However, I will note that the split does get the portions of the spec 
of greatest interest to browser vendors to last call the quickest.

And I'm curious if such a plan would be of interest to others.

> / Jonas

- Sam Ruby

Received on Wednesday, 14 July 2010 00:58:06 UTC