Warning:
This wiki has been archived and is now read-only.
FlowContentInObject
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
- Submitted to the HTMLwg on February the 9th 2012.
- There are #Corrections since the submission, see References section, bottom of the page.
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.
Contents
Rationale
For block content as children of object
as children of p
If structured fallback as child of object
is necessary, then:
-
object
is thought of as an alternative to thelongdesc
attribute and thearia-describedby
attribute, because it - unlike theimg
element - allows mark-up in its fallback. (Anaria-describedby
could even point toobject
’s fallback.) There should therefore not be puristic restrictions on the content model. - HTML5's restrictions on nesting of
p
elements and on whatp
elements may contain, are due to, quote: “peculiarities of the parser” that causesp
to be auto-closed. However, in case ofobject
, then these peculiarities do not exist: The HTML5 parser does, without parsing issues, accept block content insideobject
even when these block elements could not have been children of the parent. - 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 theobject
element is anp
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. - 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
- 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. - 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 alsoa
and other interactive elements:<object usemap=#map data=img>
<map name=map><area href=link alt=link >
</map></object>- NOTE: For some reason, HTML5 currently does not consider the
area
element as interactive content. And this despite that it is possible — see demo that works in Webkit, Opera and Firefox 3.6 and IE9 — to stylearea
elements to look like links. (A bug has been filed to make it work in Firefox post version 4 as well.) And also despite that HTML5's WAI-ARIA sections states thatarea
has a strong link role. The validator even accepts that amap
element is nested inside anda
element — which doesn't immediately make sense. Hence, it is possible that HTML5 has a bug in this regard. In fact, a bug to classify area as interactive content has now been filed. But let it therefore anyway be said that, in the case of<object usemap=* data=*>
, then the HTML5 parser (at least in Validator.w3.org/nu’s interpretation, fully accepts a link a child of anobject
that is used as image map.
- NOTE: For some reason, HTML5 currently does not consider the
- 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. - 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.
- It offers an alternative to @longdesc and @aria-describedby — when either of them does not work (e.g in a text browser)
- It would work well in tandem with @aria-describedby (which could point to the content of
object
) - 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 theusemap
attribute as the only way to turn theobject
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 ap
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 theobject
what works. (There was also an issue in Firefox 9 — but this got fixed in Firefox 10, see below).- Counter argument: Trident is being updated — this is already an issue of the past roughly since at least IE8.
- 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 ofobject
. Additionally, that issue was fixed with Firefox 10. - 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
- 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 useobject
, 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 ofobject
as well.
- Counter argument: This is not i particular related to the issue of the content model of
- It promotes use of
aria-describedby
for presenting the fallback ofobject
(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.
- 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
- 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 thelongdesc
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 insideobject
, then it would probably be possibel to use this method instead of usinglongdesc
— however, that issue is nevertheless not related to this CP. The AT issues with fallback insideobject
— 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
- 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
insidep
elements as essentally against the very nature of HTML. However, HTML4/XHTML1 have always allowedp
inidep
andh1
-h6
elements, as long as the “misnested” element (thep
in thep
or in some other “illegal” place) is wrapped inside abutton
,object
ormap
element. - 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 ap
or a in ah1-h6
element, as long as you usebutton
,object
ormap
as wrapper: Try this document in the validator (look at the source code at the bottom of the validator page). - 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:
- 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 possiblep
parent of theobject
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.
- 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. @
- 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 inobject
’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; - 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.
- We increase the utilty of
- 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 ofobject
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 theobject
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.
- 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 @
- 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
insidep
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. - The
object
element is not unique within HTML5: This CP’s proposed content model forobject
differs from that of the new media elements —video
,audio
,canvas
. The new media elements work the same way that the CCP would like theobject
to (be considered to) be working: If one does e.g. add ap
in avideo
which hasp
as its parent (<p><video><p></video>
), then the innerp
will be moved outside of both thevideo
element and the outerp
element, thus resulting in a DOM with two parallel — also known as adjacent —p
elements. However, this does not prevent authors from addingp
insidevideo
: All it takes is that authors makes sure the parent of the media element is something other than thep
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 forvideo
adnaudio
, then — unlike forobject
— the fallback, quote: “is not intended to address accessibility concerns”, and so the limited content model should not hamper accessibility. (But w.r.t. thecanvas
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, theobject
is not the sole element that the HTML5 parser treats this way: In addition toobject
then bothbutton
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
insidep
does work and — B — authors can see that that is how it works.
Which model is best, theobject
model or thevideo
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
- 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 containtextarea
. And yes, atextarea
as childobject
that in turn was the child of abutton
, 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 theobject
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 atextarea
is useful as fallback for any thing thatobject
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. - HTML5 itself includes code examples where there are a link inside an interactive element: When
video
oraudio
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 insideobject
even if it has the @usemap
attribute. And, equivalently, when the @controls
attribute is present onvideo
andaudio
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 thevideo
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. - 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.
- 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. atable
is not possible in the fallback if theobject
’s parent is ap
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:
- 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 thep
to do the nesting. - Consequently, the way HTML5 defines it, it does not matter whether the paragraph is represented by a
li
,p
or adiv
. And so, even today, authors can embed e.g. a table inobject
— it is just that they must, in order to be valid, take care to change the parentp
into e.g. adiv
. - 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 atable
is suitable as fallback for theobject
, does not — in real life — depend on whether the parent of theobject
is ap
or adiv
. 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 becauseobject
's parent tag doesn't allow it.
- 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
- 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 adiv
— 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
- Test file nested anchors (
<a href=*>Foo<object><a href=*>foo</a></object></a>
).
Corrections
Corrections since the submission to the HTMLwg:
- 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 thetabindex
attribute has any such effect: It is only when theusemap
attribute is present, that HTML5 considersobject
interactive content.)
- Why: The text wrongly indicated that the HTML5 spec considers that presence of
- 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.
- Added author signature on top of the page.
- Why: For clarificaiton
- 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.
- Added a NOTE point under list item 2 inside the rationale section #For interactive content as child of an object whose parent is interactive.
- Why: Because I took for granted that HTMl5 considers the
area
elemetn to be interactive content, however at the time of this writing,area
is not listed by HTML5 as interactive content.
- Why: Because I took for granted that HTMl5 considers the
- 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.
- 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.