*** Bug 10636 has been marked as a duplicate of this bug. ***

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Do you mean what are the rendering rules? The mapping to CSS is listed in the Rendering section. Or do you mean what is the content model? That's listed in the element definitions. Or something else?

I'm not sure what "flow behaviours" are.

My apologies for not being clear.

"flow control" refers to an element's affect on content before and after it. a SPAN tag by default has no affect on flow. H1, DIV, LI, BR, and similar tags DO affect flow. Currently the ARTICLE, and similar elements, behavior is undefined. I believe that such tags should be block-level elements, i.e: affect flow control by applying the box model to the content, effectively making these elements behave like DIV or H tags. However, it could be just as valuable to make the default behavior be one similar to span tags. My point is that is is NOT DEFINED ANYWHERE in the spec. I looked for hours.

While it would be easy to override the initial behavior with CSS, the default behavior should still be defined.

Perhaps this is an issue which should be moved to the RENDERING section.

I believe this is already adequately addressed in the spec. An element in the category of Phrasing content (cite, say) doesn't affect flow; an element not in the Phrasing content category (div, say) does.

Thank you. The behavior is somewhat defined in the "Content Models" Section. Specifically regarding "Phrasing Content" with respect to the definition of the term "paragraphs." However, the behavior of "Flow Content" is not clearly defined, but only infered by the definition of "Phrasing Content."

Specifically, "Phrasing Content," is defined only as "runs of phrasing content form paragraphs." A summary of the Paragraphs definition is, "uninterrupted runs of phrasing content (and text) will be considered a 'paragraph.'" While I can ASSUME that means that all (almost all) phrasing content essentially acts like pure text: not creating any (like pure text) carriage returns. By extension I can INFER based on that ASSUMPTION that "Flow Content" does have such an affect. Unfortunately, I still don't see where it is clearly defined.

This is much closer to what I was hoping for, but still seems like it needs a more clear definition.

For anyone out there who happens by this report, read through here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html

The closest answer I have gleaned so far is an inference that flow-control objects (like article) WILL break-up phrasing-content (like pure-text, span, and a).

It sounds like what you describe as "flow control" is rendering rules, and those are described in detail in the rendering section. Does that address your concern? (Rendering rules have nothing to do with the content models, though. The content models are only about what is allowed where.)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 6

That's the first place I looked. It is kindof defined there. But the whole flow-control section is entirely ambiguous. This probably is an issue for there instead of here.

Marked as resolved.

However, intentionally creating ambiguous rendering guidelines is NOT a good idea in my opinion.