- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 10 Apr 2012 02:31:40 +0200
- To: Edward O'Connor <eoconnor@apple.com>
- Cc: public-html@w3.org
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