W3C home > Mailing lists > Public > public-html@w3.org > April 2012

Re: ISSUE-158: object-content-model - Straw Poll for Objections

From: Edward O'Connor <eoconnor@apple.com>
Date: Mon, 09 Apr 2012 15:54:46 -0700
To: public-html@w3.org
Message-id: <m2pqbga53d.fsf@eoconnor.apple.com>
Paul Cotton wrote:

> ISSUE-158: object-content-model - Straw Poll for Objections
>
> http://www.w3.org/html/wg/tracker/issues/158
>
> The poll is available here and it will run through Friday April 6:

Hi,

I had planned to reply to Leif's updates to his ISSUE-158 CP within my
poll response,[1] but I missed that the poll closed last week. I'm sorry
to have missed the poll; my HTML WG time last week was taken up with
work on ISSUE-194 and ISSUE-201. Despite its tardiness, I hope that the
Chairs will accept the below comment as a response on the poll.



Objection to the Change Proposal to use HTML4's content-model for
"object" element in HTML5:

This response is in addition to the arguments presented in the "Preserve
the transparent content model of the object element" Change Proposal.

In "Rebutting block element nesting problems claims,"[2] the CP cites
the behavior of the W3C's HTML 4.01 / XHTML 1.0 markup validation
service. 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. This WG has repeatedly
chosen to do otherwise.

Later on in that section, the CP claims that there are three benefits to
the proposed change to HTML5's author conformance criteria:

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

   I agree that this is a benefit of the proposed change, but I believe
   it to be a minor benefit outweighed by the costs of the change, as
   argued in the CCP.

 * It is claimed that, by making the proposed change, "we don't disturb
   authors by unuseful validity contraints that could, possibly, lead
   them to not add the fallback that is most optimal for the users."

   The merit of this claim hinges on whether or not the existing author
   conformance criteria are useful. The CP's author has asserted that
   they are not, whereas I (and the existing spec prose) argue
   otherwise. I won't repeat the arguments made in the CCP here.

 * The CP claims that the CCP "tries to uphold a simplistic image of
   HTML," but does not provide a citation for this claim. I am unable to
   find such a claim in the CCP. Also, I am unable to determine how this
   claim is a benefit of the proposed change.

Whether or not <object> is unique in its behavior does not seem to be a
point that argues for either proposal.

The CP claims "when there are use cases, the authoring requirements
should reflect how the HTML5 parser works and not operate with rules
which prescribe things to be authored in ways which the HTML5 parser
does not require." There are numerous authoring conformance criteria in
the HTML5 specification which are more restrictive than what the HTML
parser demands. It's certainly the case that parser behavior should be
considered when designing author conformance criteria, and it is. In
this case, the spec has chosen to restrict conforming content to a
subset of content which the parser will process without error, for
reasons cited in the spec and in the CCP.

In "Rebuttal of interactivity change claims,"[3] the CP claims that
"most would probably agree that it is almost never the case that a
textarea is useful as fallback for any thing that object can represent."
This claim is unsubstantiated. It is certainly reasonable to use a
<textarea> as fallback for, say, a rich text editor written in Flash.
Many such editors exist, such as mx.controls.RichTextEditor.

Later in that section, the CP cites a) including <a> elements in the
fallback content of <object usemap> and b) including <a> elements in the
fallback of <video controls> as examples of other places where HTML5
allows the nesting of interactive content. However, such 2-level nesting
of an interactive element with interactive fallback is not the problem.
(Were the fallback content used, it would not be used *at the same time*
as the container.) The problem is *3*-level nesting of an interactive
element containing an element that takes fallback containing interactive
fallback content. For instance, consider this markup:

                <a>foo<object><a>bar</a></object>baz</a>

If the <object> is not used, its fallback is substituted as if the
document looked like so:

                        <a>foo<a>bar</a>baz</a>

This is precisely the sort of confusing UI that the spec's introduction
discourages.

In "Rebuttal of invariant break claims related to 'rich fallback',"[4]
the CP claims that "even today, authors can embed e.g. a table in object
— it is just that they must, in order to be valid, take care to change
the parent p into e.g. a div. And so, with or without the CP, it remains
possible to add fallback that isn't suitable as fallback." But <div>
can, of course, take <p> and <table> children declaratively, so the
author misses the point of the original statement, which is that you
should be able to replace an <object> with its contents without changing
the meaning or conformance of the document. If an <object> is the child
of a <div>, and the <object>'s fallback is a <p>, you *can* replace the
<object> with its fallback content without altering the meaning or
conformance of the document.



Thanks,
Ted

1. http://lists.w3.org/Archives/Public/public-html/2012Mar/0771.html
2. http://www.w3.org/html/wg/wiki/FlowContentInObject#Rebutting_block_element_nesting_problems_claims
3. http://www.w3.org/html/wg/wiki/FlowContentInObject#Rebuttal_of_interactivity_change_claims
4. http://www.w3.org/html/wg/wiki/FlowContentInObject#Rebuttal_of_invariant_break_claims_related_to_.E2.80.9Crich_fallback.E2.80.9D
Received on Monday, 9 April 2012 22:55:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:47 GMT