Re: Obsolete, deprecated, et al

On Aug 1, 2009, at 8:07 PM, John Foliot wrote:

> 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 actually disagree with that. I think meeting technical requirements  
is more important than the process of how we get there. But I don't  
think we need to debate that point.

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

I don't have any inside information on what "obsolete" means in HTML5,  
besides the text of the spec. You can check the spec for yourself if  
you are unsure of my interpretation. And if you think it's not clear  
enough, I am sure the editor would be glad to have that feedback.

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

Would you say then, that there is no technical issue besides the PR  
problem of the apparent conflict? (I'm not saying that concern  
shouldn't be addressed, I'm just trying to understand the issue.)

Incidentally, I searched WCAG 2.0 for mention of the summary=""  
attribute, and I could not find a reference, could you point me to the  
right section of the document? I looked at this document: <http://www.w3.org/TR/WCAG20/ 
 >.


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

Do you think it would help if HTML5 gave its own standalone  
definitions of "obsolete", "obsolete but conforming" and "obsolete and  
nonconforming"?

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

I think "deprecated" features are also discouraged. So I don't think  
that's a significant difference. If you're ok with a HTML4-deprecated  
summary="" attribute, I can't see a solid reason for being against an  
HTML5-obsolete-but-conforming summary.

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

Actually, neither <b> nor <i> is deprecated in HTML4.01. And lots of  
web developers continue to use them. So this is not a very compelling  
example. <u>, <applet> and <font> are deprecated elements - I don't  
think that status has had a significant effect on their use. I think  
most web developers don't even know which elements are deprecated.

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

All right, instead of "seen by many" I'll say I see it that way. I  
believe there are others who agree for me, but I'm not going to speak  
for them. That being said, my point is not to argue against having a  
category named "deprecated". What I'm saying is that "obsolete but  
conforming" is another name for essentially the same thing. And I'm  
trying to explain why that category isn't called "deprecated".

Regards,
Maciej

Received on Sunday, 2 August 2009 04:22:38 UTC