Re: head@profile: another dropped attribute

On Feb 5, 2009, at 02:20, Larry Masinter wrote:

> I think the two issues depend to some extent on the following  
> general policy questions:
[...]
> 	• In particular, whether attributes and features that are present  
> in HTML4, widely documented and references, should have a higher bar  
> against removal, even if they are not widely used, as long as they  
> are not harmful.

I guess first we need an understanding of what is harmful.

What's your definition of harmful?

Is wasting a lot of author time (on aggregate globally during the  
lifetime of HTML5) with syntax of little to no use harmful?

Is creating an attractive nuisance[1] that can lead to such waste  
harmful?

Is failure to remove an attractive nuisance that can lead to such  
waste harmful?

Is asking authors to spend time on removing pre-existing no-op syntax  
harmful?

Is adding GUI clutter to Dreamweaver harmful?

Is failure to remove pre-existing GUI clutter from Dreamweaver harmful?

> Rather, it seems preferable from a tool and validity point of view  
> to leaving them in the specification as conforming, but marking  
> them  as deprecated; “deprecated” in the sense of “could be dropped  
> in the future”, possibly designating them as SHOULD NOT be used in  
> content, SHOULD BE ignored by browsers.

HTML 4.01 had three levels of markup feature conformance from current  
to old:
Conforming (in HTML 4.01 Strict, e.g. <p>)
Deprecated (in HTML 4.01 Transitional, e.g. <font>)
Obsolete (previously in HTML but not in any flavor of HTML 4.01, e.g.  
<xmp>)

Putting things in the "deprecated" class is a cop-out. In the case of  
HTML 4.01, it is a wishful class of non-conformance: authors still use  
those features as Transitional and authoring tool vendors spent time  
and UI real estate on the features--and the transition has been going  
for about a decade. Also, having a "deprecated" class of conformance  
makes it too easy for the definers of language to be too idealistic  
with the non-deprecated part. That is, if deprecation is considered to  
be available, oft-used but ideologically impure features (such as the  
target attribute) may end up as deprecated too easily leading to a  
situation where the deprecated version of the language becomes the de  
facto conformance target of authors.

By deliberate policy (not formulated by this WG), HTML 5 has no  
deprecated features. Recently, though, HTML 5 has gained a list of of  
downplayed errors[2] which, in my opinion, is partly similarly wishful  
as deprecation was in HTML 4.01.

[1] http://en.wikipedia.org/wiki/Attractive_nuisance
[2] http://www.whatwg.org/specs/web-apps/current-work/#conformance-checkers-0
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 5 February 2009 07:53:38 UTC