Re: [DRAFT] Heartbeat poll

John,

I hope you will forgive me for skipping over the procedural issues,  
because I'm personally much more interested in the technical solution.  
So let's focus on that.

On Aug 1, 2009, at 6:20 PM, John Foliot wrote:

>
> And the requested feedback has come forward.  However, I will  
> reiterate
> *my* concerns once again:
>
> 1) the truthiness[1] of the 'proof of harm' has been disputed by  
> many, and
> alone is not a reason for making the attribute obsolete.  AS PFWG  
> noted:
> "We note that accessibility is poorly supported on most web sites. The
> wider web is not an example of good practice." Sufficient examples  
> of the
> proper use of @summary have been delivered to the working group to  
> prove
> that it serves a unique and needed function today.

I think the current draft allows use of @summary for those who feel  
they can use it correctly. That's a change from before, when it was a  
conformance error. I think the conforming-but-obsolete state allows  
@summary to serve its function, in cases where the recommended  
alternatives don't work.

[... snip discussion of procedural issues ...]

>> Thanks for making an alternate proposal. What do you think is the
>> substantial difference between "deprecated" and "obsolete" status? To
>> me they seem like pretty much the same thing. It's allowed, but not
>> recommended.
>
> The current W3C definition of deprecated and obsolete can be found at:
> http://www.w3.org/TR/html4/conform.html#deprecated
>
>  "Deprecated: A deprecated element or attribute is one that has been
> outdated by newer constructs. Deprecated elements are defined in the
> reference manual in appropriate locations, but are clearly marked as
> deprecated. Deprecated elements may become obsolete in future  
> versions of
> HTML."
>
>  "Obsolete - An obsolete element or attribute is one for which there  
> is
> no guarantee of support by a user agent. Obsolete elements are no  
> longer
> defined in the specification, but are listed for historical purposes  
> in
> the changes section of the reference manual."
>
> By my reading there are significant differences between either  
> state. If
> WHAT WG does not make these distinctions then could you kindly point  
> me to
> the WHAT WG definition of both or either term? (This might be an  
> existing
> hole in the Draft Specification that perhaps needs to be plugged?)

OK, now I understand. HTML5 does not use the terms "deprecated" and  
"obsolete" in the same way as HTML4. I can see how the HTML4 sense of  
"obsolete" would not be satisfactory. Just to be clear though - those  
are HTML4 definitions, not W3C-wide definitions.

HTML5 does not have a category of "deprecated". It only has  
"obsolete". I'm not sure if there is a standalone definition of  
"obsolete", but it has the following characteristics:

- Obsolete features are all mandatory to implement (or in a few cases  
optional) for user agents. That's different from HTML4, where there is  
no guarantee of support.
- Obsolete features are defined in the specification - they are not  
just listed for historical purposes.
- There are two subcategories of obsolete features, nonconforming and  
conforming.
    - For the nonconforming category, there are implementation  
requirements but the feature is disallowed for content authors.
     -For the conforming category, the spec says:

    "To ease the transition from HTML 4 Transitional documents to the  
language defined in this specification, and to discourage certain  
features that are only allowed in very few circumstances, conformance  
checkers are required to warn the user when the following features are  
used in a document."

So the HTML5 category of "obsolete but conforming" is actually much  
closer to HTML4's "deprecated" than HTML4's "obsolete". You can count  
on an implementation being there, but use of the feature is discouraged.

The reason HTML5 doesn't have a "deprecated" category is that marking  
something "deprecated" seems to have little practical effect.  
Implementations still have to support it, conformance checkers don't  
necessarily give any guidance, and authors are not in practice  
discouraged. HTML5's "obsolete but conforming" is an attempt to create  
a category that's a little more effective than "deprecated".

It might be helpful for HTML5 to use a different word than "obsolete",  
but I think most people are not familiar with the details of HTML4  
obsolete, and the word "deprecated" is seen by many as poisoned by its  
past ineffectiveness.

>
>>
>> This is a good idea. Someone should propose a change to WCAG2 based  
>> on
>> the data collected on summary="".
>>
>
> I am sure that WAI and the PFWG would listen very carefully to  
> anything
> the HTML WG might offer as a constructive observation and  
> recommendation.
> I invite you to make such a proposal; WAI welcomes input and  
> comments from
> all sources and can be reached in a number of ways:
> http://www.w3.org/WAI/contacts#documents

I would prefer if someone directly involved in the data gathering  
could make the case to WAI, and I would be glad to support them in  
doing so.

>
>>
>> I do appreciate it. And I appreciate that you made an alternate
>> compromise proposal. What I'd like to understand now is why a
>> "deprecated" summary attribute would meet your requirements, but an
>> "obsolete" one would not. Is it just the particular word and how
>> judgmental it sounds? Or do you see some other difference?
>
> Hopefully the W3C definitions I quoted make the difference clear.
> Deprecating @summary makes it suitable for use today, and allows  
> WCAG 2 to
> remain true to its guidance - deprecation however also signals that
> @summary's days will likely come to an end, so that if/when WCAG 2  
> comes
> up for review the reviewers will be advised that the current guidance
> needs to be modified.

Yes, I now understand your position. But I think HTML5 is using  
"obsolete" in a very different way. Do you think the HTML5 sense of  
"obsolete but conforming" meets your requirements better than the  
HTML4 "obsolete"?

I feel that some of the disagreement here may have been due to a  
misunderstanding, based on different definitions of "obsolete".

Regards,
Maciej

Received on Sunday, 2 August 2009 01:59:59 UTC