Re: head@profile: another dropped attribute

On Feb 4, 2009, at 6:57 PM, Larry Masinter wrote:

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

Questions about the value of use cases of and whether particular  
features effectively address them often cannot be made 100% objective.  
But still, these are the kinds of judgments a Working Group have to  
make. Through reasoned discussion I believe we can do a lot better  
than personal like or dislike. This is one reason that studies of  
content and authoring practices help - they add some objective data to  
the mix, to help answer questions such as "how often does the longdesc  
attribute hold a meaningful value in practice"?

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

For features present in HTML4, we now have a decade of deployment  
experience, including a great deal of education and outreach efforts.  
I think it is important to study that experience and learn its  
lessons. In some cases, that lesson will be to change the details of a  
feature or replace it with a better-designed alternative, rather than  
to drop it entirely.

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

I think that is something to be considered on a case-by-case basis.  
For example, HTML5 makes the <applet> element nonconforming, because  
it is redundant with <object> and <embed> but is tailored to one  
specific type of plug-in content. I do not think any amount of  
tweaking would remove this problem. Similarly, the <body bgcolor="">  
attribute is purely presentational and its effect is always better  
achieved with CSS. Again I do not think any amount of tweaking would  
resolve the problem.

With other features, things may not be as clear-cut.

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

HTML4.01 removed some HTML3.2 features considered harmful, and over  
time these have faded into the background to the point that they have  
little impact on the modern Web. So, I think there is evidence that it  
can happen.

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

I think this requires human judgment. Anything that content authors  
are already commonly trying to do, whether using existing mechanisms,  
or workarounds, or escapes to browser extensions outside the Open Web  
platform, is highly likely to be a valid use case. Specific ways of  
making content available to a larger audience (for example, including  
speakers of foreign languages or people with disabilities) are highly  
likely to be valid use cases. If there is a possible use case that  
could be achieved through workarounds but which no one does, that  
casts doubt on the validity of the use case.

I don't think this can be made 100% objective, but we can try to state  
fact-based arguments pro and con in any particular instance.

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

Agreed. There is definitely a difference between "not useful" and  
"harmful". In some cases, the migration tax of making a useless  
feature nonconforming will outweigh the simplification value of  
removing it.

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

I'm not taking a position either way on this, and I do not have a  
stake on whether <table summary=""> is in or out. I am trying to  
describe what I see as the positions of those in favor and those  
against, by way of explaining how these things have often been  
decided. I think a lot of your message may be based on assuming I am  
against the summary or profile attributes. In fact, I am agnostic on  
both of these, but I am trying to explain how I think such cases  
should be decided.

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

These transition costs are part of why studies of real-world  
deployment are part of the decision-making process. If correct  
deployment is extremely low, the the associated transition cost is  
also likely to be low.

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

Past versions of HTML are certainly given some legitimacy. A truly  
from-scratch design probably would not name the hyperlink element <a>.  
But it is not assumed that everything in past versions was correctly  
decided; rather, changes are made where necessary. I believe that has  
been true for every version of HTML developed so far.

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

I don't believe I ascribed any position to anyone else with the above  
statement, so I do not believe I have misrepresented anyone's position.

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

Perhaps you are implying that is the only implementation cost I would  
consider. Although I personally work on a browser team, Apple also  
develops a number of HTML authoring tools (Dashcode, iWeb, the HTML  
export features of apps such as iPhoto and Aperture) and Web sites  
(apple.com, the Apple online store, MobileMe). In addition, many Apple  
applications use HTML and other Web technologies internally (Mail,  
iChat, Dashboard, Dictionary). And finally, it's an important  
principle for everything Apple does to consider the effect of end  
users. I try to consider all of these perspectives in my input to the  
Working Group. In fact, we are generally willing to do extra work in  
the browser for the benefit of all the other mentioned groups.

The reason I raised browser implementation cost in this case is  
because it is zero, so it cannot be argued that the feature was  
dropped for the benefit of 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?

I wasn't closely involved in the decision about <html profile="">, so  
I am probably not in the best position to explain it in detail.

By our Design Principles, the needs of authors should be given higher  
priority than the needs of implementors (of both browsers and  
authoring tools): <http://www.w3.org/TR/html-design-principles/#priority-of-constituencies 
 >. I originally proposed the Priority of Constituencies Design  
Principle, and I do my best to stand by it.

Regards,
Maciej

Received on Friday, 6 February 2009 02:43:59 UTC