Re: issue-30 and author conformance requirements

On Tue, Jul 13, 2010 at 5:57 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> 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.

That is correct.

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

Indeed, it would be a blocker for the new 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'.

Issue 4 is tricky. Any future versions of HTML that introduce
versioning would affect the spec at http://dev.w3.org/html5/spec/ . So
it's possible that no matter what we'd explicitly want to explicitly
say that HTML does not currently use versioning.

But I agree on issue 84.

> 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 think an alternative way to increase the speed of development would
be to make the decision process more lightweight. But that's for a
separate thread I suppose.

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

I don't think the above statement is true for mozilla. We don't just
care about building a web browser, but also about making the web a
good place for users and authors. While I can't speak for other
browsers vendors, I expect this is true for at least some of them.

/ Jonas

Received on Wednesday, 14 July 2010 16:41:32 UTC