W3C home > Mailing lists > Public > www-html@w3.org > January 2000

Re: So, what's left?

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Tue, 25 Jan 2000 00:19:26 -0800
Message-Id: <200001250819.DAA18922@tux.w3.org>
To: Murray Altheim <altheim@eng.sun.com>, "dwagner@sa.kevric.com" <dwagner@kevric.com>
CC: "www-html@w3.org" <www-html@w3.org>
One pattern (which I believe to be the result of deliberate intelligence 
rather than random coincidence) that I have observed in the evolution of W3C
specifications is that *for the vast majority of cases*, whenever one
technology, method or mechanism was deprecated, there was an *approved*
alternative suggested and provided.

E.g. the vast majority of deprecations in HTML4 are style related, and it is
recommended that CSS1 properties be used instead of the various deprecated
HTML4 stylistic tags (e.g. font-weight instead of <B>) and attributes (e.g.
background-color instead of BGCOLOR).

At the time HTML4 was published as a recommendation, the alternatives that it
referred to (e.g. CSS1) were already recommendations as well, so that it was
theoretically possible for someone to use HTML 4 Strict and CSS1, and not have
to depend on anything that was deprecated, or anything that was only at the
working draft level.

And I'm just talking about deprecation of a feature, not the far more
serious/radical act of removal of a feature.

IMHO new W3C recommendations should continue this "pattern" moving forward -
in short, deprecate only that for which there is an *approved* alternative -
where "approved" means something which is already in a W3C recommendation.

If we begin to prematurely deprecate (much less <gasp/>, remove) features
without such approved alternatives, especially features which are already
widely in use, then we will end up with less and less practical (read as
"useful" or "likely to be implemented") specifications.

>From: Murray Altheim <altheim@eng.sun.com>
>Date: Mon, Jan 24, 2000, 11:38 AM
> David Wagner wrote:
>> It just hit me.  If I have followed the discussion of where the HTML and
>> standards are headed, FRAME, IFRAME, APPLET, and OBJECT elements are all
>> away.  Does this leave ANY means to include content other than text, static
>> images (including the limited gif animation), and the few XML content models
>> available such as MathML?  Wasn't OBJECT supposed to replace IMG, and not the
>> other way around?
> As I've tried to explain, XHTML 1.1 currently has <applet> (if you read the
> draft you'll see it staring back at you) and we'll be discussing in our F2F
> meeting this week what to do with <object> (which currently isn't in the 1.1
> DTD but my guess is that it will be).

See above.  Please keep <object> until an approved alternative is available.

> As for frames, the industry, representatives of the authoring community, the
> i18n and WAI communities, all agree that they should not continue to be
> supported. Frames have been broken since the start for more reasons than I
> care to list. While those who like flashy pages are already screaming, our
> best response to those who care more about flash than the ability of *all*
> people to navigate, bookmark, print and access online pages is that many of
> the functions of frames will be much better served with XLink and proper
> use of stylesheets.

The reality is FRAMES are in widespread use, whether we like it or not, for
valid uses and probably also for not.

AFAIK, there is no complete replacement for FRAMES using CSS.  We're close
with position:fixed and overflow:scroll, but we still don't have NORESIZE (at
least not in a recommendation, though it is "under development" in a working
draft [1]).

Please keep <frameset>, <frame>, and <iframe> until approved alternatives are

> One may not care about blind users but one might consider
> everyone using Palm pilots and other devices, new browsers, etc. And as we
> all move into an XML environment, frames will become even less interoperable.

This is an excellent argument for developing a superior alternative to FRAMES.

This is not a good excuse to prematurely deprecate (or remove) FRAMES.

>> I would not like to tell people, "Well, since we upgraded to the most
>> technologically advanced standards-based digital document formats available,
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> XHTML is a LOONNGGGG way from being the most technologically advanced format
> available.

Hopefully we can strive to make it advanced *and* practical.

Received on Tuesday, 25 January 2000 03:19:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:52 UTC