- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 05 Feb 2009 18:43:12 -0800
- To: Larry Masinter <masinter@adobe.com>
- Cc: HTML WG <public-html@w3.org>
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