Working Group Decision on ISSUE-158: object-content-model

The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic as well as
rebuttals that were provided in response to the poll, and shortly
thereafter.

*** Question before the Working Group ***

In XHTML1 and HTML4, the "object" element creates a new context, where
the parent element is ignored when the content of object is validated.
HTML WG has not reached consensus on whether the "object" element should
be handled this way in HTML5. In an effort to resolve this issue
amicably, bug 9657 has been raised. This bug has not been resolved and
it is considered that further discussion in bugzilla will not result in
the bug being resolved.  This issue has been captured as Issue-158.

https://www.w3.org/2002/09/wbs/40318/issue-158-objection-poll/results
http://www.w3.org/html/wg/wiki/FlowContentInObject
http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-158
http://lists.w3.org/Archives/Public/public-html/2012Apr/0047.html
http://lists.w3.org/Archives/Public/public-html/2012Apr/0049.html

== Uncontested parts of the proposals:

Regarding FlowContentInObject, Ted O'Connor said:

   * The CP claims that, by changing the spec as proposed, we improve the
     accessibility of <object> "by allowing e.g. a diagram image to
     fallback to a table — without having to alter the possible p parent
     of the object element."

This use case turns out to be an important factor in the decision but
was not, by itself, not decisive.  There were people who supported
different proposals even after taking this fact into consideration.  The
fact that this was acknowledged up front was appreciated.

== Objections to FlowContentInObject

http://www.w3.org/html/wg/wiki/FlowContentInObject

   * Those who would change HTML's paragraph model need to demonstrate
     significant benefits to the change. After all, there are numerous
     educational materials, tutorials, and reference guides which would
     need to be updated.

This author of this statement also stated "It doesn't make sense to make
HTML5 design decisions based on the behavior of a validator for previous
versions of the language. That line of argument is a slippery slope that
leads to the position that HTML5 should change nothing from HTML 4.01."
Given that not a single education material, tutorial, or reference guide
that would need to be updated was sited, and given that there was no
push back to the assertion that this was previously permitted, this
argument was given no weight.

   * Change Proposal does not explicate any particular benefit to this
     change.

Given that the author of this statement conceded that there was a
potential accessibility benefit, this statement was given no weight.

   * nesting is highly confusing to users

This would be a strong objection if it were backed by anything
resembling evidence.  As it was not rebutted, this was considered to be
at most a weak objection.

== Objections to transparent content model of the object element

http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-158

   * Authors will add such content in anyway

This is another assertion presented without evidence.  The counter
argument to this is that this is an area where confusion exists.

   * It works

Given that there is an uncontested use case, this argument is moderately
strong.

   * It has always been permitted

Contrary to the rebuttal that has been presented, this is at least a
weak objection; that doesn't mean that it couldn't be changed by HTML5,
but that for it to change it needs to have a reason provided to do so.

== Evaluation of arguments

Many of the rebuttals focus on 'theoretical purity' arguments in both
directions.  It was difficult to cast the original arguments as
objections, they were (generally correctly) contested, and at most would
have been considered weak.

As stated above, the 'priority of constituents' argument that a more
complex specification would be tolerable given sufficient user need
would have been considered strong if there were anything resembling
evidence provided to back up this assertion.

While relatively weak (no evidence was provided that this pattern
actually occurs in the wild), the uncontested use case for the
accessibility of the object element, coupled with "it works" and "It has
always been permitted" represents a comparatively stronger argument
against the "transparent content model of the object element" change
proposal.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "flow content in
object" change proposal:

     http://www.w3.org/html/wg/wiki/FlowContentInObject

Of the Change Proposals before us, this one has drawn the weaker
objections.

== Next Steps ==

Bug 9657 will be REOPENED and marked as WGDecision.  Once the editors
have made the change, ISSUE-158 will be 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. Examples of
possible relevant new information include:

* Evidence backing up the assertion that this change would be "highly
   confusing" to users.  Ideally, such evidence would include multiple
   citations of non-obscure web sites that demonstrate the problem, and a
   description of the problems (in terms of real world consequences) that
   such usages create.

* Any other evidence that the benefit of this use case is outweighed by
   the costs of the change.  This could be by citing sufficient
   quantities of education material, tutorial, or reference guides that
   not only would need to be updated, and that doing so would impose an
   unreasonable burden.  Alternately it could be done by arguing that
   "theoretical purity" in this particular case outweighs the use case.
   Other, new, arguments may also be possible.  Feel free to complement
   such information with indications that the potential benefits don't
   overcome these costs: information such as alternate and better ways to
   address the use case, indication that the feature was rarely or never
   used, etc.

Received on Tuesday, 31 July 2012 18:53:18 UTC