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

Edward O'Connor, Mon, 09 Apr 2012 15:54:46 -0700:
>> 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:

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

Please note that in our counter proposal, you cited "numerous HTML 
guides" as your argument. And that my argument answered to that. I did 
*not* say that we should design HTML5 according to the HTML4 validator 
or anything like that.

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

This seems irrelevant: Funny as it may sound, an <object> is not 
considered interactive - by HTML5 -  just because is its @data 
attribute or its <param> elements embeds a Flash editor. Only when 
@usemap is present - or <object> is wrapped in a link - is the <object> 
interactive, according to todays spec.
 
> 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.)

I agree that this is the case - they won't be used at the same time.

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

I see only two levels here. :-D At least, there is nothing that makes 
that <object> interactive. *If* that <object> had the @usemap 
attribute, then even in my CP, your code would not be permitted.

The only way to create level 3, with my CP, would be through have a 
second <object> element inside the first. I admit that have not done 
anything, in the CP, to prevent that.

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

I have answered that point in my CP. So won't repeat. I hope the chairs 
find it.

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

This to me is an argument about theoretical purity, and I believe I 
have answered it in the CP.
-- 
Leif H Silli

Received on Tuesday, 10 April 2012 00:32:15 UTC