Re: AuthConfReq: Presentational Markup

On Mar 31, 2010, at 1:51 AM, Henri Sivonen wrote:

> "Jonas Sicking" <jonas@sicking.cc> wrote:
>
>> 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.
>>
>> This not only saves us a bunch of work, it also gives lint tool
>> authors more freedom to develop whichever practices that they deem
>> suitable.
>
> Leaving the definition of document conformance criteria to "lint  
> tool" developers doesn't remove the need to think through the  
> definition. It just makes it Someone Else's Problem.

Someone Else may even still have to be this Working Group, since one  
of our charter success criteria is "Availability of authoring tools  
and validation tools". I do not think a tautology machine would be a  
meaningful fulfillment of this success criterion.

>
> I'd still expect markup generator developers to want the criteria to  
> be such that the output of their products isn't considered to be in  
> error by lint tools. If this expectation is correct, there's still a  
> need to come to mutual agreement on the rules--i.e. to standardize  
> them. Kicking that standardization work out of this WG would only  
> have the benefit that developers of products that are exclusively  
> markup consumers wouldn't have to watch how the document conformance  
> sausage is made. But even browsers these days are also producers:  
> For example, the contentEditable feature set should probably be  
> informed by document conformance criteria.

I would also add that at least a subset of the document conformance  
criteria are important for documents to be interoperable with user  
agents. Even if every fully HTML5 compliant browser handles arbitrary  
octet sequences in an interoperable way, we still have to consider:

- Constructs which are known to result in non-interoperable behavior  
in legacy UAs. And by "legacy" I mean "all the ones available now".
- Constructs which are known to result in non-interoperable behavior  
for non-browser classes of content consumers, even ones that are fully  
HTML5 compliant, but either do not implement all of the optional error  
handling, or operate in streaming mode.
- Construct which may stress weird corner cases even in largely  
compliant UAs, and therefore are more likely to fall into buggy and  
non-interoperable territory.

In other words, any content we label "conforming" needs to  
interoperate with not just fully compliant and fully capable HTML5  
browsers, but also implementations that are not fully compliant or  
fully capable in various predictable ways. This is a simple  
application of Postel's Law. I used to think that we could get away  
with removing all authoring conformance requirements, but the above  
considerations have changed my mind.

I now believe that requirements that address the above points are the  
bare minimum position that is at all tenable.

Granted, this is a considerably smaller set than the full set of  
conformance criteria in the spec currently. But I think this has to be  
the minimum baseline, rather than no document requirements whatsoever.


The other types of reasons given for document conformance criteria are  
to prevent harm to the author, or to discourage authors from creating  
various kinds of negative externalities. I can see how those are less  
of a slam dunk. In fact, I filed a number of bugs recently about  
authoring conformance criteria in this category. But I suspect at  
least some criteria in these categories will enjoy wide consensus.


Regards,
Maciej

Received on Wednesday, 31 March 2010 09:18:05 UTC