- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 19 Mar 2011 10:12:04 -0400
- To: HTMLWG WG <public-html@w3.org>
The decision follows. The chairs made an effort to explicitly address all arguments presented in the Change Proposal on this topic in addition to the arguments posted as objections in response to the call for closure based on Amicable Resolution. *** Question before the Working Group *** There is a basic disagreement in the group as to whether or not the content attribute of the meta element should allow multiple languages, or even if a Content-Language pragma should be treated as conforming at all. The result was an issue, three change proposals, and a survey: http://www.w3.org/html/wg/tracker/issues/88 http://lists.w3.org/Archives/Public/public-html/2010Apr/0308 http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html http://lists.w3.org/Archives/Public/public-html/2010Apr/0307.html http://www.w3.org/2002/09/wbs/40318/issue-88-objection-poll/results == Uncontested observations: The following observations were made by participants and seemed to enjoy consensus: * it would be nice if http-equiv actually had the same effect as the HTTP header. However, this isn't possible in this case for compatibility reasons. * All 3 proposals agree that UAs MUST ignore pragmas with multiple languages inside * Any restrictions on the use of Content-Language interferes with the original intended use of this markup. * The use of html@lang cancels any effects that HTTP and http-equiv might have, in HTML5 parsers and (in the average cases) in legacy parsers as well. * We are faced with a situation where the choices either involve producing error messages for situations which are harmless, or to pick a more complicated solutions that authors may not universally understand. None of these were decisive. There were people who supported one of the change proposals even after taking these facts into consideration. The fact that they were acknowledged up front was appreciated. It generally is difficult to evaluate consensus when there are more than two proposals. In this case, the way we proceeded was simply to evaluate each in turn. === Objections to allowing multiple languages Weakest objections include: confusing/complicated, and redundant/unnecessary. That's not to say that such objections are not valid, just that there may be circumstances where it may be necessary to ignore such requirements once the full implications are are understood and carefully weighed. In both of these cases, exactly such an argument was made. Strong objections include: does not match the HTML model where each node in a document can have its language computed to at most one language tag, nor does it exactly match the HTTP header model, no demonstration that content language tools actually need/use this feature, multiple language values are not interoperably supported, and evidence that this feature is more often than not unused or misused. === Objections to making only multiple languages non-conforming Weakest objections include producing errors in situations where the markup is harmless, and redundancy. Again, that's not to say that these objections are not valid, just that there were arguments put forward which indicate that there are valid reasons for an exception to be made in this case. Strong objections include changing the syntax in a way that makes HTML and HTTP incompatible. == Objections to making Content-Language non-conforming Weakest objections include producing errors in situations where the markup is harmless, the proposal is a layer violation, and that this proposal will interfere with the intended use case for this function. There were no uncontested strong objections to this proposal. Again, what that means is that while there were valid objections against this proposal, we found that for each objection there were valid reasons put forward why such an objection should not be considered strong. For completeness, we now review each of the objection to the "making Content-Language non-conforming" proposal: It is uncontested that this proposal will cause validators to produce errors in situations that are, in fact, harmless. In each such case, there is a preferred way for the language to be expressed. One of the alternate proposals would have produced the same number of messages, just as warnings not as errors. The other proposed not producing messages in cases which will neither be interoperably implemented nor compatible with the HTTP definition, and both of these conditions were considered undesirable. It is also uncontested that this is a layering violation. The I18N Working Group provided a clear statement as to why specific circumstances merits an exception: It really is a requirement that HTML5 clearly specify if (and if so, how the) HTTP Content-Language and/or the Content-Language pragma is assigned to html@lang when html@lang is itself not present. The I18N WG could accept language specifying the assignment of the (unmodified) Content-Language syntax header/pragma to html@lang, as long as such an assignment were completely unambiguous, although we really would prefer that no such linkage is created. Additionally, this layering concern applies in differing degrees to both of the other Change Proposals as each proposes conformance criteria and/or behavior which differs from the HTTP definition. Finally, it is asserted that this will interfere with the intended use case for this function. While the assertion itself is not contested, what is contested is that there has been any demonstration that there is any need or desire on the behalf of authoring tools to communicate this information in this manner. This leads to a strong objection to premature standardization absence this evidence. *** Decision of the Working Group *** Therefore, the HTML Working Group hereby adopts the Change Proposal to make Content-Language non-conforming. Of the Change Proposals before us, this one has drawn the weaker objections. == Next Steps == Bug 8552 is to be REOPENED and marked as WGDecision. Since the prevailing Change Proposal does call for a spec change, the editor is hereby directed to make the changes in accordance to the change proposal. Once those changes are made, ISSUE-88 is to be marked CLOSED. == Appealing this Decision == If anyone strongly disagrees with the content of the decision and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request. == Revisiting this Issue == This issue can be reopened if new information come up. An example of possible relevant new information include: * Clear evidence that there are either authoring tools or servers which depend specifically on the Content-Language pragma to behave per the original intended use for this function. == Arguments not considered The following arguments expressed in the survey were not considered for the reason specified: Additionally, it is asserted that this proposal contains "unjustified changes, inconsistencies, unimplementable requirements and is overall inappropriate for use in the specification." This argument is entirely lacking in specifics. We would prefer that the CP be modified... this, of course, is an argument against the main raison d'ĂȘtre of this CP. We only evaluate change proposals that actually were submitted. This is particularly true when the changes proposed are "against the main raison d'ĂȘtre" of the proposal in question.
Received on Saturday, 19 March 2011 14:12:37 UTC