Re: head@profile: another dropped attribute

On Feb 4, 2009, at 4:20 PM, Larry Masinter wrote:

> I think the two issues depend to some extent on the following  
> general policy questions:
>
> whether HTML 5 should recommend *any* practice that doesn’t  
> correspond to content that is commonly found “in the wild”, and if  
> so, what qualifies for inclusion and what doesn’t.
> 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 don't think anyone would argue that any practice that is not  
widespread in the wild must therefore automatically not be recommended.

I believe the way potentially dropped features have been analyzed so  
far is using a balancing test, considering questions like these:

- What is the purpose of this feature? What use cases does it serve?
- If the feature is already deployed, then how well is it serving its  
use cases? Is it used at all? When used, does it serve the intended  
purpose?
- Does the feature cause harm, for example by fostering bad practices,  
either directly or indirectly (by being error-prone, or easy to abuse)?
- Does the harm of the feature outweigh the benefit?

I think many (though perhaps not all) would agree that HTML4 features  
which do more harm than good should be made non-conforming. Others  
would also argue that a feature with no valid use case, or which  
completely fails to serve its use case in practice, should also be  
made non-conforming.

I think the true areas of disagreement are of two kinds:

1) Disagreement over whether the harms outweigh the benefits in the  
cases of particular features. I believe this is the point of  
controversy with <table summary="">.

2) Disagreement over whether features which do not appear to serve a  
useful purpose in practice, but which are in HTML4, should still get a  
strong presumption of inclusion. I believe this is the case with <head  
profile="">.


>
> If we had agreement on these policy issues, we might have better  
> luck than trying to battle this attribute-by-attribute.
>
> While the two issues share the basic policy questions, with  
> head@profile, unlike table@summary,  I haven’t been able to track  
> down uses in authoring software or web sites, although its use in  
> several other specifications has been noted and documented, so the  
> argument about backward compatibility isn’t quite as strong.
>
> For the record, I am strongly in favor, in general, of NOT DROPPING  
> features from HTML4 from the specification in a way that would make  
> valid HTML content and authoring tools invalid.

I would agree that HTML4 features should have some presumption of  
legitimacy. However, past revisions of HTML have dropped features from  
earlier versions entirely, and it seems sensible to me to do so for  
features that we think fail the balancing test. If we drop even one  
element or attribute from conformance, then we lose the conformance  
superset property, which reduces the value of retaining any single  
feature for continuity reasons alone.

>
> 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.
>
> If there were thousands of dropped attributes, this might be a  
> problem, but it looks like there are a relatively small number, and  
> taking this approach would serve the needs of the  broader HTML  
> community that focuses on applications of HTML on the web that are  
> beyond the needs of the “four popular browsers”.

 From the implementation point of view, there is no cost to <head  
profile=""> being conforming. We must support the  
HTMLHeadElement.profile property in any case for compatibility. I  
would guess the developers of other browsers are similarly agnostic on  
this one. I believe the decision to drop profile was made based on  
considering the needs of authors, although that assessment may have  
been incorrect.

Regards,
Maciej

Received on Thursday, 5 February 2009 01:37:03 UTC