RE: head@profile: another dropped attribute

>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?

Interesting background questions, but what is the "balancing test" that would be based on the answers to these questions?   For example, it wouldn't be appropriate to judge a feature by whether you personally liked the purpose or thought it was important for yourself, or found the use cases personally compelling, or base it on what you think of the people for whom the use case is important.
What are the objective criteria here?

   > 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?

This is backwards looking, though.  For many of the accessibility issues, for example, the community is making good headway in improving deployment of accessibility authoring.  It's reasonable to judge whether a feature *can* serve its intended purpose, and whether any improvement in deployment and effectiveness is possible, but in some cases successful deployment takes time and education. I think that's true especially for features supporting desirable (but not necessarily "cool") features of the web: usable metadata, accessibility, international support, security.

> - 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.

I disagree: we should first attempt to repair existing features that seem to do more harm than good.    Often the problems are minor, due to poor documentation, or an error or missing parts of requirements, test cases, and conformance requirements.

> 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.

There is no evidence that removing a feature prevents any "harm", and rather, increases the likelihood of harm. It makes some documents and tools non-conforming, confuses people who are looking for a feature that has been there in the past.

"valid use case": I think too many private interpretations of "valid" have been made implicitly without discussion, and that it's really necessary to be more explicit: how do you judge whether you think a use case is "valid"?

Even if a feature is determined to be not useful,  it is preferable to deprecating the feature (advising against) rather than removing the feature, making previously conforming documents and authoring tools non-conforming.  A strong case needs to be made that actually leaving the feature in is harmful.

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

>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="">

Please explain how leaving tables with a summary attribute as conforming is harmful, and that the harm is greater than the harm causes by preventing the attribute from being used in conforming documents.

> 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="">.

I think there also significant disagreement over the evaluation of "useful purpose in practice", perhaps much as there is in the "strong presumption of inclusion".

The existence and widespread deployment of tools that support a feature is itself grounds for "strong presumption of inclusion".   Adding, supporting, documenting, testing features is expensive and not done lightly. Further, removing features and making existing tools non-conforming carries its own cost as well, of updating the software, documenting the change, dealing with different cases where the feature is sometimes enabled and sometimes not, helping users remove elements that were previously conforming but no longer, etc.

The costs and benefits for software other than browsers (and, of course, authoring tools) needs to be included in the criteria for decision making.

Ø  I would agree that HTML4 features should have some presumption of legitimacy. However, past revisions of HTML have dropped features from earlier versions entirely,

I don't detect any other time where past revisions of HTML have been given significant legitimacy in this working group, and I don't see why past behavior of W3C HTML committee should be given any more deference in this issue than for any other issue. In any case, precedent isn't a strong issue here, maybe they also did wrong.

> 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.

Perhaps a strawman?   You can't change (clarify, restrict) any element or attribute without breaking "conformance superset" so I think it is a lost cause anyway.

In any case, the cost is almost entirely incremental: each feature removed (or modified incompatibly) causes some parts of previously conforming documents to no longer be conforming, and thus require editing of those parts to bring the documents into conformance. Each incompatible change on its own causes some features of tools to need modification, if the tools want to produce conforming documents.   The cost of incompatibility is borne feature-by-feature, line-by-line for documents and feature-for-feature for tools.

So this is not a good argument for casually dropping other features because you've already dropped one.

>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.

It's good you're considering implementation costs for browsers.

I believe the decision to drop profile was made based on considering the needs of authors, although that assessment may have been incorrect.

This is the first mention of "needs of authors" I think you've made, and I don't see how making previous tools, documentation, and documents, and dropping them from HTML5, helps any author. Could you explain?

Larry
--
http://larry.masinter.net

Received on Thursday, 5 February 2009 02:58:34 UTC