W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: ISSUE-53: mediatypereg - suggest closing on 2009-09-03

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 2 Sep 2009 22:27:20 +0000 (UTC)
To: Mark Baker <distobj@acm.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org WG" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0909022225090.6775@hixie.dreamhostps.com>
On Tue, 1 Sep 2009, Mark Baker wrote:
> On Mon, Aug 31, 2009 at 6:24 AM, Ian Hickson<ian@hixie.ch> wrote:
> > It is pointless to provide semantics of elements (or other features) that
> > are obsolete
> Obsolescence is a forward-looking statement; don't use these features
> in the future.  That's fine and good, and I agree with the list of
> obsolete features assembled in HTML 5.
> Obsolescence does not change the meaning of existing content which
> happens to use those features, nor does it mandate that existing
> content be updated to remove them.

Sure, but that doesn't matter. Old documents will still be processed by 
software in a backwards-compatible manner, since the processing 
requirements on old features are still present in HTML5.

> > other than the semantics that form the element's (or the
> > feature's) normative user-agent conformance criteria, since the only
> > effect of such semantics is in deciding whether the element (or feature)
> > is being used correctly, and obsolete elements (and features) can never be
> > used correctly, since they are obsolete and must never be used at all.
> It is a fact that obsolete features are in wide use today by content
> served as text/html.  Therefore, any HTML specification(s) normatively
> referenced by the media type registration needs to define what that
> content means.

It needs to define how the content should be handled. What it means only 
matters from the point of view of authoring the content in the first 
place; after the content is authored, what matters is how it is processed.

> FWIW, I had a look through the obsolete list last night and found some 
> which had properly defined semantics.  For example, "plaintext" was 
> defined to mean the same thing as "pre".  That's good, and what we 
> should strive for for the examples given by Julian.

If you think that what is said for <plaintext> (i.e. a UA conformance 
requirement on the processing of the obselete feature) is acceptable, then 
what features are lacking these requirements?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 2 September 2009 22:24:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:51 UTC