Obsolete, deprecated, et al

Maciej Stachowiak wrote:
> 
> 
> 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.

Fair enough, so long as you understand that the process and procedure that
are underlying this discussion are paramount to resolution.

> 
> I think the current draft allows use of @summary for those who feel
> they can use it correctly.

That's what you think [*], but you are in the most inner circle of the
drafting of this spec.
[* thinking and knowing because it specifically says so are 2 very
different things]

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

After reading your explanation of obsolete in HTML 5 (which, for the
record is normatively defined where?) I can see how you have reached your
current position.  However, the Draft also goes on to say explicitly:

	"Authors should not specify the summary attribute on table
elements."

Which to me is the larger problem.  This is not in accordance with WCAG 2,
and in fact directly contradicts WCAG 2.  The average Joe Developer on the
web reads "Obsolete" and "...should not specify..." and walks away
wondering why HTML 5 says one thing and WCAG 2 says the completely
opposite.  This is not a technical problem, it is a PR problem. 

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

They are the only HTML related definitions that anyone can point to at W3C
- they also apply to XHTML1 (and I believe, but will not state
categorically, apply to earlier version of HTML as well - Dan C if you are
following this?)

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

...because there was the intermediary step of Deprecated which still
required 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.

Based on your non-normative explanation however, the failure is with the
"discouraged" aspect of HTML5's Obsolete.  WCAG 2 "encourages" the use of
@summary and gives specific guidance and explanation of its usage.  

Making @summary obsolete and invoking the "discouraged" aspect is counter
to WCAG 2 and is thus the reason for *not* making @summary obsolete.
Again, this is not a technical problem, it is one of PR and perception -
we simply cannot have 2 W3C documents officially disagreeing with each
other. It sends the wrong message.  Since WCAG 2 is a Final Recommendation
it is the Working Draft that must step back and re-align, and not
vice-versa.

> 
> The reason HTML5 doesn't have a "deprecated" category is that marking
> something "deprecated" seems to have little practical effect.

The majority of savvy web developers I've encountered have a passing
awareness of what deprecated means. Standard aware developers long ago
stopped using <b> and <i> because they knew that these elements were
deprecated in HTML 4.  You know this to be true as well as I do and is
proof of the practical effect it had.

> Implementations still have to support it,

You just finished stating that obsolete but conforming meant: "You can
count on an implementation being there..." - isn't this now the splitting
of semantic hairs?

> conformance checkers don't
> necessarily give any guidance,

How is that currently the fault of 'deprecated'?  I am sure that Henri
could cook that up in under a day... in fact he's had to spit obsolete
into two categories, an issue he was (by accounts) none-too-happy with...
[http://lists.w3.org/Archives/Public/public-html/2009Jul/0467.html ] 

> and authors are not in practice discouraged.

However, specific to @summary, WCAG 2 (and I) do not want to discourage
authors from using this attribute - we would prefer to teach them how to
do it right.  Again, this is not technical in scope, it is once again
about perception and about who is actually the right working group to
speak to accessibility techniques.  The current HTML 5 design appears to
be offering multiple ways of attaching the required information to a table
(+1), but the technical specification strays into 'techniques and
guidance' that is outside of its realm, and contradicts approved W3C
Recommendation (read Standard) (-1).

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

Can you defend that statement beyond anecdotal?  I've never heard someone
suggest that 'deprecated' was 'poisoned by its past ineffectiveness'.
Burden of proof (please).

> 
> 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 believe it is the responsibility of those who are adamant that @summary
is harmful to make their case.  Ian feels strongly enough that he to date
has still not modified the current Draft Text - perhaps he should do so -
I'm sure given his position his thoughts would be taken very seriously.  I
too would support the notion of WAI revisiting their guidance within WCAG
2 on this issue, if my vote of support is worth anything - it would be of
great benefit to all to also point out within WCAG 2 other means of
delivering support to users that have emerged in HTML5 (and for that
matter ARIA too).

> 
> 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"?

Partially, but in respect to @summary it only strengthens the case to move
it back to fully conformant at this time, as the WCAG 2 Official
Recommendation says that authors should use @summary.  From a technical
perspective it is a non-issue for browser implementers to deliver, as they
already do so due to @summary's legacy status in HTML 4.  Where is there a
technical issue?

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

You have helped clarify how WHAT WG perceives 'obsolete', and have perhaps
also identified an important need within the Draft Spec (clearer
definitions), so this dialog has been fruitful.  I am not sure if it
solves the greater problem at hand however, although it does frame it
clearer.

JF

Received on Sunday, 2 August 2009 03:08:03 UTC