I am basing my definition of this term "deprecate" on previous work in
standards groups. My understanding is that "deprecate" is only phase
one, where "obsolete" is phase two, and this second phase _may_never_
_come_. My (non-legalese) definition of this "deprecate" phase is:
"document writers should no longer use this, the standard should
not propose any changes to this, but browsers should continue to
accept this."
The idea is to have such a better new way to do things that people stop
using the old (deprecated) way for all newly created documents, and the
language group stops tinkering with the old way in the standard, but
focuses efforts on the new (supposedly) better way. Since I believe
that my proposal for LIST is a better way (IMHO ;-) I feel sure that
the usage of these old list constructs will simply fade away, but
existing documents that use them will still be renderable by browsers.
When (or even if) an element is identified as "obsolete", then it
is possible for newer browsers to not recognize it (though I would
still expect most vendors to continue to handle any construct that
had a significant installed base of documents using it) Only when
(or even if) an element is made "obsolete" would I also expect
conversion tools to input (version old) documents and produce
(version new) documents. This is what happens for most any other
language I have every dealt with, from computer languages like
FORTRAN, to document languages like FrameMaker or WordPerfect.
But I would not expect a construct to be declared "obsolete" until
a (better) replacement construct was available and in use.
With this definition of the term, I do not understand the concern of
"breaking" existing documents. If the concerns are valid, then _NO_
construct in the language that was at all widely used could _ever_
be deprecated. Am I missing something?
Michael Hannah