Re: Please put in interim text for the ISSUE-204 statement about exposing semantics of hidden content

On Sep 15, 2012, at 2:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Sep 12, 2012 3:14 PM, "Maciej Stachowiak" <mjs@apple.com> wrote:
> 
> > That example makes me lean even more towards my previous suggestion (which you snipped) - which is to update the spec when and if the future condition we imagine actually occurs.
> 
> Does that then mean that we should add a warning statement to any feature which doesn't have accaptable fallback a warning statement that the feature shouldn't be used?
> 
> I.e. should we add this to most of the new <input> types? To pushState? To <video>? To <nav>?
> 
> If not, what criteria are we using to dtermjne which new features get a warning?
> 
> Should we add it to headers and longdesc given their poor adoption in non-AT UA
> 

I'm not sure I buy your logic to a general rule. Some thoughts:

(1) There are many times the spec tells authors that they SHOULD NOT or even MUST NOT do something that will in fact work interoperably in all UAs the implement the MUST requirements in the spec, in part for work around historic quirks. Do you think it is reasonable for the spec to do that? 

(2) I think the difference between the cases in point #1 and the examples you cite is whether there is a practical approach to graceful degradation. <video> can contain an <object> in its fallback; <input> types fall back to a text field; <nav> falls back to being a generic container. The SHOULD NOT requirement we are talking about here is specifically to only use content that will degrade gracefully. So you can use all the structured content you want, as long as it works well (does not "lose essential meaning") in a flattinging UA.

(3) I don't know of any existing cases where the spec gives a conformance requirement (even SHOULD-level) that changes based on some future condition. I don't know if you are still advocating that, but it strikes me as weird. We should publish frequently, and deal with the future when it arrives, in my opinion.

(4) In this case, the spec isn't even creating a MUST requirement on UAs, just a suggestion, and at least one implementor (Microsoft) has stated that they are not sure they can practically implement it. So it's presumptuous to assume the expected future condition will come to pass.

As for your specific examples of headers="" and longdesc="" -

* If you can think of a SHOULD NOT requirement on headers="" usage (short of SHOULD NOT use the feature at all) that would make it work better in more UAs, please suggest it, I bet the editors would be open to it.

* longdesc="" is not currently in the spec. But it's a valid point of feedback that it may merit some sort of warning about the level of UA support, if it does get added.

Regards,
Maciej