Re: AuthConfReq: Presentational Markup

hi maciej,
"- 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. "

Can you indicate whether the above statement applies to users agents
such as assistive technology?
I ask this question because there are conformance requirements in
HTML5 which are not compatible with the behaviour of currently used
assistive technology and do not appear to take into account the
negative consequences for users of one class of user agents (AT) which
rely upon the output of another class of user agents (browsers).

Am i right in considering this as an interoperability concern?

with regards
stevef

On 31 March 2010 10:17, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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
>
>
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html

Received on Wednesday, 31 March 2010 09:37:11 UTC