Warning:
This wiki has been archived and is now read-only.

FlowContentInObject

From HTML WG Wiki
Jump to: navigation, search

Leif Halvard Silli 15:26, 9 February 2012 (UTC) (Rebuttal-section: 28th of March 2012.)

Change Proposal for ISSUE-158:

Content model of object should be flow content + interactive content

Summary

The content model of the object element should change from transparent to flow content + interactive content. That it is not transparent but instead flow content means that it doesn't inherit the content model of its parent. That the content model also is interactive content means that it can contain interactive content even if its parent element is interactive too.

This would — A — allow block elements as children of <object> when object is child of <p> or inline element — like in this example: 

<p>Mug shot of Frank Sinatra  
     <object data=mugshot >
         Black and white photo of a young Frank Sinatra.
         The data stamped on the photo are: 
         <dl>
            <dt>Location: <dd>Bergen County Sheriff's Office
            <dt>Date:     <dd>11.27.38
            <dt>Number:   <dd>42799
         </dl>
     </object>
</p>

And — B — allow interactive elements as children of object whose parent is interactive — as in this example: 

<p>Mug shot of Frank Sinatra  
   <a href=link-to-sinatra-page >
      <object data=mugshot >
         <a href=description>external description</a>
       </object>
   </a>
</p>

NOTE: There is — seemingly — a exception to the nested anchors example: If the very object itself had been interactive (such as if the usemap attribute had been present), then object’s parent could not have been an interactive element. However, that is not really related to this change proposal, but instead depends on the fact that a (direct) child of the a element is not allowed to be interactive.

Rationale

For block content as children of object as children of p

If structured fallback as child of object is necessary, then:

  1. object is thought of as an alternative to the longdesc attribute and the aria-describedby attribute, because it - unlike the img element - allows mark-up in its fallback. (An aria-describedby could even point to object’s fallback.) There should therefore not be puristic restrictions on the content model.
  2. HTML5's restrictions on nesting of p elements and on what p elements may contain, are due to, quote: “peculiarities of the parser” that causes p to be auto-closed. However, in case of object, then these peculiarities do not exist: The HTML5 parser does, without parsing issues, accept block content inside object even when these block elements could not have been children of the parent.
  3. Authors will add such content in anyway. Example: HTML5 includes an code example where the fallback includes a p element despite that, in that example, the parent of the object element is an p as well. But for the author of this very change proposal, not a single HTML Working Group member has made it a problem of this break against the current HTML5 syntax rules.
  4. HTML5 describes how to implicitly (that is: without the use of the explicit p — paragraph — element) nest paragraphs and it uses an object element to examplify it - see the last example in HTML5's description of paragraphs. Hence, the very model — a paragraph inside a object inside another paragraph — is already known by HTML5.

For interactive content as child of an object whose parent is interactive

  1. It works in the parser(s): test file. Tested in the gui browsers IE9, Firefox, Webkit, Opera, the text browsers Lynx, W3M, elinks, links. Based on earlier evidence. With regard to gui browsers, they will normally display what the e.g. the data attribute points to, and this works without a hitch. However, with regard to the test file, then it tests what happens when the fallback is displayed. One thing that works nicely when fallback is displayed, is keyboard navigation (tabbing) from link to link.
  2. It should not require parser changes because test shows that it works and because, even by now, the HTML5 spec permits an image map object to contain area elements — and thus logically also a and other interactive elements:
    <object usemap=#map data=img>
    <map name=map><area href=link alt=link >
    </map></object>
  3. It has always been permitted (e.g. in HTML4 and XHTML1). But note that per HTML4 and XHTML1, then it is permitted to wrap an anchor element around object even when the object is interactive: This CP does not at all touch that aspect of HTML5.
  4. In most situations, the fallback link will not be “parsed” by the user — because in most cases, fallback is not what most users get. Thus the potential confusion is hidden and only revealed to them it could benefit, such as text browser and screen readers.
  5. It offers an alternative to @longdesc and @aria-describedby — when either of them does not work (e.g in a text browser)
  6. It would work well in tandem with @aria-describedby (which could point to the content of object)
  7. It simplifies the content mode of object: Authors don't have to wast time on learning that interactive content sometimes aren't permitted — instead it will always be permitted. (As told, the only limitition will that, if the very object element is interactive, then it may only occur in contexts where interactive content i spermitted. Currently, HTML5 considers presence of the usemap attribute as the only way to turn the object element itself into interactive content.)

Details

Exact spec text for the sections to be changed: Replace this line:
Zero or more param elements, then, transparent.
with this line:
Zero or more param elements, then, flow content and interactive content.

Additional, optional changes: At the HTML editor's discretion, it is suggested that HTML5's section on paragraphs is updated with an example to reflect this change. (See in particular the last example(s).) And also, examples to demonstrate the permitted anchor nesting.

Impact

Positive Effects

The flow content model change and the interactive content model change has these benefits:

  • Separation of concerns: It becomes more straight forward to add fallback content to object. For exacmple: Even when inside a p element, authors can just fill it with content without having to re-author the page first (that is: they don't need to make changes to the parent element in order to add the most optimal fallback content).
  • How the HTML5 parser works and what is conforming for authors to do, becomes more congruent.
  • Useless warnings during conformance checking is avoided.

Negative Effects

  • In some legacy versions of one parser engine (Trident), block elements inside object is difficult to use — it depents on the parent element of the object what works. (There was also an issue in Firefox 9 — but this got fixed in Firefox 10, see below).
    1. Counter argument: Trident is being updated — this is already an issue of the past roughly since at least IE8.
    2. Counter argument: The issue in Firefox 9 (that the content of object occurs at the then of the paragraph instead of where it should occure), has nothing to do with the content model of object. Additionally, that issue was fixed with Firefox 10.
    3. Counter argument: In both IE legacy and Firefox legacy's case, a wrapper in the form of a span element is a solution.

Conformance Classes Changes

Only authoring and validation will be affected. Parsing is unchanged (at least as far as this CP author is able to see).

Risks

  1. Relevant ATs are known for not supporting fallback of object very well, and so authors could use this method without getting the expected results.
    • Counter argument: This is not i particular related to the issue of the content model of object, but more of a general problem that UA and AT have to fix. In fact, the problem is unrelated to what the parent element is. It is only to the extent that this CP makes it simpler — and thus more attractive — to use object, that this has any relevance.
    • Counter argument: There is a drive (see Jonas Sicking's change proposal for the longdesc issues) towards making aria-describedby reveal not only the plain text version of the element(s) it points but also semantic mark-up — if successfull, then one can use this method to reveal the fallback of object as well.
  2. It promotes use of aria-describedby for presenting the fallback of object
    (by letting the attribute point to the very object element itself — or directly to the fallback).
    • Counter argument: No. Until further, aria-describedby will turn the fallback into a text string — and thus work against the use fo structure in the fallback. This CP could just as well encourage AT to present the fallback with its mark-up semantics, without any look at ARIA. Futher more, if such side effects exist, then they exist even without this CP — and it is only to the extent that this CP makes object more attractive to use, that it bears any relevance.
  3. When object is used for non-interactive images in need of a long description,
    then this change negatively impact the case for the inclusion of the longdesc attribute.
    • Counter argument: In any case, the change of this CP should be evaluated on its own merit.
    • Counter argument: No. This change is only about the content model. Regardless of this change proposal, one can include a link inside the fallback of e.g. <object data=image></object>. All this CP does is that it makes it simpler for authors to add structured and interactive content inside the fallback. To the extent that ATs will be able to render structured and interactive fallback inside object, then it would probably be possibel to use this method instead of using longdesc — however, that issue is nevertheless not related to this CP. The AT issues with fallback inside object — that they natively (that is: without ARIA) often support it badly — are not affected by this change proposal.

Rebuttal of the Counter Change Proposal - CCP

The CCP was also rebutted in public-html — please consider that message part of this rebuttal section.

Rebutting block element nesting problems claims

  1. Contrary to what the CCP says, the CP proposes a natural solution: The CCP portrays what the CP suggests w.r.t. block elements inside object inside p elements as essentally against the very nature of HTML. However, HTML4/XHTML1 have always allowed p inide p and h1-h6 elements, as long as the “misnested” element (the p in the p or in some other “illegal” place) is wrapped inside a button, object or map element.
  2. Authors’ most trusted source tells authors that what this CP proposes, is legal. The CCP claims, without documentation, that the block element nesting aspects of the CP goes against “numerous educational materials”. By contrast, it is very simple to document that the most respected authority, the W3C HTML4/XHTML1 validator, tells you to that you can wrap a p in a p or a in a h1-h6 element, as long as you use button, object or map as wrapper: Try this document in the validator (look at the source code at the bottom of the validator page).
  3. The CP does list substantial benefits of the nesting change: The CCP claims that the CP fails to “explicate any particular benefit to this change”. However, this is not true. The benefits are listed above - a brief recap:
    1. We increase the utilty of object when it comes to accessibility, by allowing e.g. a diagram image to fallback to a table — without having to alter the possible p parent of the object element.
      Examples:
      • a) A browser that doesn't render images, can render the table instead of the image of the object element. This should nicely with e.g. @aria-describedAT: Image supporting ATs with ARIA support can visit the external description, while AT without image or ARIA support, such as text browsers, can use the fallback. Another “image-less” browser is search engines — with the table in the fallback, the page page can contain more indexable data.
      • b) Depending on the effects and outcome of ISSUE-184, ATs mights be able to render the table, despite that the fallback is essentially hidden.
    2. 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. We know from @alt attribute validaton that authors tend to just add an empty attribute, in order to be valid. Thus we can be pretty sure that the current rules will impact negatively on what authors place in object’s fallback: They might remove content instead of altering the parent element. Thus, by removing the need to alter the parent element, we remove that particular obstacle;
    3. We also avoid giving a false impression: The CCP tries to uphold a simplistic image of HTML. But HTML isn't quite as simplistic as the CCP wants it to be. Let's deal with it. Heck, the CCP admits that what the CP proposes, is compatible with the HTML5 parser. In fact, I would be as bold as to claim that the CCP faviours HTML teachers rather than HTML authors. Because, the CP does not propose a difficult rule, even if it perhaps — from a HTML teacher's point of view — complicates thing a little bit.
  4. The purpose of the CP is not to allow “tricks”: The CCP mentions that object makes it “possible to trick the parser into making the second paragraph a descendant of the first by wrapping the second”. However, the claim that the CP is about “tricks“, have allready been refuted on public- html: The goal with the CP is not “tricks”. The “tricks“ were easy to do in HTML4, where @data and @type were not required — thus one could easy and lazily “circumvent” the content models. But in HTML5, these attributes are required, and thus it requires a active misuse from the authors’s side if the goal is to both take advantage of the HTML5 parser's treatment of object while also staying — formally — valid.
    • In fact, depending on the purpose with that kind of “circumvention” of the content model, then it is already possible: One can add a valid but still fake (read: unsupported) value in the @type attribute (in combination with no @data attribute) — without this trick, the fallback will not display to the average user. Because, who would use the object to perform “tricks“ unless the intention is that everyone — and not just those who are served the fallback — experiences the “trick”? To use the object element for its fallback features, is indeed to use it for the wrong reasons — but neither this CP nor HTML5 prevents that kind of abuse. If there are bad effects of this change, then it can be solved by restricting which values of the @type attribute that should be permitted — that's the right place to fix the problem.
  5. The CP does not argue against authoring conformance criteria: That the CP says that authors will do this anyway is not a main argument but a subsequent argument. The main argument is that authors will add structured content, including p inside p with the best intentions: Good, strucktured fallback for the users. Heck, as I document above, HTML5 itself includes one such example. And thus, the CP argues, that we should not make things difficult for authors, by telling them that they do something wrong when what they do doesn't create problems anyhow.
  6. The object element is not unique within HTML5: This CP’s proposed content model for object differs from that of the new media elements — video, audio, canvas. The new media elements work the same way that the CCP would like the object to (be considered to) be working: If one does e.g. add a p in a video which has p as its parent (<p><video><p></video>), then the inner p will be moved outside of both the video element and the outer p element, thus resulting in a DOM with two parallel — also known as adjacent — p elements. However, this does not prevent authors from adding p inside video: All it takes is that authors makes sure the parent of the media element is something other than the p element. Whether this is any intuitive, can be debated, but at least authors can see — visually — what happens in the DOM. Thus, for the new media elements, the authoring requirements are about more than theoretical purity: The HTML5 parser works that way. Note, by the way, that for video adn audio, then — unlike for object — the fallback, quote: “is not intended to address accessibility concerns”, and so the limited content model should not hamper accessibility. (But w.r.t. the canvas element, then it seems entirly possible that affectst what authors place in the fallback.). So — once more —  object’s content model from the HTML5 parser’s point of view, differs from that of the new media elements. However, the object is not the sole element that the HTML5 parser treats this way: In addition to object then both button and the obsolete but still used (in internet banking that dependens on Java applets) applet element have the same effect on the DOM. Common to these elements is that — A — p inside e.g. object inside p does work and — B — authors can see that that is how it works.
    Which model is best, the object model or the video model? And is that the right question? This CP consider that, 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.

Rebuttal of interactivity change claims

  1. The CP does not encourage authors to do anything “highly confusing“: The CCP cites the introduction to HTML5, which takes as example that button is not allowed to contain textarea. And yes, a textarea as child object that in turn was the child of a button, might easily be a highly confusing thing. However, like I stated in public-html, for someone to do that specific thing, would require the author to misuse the fallback: The fallback should be a replacement for the media that the object is embedding. That the fallback really does fit as fallback, is for the author to decide. But 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. So, once again, we see that the CCP’s claims presupposes a lot more than just those things that are in the CP: The CCP presupposes that the author has no sense or understanding for what fallback means — that it is supposed to reflect that which it is fallback for.
  2. HTML5 itself includes code examples where there are a link inside an interactive element: When video or audio include the @controls attribute, then they are considered “Interactive content“. (Ironically, this means that if the controls are added via JavaScript, then it is not considered interactive. But anyway:) If one were to read very literally what HTML5’s introduction says about, quote “the way interactive content cannot be nested”, then one ought to think that HTML5 never provides examples of interactive content inside interactive elements. However, HTML5 does permit links inside object even if it has the @usemap attribute. And, equivalently, when the @controls attribute is present on video and audio then one should think that it would be non-concorming to place a link for downloading the video file in those media element’s fallback. However, there appears to be no such rule: These elements are still considered transparent. Hence, the HTML5 editor includes two code examples for the video element which do precisely include a link, despite the presence of the @controls attribute. See 4.4.9 The footer element and 4.8.4 The object element.
  3. It is the default that matters: When HTML5’s introduction talks about “highly confusing”, then it links it to the default behaviour: ”This is because the default behavior of such nesting interactive elements would be highly confusing to users.“ This thinking ought to be in line with the CP, which focuses presicely on the default behavior: The default is that the user does not see the fallback.

Rebuttal of invariant break claims related to “rich fallback”

  1. The CP does not break “a basic invariant of fallback content”.
    The CCP currently says, and I quote — the emphasis is mine:

    “If fallback content is equivalent in this way, it should be possible to remove the surrounding <object> (and its <param> children) without changing the meaning or conformance of the document. If we adopt the Content model of object should be flow content + interactive content Change Proposal, this would no longer be the case. We will have broken a basic invariant of fallback content.“

    The CCP’s claims here appears taken out the air — although it is not at all clear what exactly it tries to say. But my guess is that it tries to claim that the current restrictions — the fact that e.g. a table is not possible in the fallback if the object’s parent is a p element — will prevent the author from adding something in the fallback that isn't usefull as fallback. With that as my interpretatation, here is my response:

    1. Firstly, as I have already said previously in this CP, the HTML5 spec does include the idea of nested paragraphs. It allows it by exending the definition of what at paragraph is: It is not just the p that is is a paragraph. And so, authors can nest paragraphs. They just can't use the p to do the nesting.
    2. Consequently, the way HTML5 defines it, it does not matter whether the paragraph is represented by a li, p or a div. And so, 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.
    3. And so, with or without the CP, it remains possible to add fallback that isn't suitable as fallback. The CP does not impact on that at all: The CP only makes it simpler to embed e.g. a table in the fallback. Because, whether a table is suitable as fallback for the object, does not — in real life — depend on whether the parent of the object is a p or a div. In fact, it would be unfortunate if authors thought there was such an interdependence. And the good thing about the CP is that it removes the possibility that the author doesn't add proper fallback because object's parent tag doesn't allow it.

  2. The current state of affairs has a problem that sofar has not been taken up: It might trigger authors not only to change the parent p to a div — they might even remove the parent element altogether, as shown in HTML5’s secton on paragraphs. When the parent element is removed, a CSS styling hook is removed as well — which is yet another negative experience, solely for the goal of being “valid”.

References

Corrections

Corrections since the submission to the HTMLwg:

  1. Deleted the mention of the tabindex attribute in the #Summary section
    • Why: The text wrongly indicated that the HTML5 spec considers that presence of tabindex attribute turns an element into interactive content. But the correct thing is that HTML5 does not consider that the tabindex attribute has any such effect: It is only when the usemap attribute is present, that HTML5 considers object interactive content.)
  2. Added a new sentence at the bottom of the #Rationale section: Currently, HTML5 considers presence of the usemap attribute as the only way to turn the object element itself into interactive content.
    • Why: For clarification.
  3. Added author signature on top of the page.
    • Why: For clarificaiton
  4. Added the word “for” in this heading: #For interactive content as child of an object whose parent is interactive.
    • Why: For congruence with the preceding heading.
  5. Added a NOTE point under list item 2 inside the rationale section #For interactive content as child of an object whose parent is interactive.
  6. Replaced, in the rationale section (#For interactive content as child of an object whose parent is interactive) a referenc to Webkit with a cross browser reference: «see demo that works in Webkit, Opera and Firefox 3.6 and IE9» + a link to a file which demoes this plus a link to a bug in Firefox.
    • Why: To demonstrate its broad support.
  7. Add this sentence: In fact, a bug to classify area as interactive content has now been filed.
    • Why: It is relevant.
  • Note that pure typos are corrected as they are discovered — check the page history.
  • 28th of March: Added rebuttal secton of the Counter Change Proposal.


Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=FlowContentInObject&oldid=12509"