17:56 < hsivonen> zcorpan_: I want the top edge of the figure to align with the 
                  top edge of the paragraph text if the paragraph has a top 
                  margin or even padding plus border
17:57 < zcorpan_> hsivonen: i take it you want figure to be phrasing content 
                  with transparent content model (plus figcaption)?
17:58 < hsivonen> zcorpan_: it want it to be phrasing, yes
17:58 < hsivonen> zcorpan_: I'd prefer non-transparent and scoping but maybe 
                  that's too much to ask for considering Degrade Gracefully
17:58 < zcorpan_> hsivonen: what if you want it to align with the paragraph 
                  text but the figcaption contains several paragraphs?
17:59 < hsivonen> zcorpan_: hence I'd prefer non-transparent and scoping
17:59 < zcorpan_> maybe you should say that in the bug
18:00 < zcorpan_> <figcaption> can still close <p> if <figure> is scoping

When considering tweaking the parsing algorithm, please consider that implementations are starting to ship.  For example, Chrome will likely be shipping the HTML5 parsing algorithm in Chrome 7.  However, we're already past the branch point for Chrome 7, which means we're unable to make gratuitous changes to the parser for that release.

Of course, we can make changes in future releases, depending on the risk/reward trade-off.  However, I'd prefer if we stopped tweaking the algorithm for aesthetics.

From my POV, making <figure> and <summary> close <p> are gratuitous changes considering what's on track for shipping in Firefox 4. :-/

> From my POV, making <figure> and <summary> close <p> are gratuitous changes
> considering what's on track for shipping in Firefox 4. :-/

I guess it's a matter of when you draw the baseline.  If there were some sites that worked better with one behavior or the other, that would be a good basis on which to make a decision.  However, in the absence of such data, I'd be inclined not to make changes to the algorithm at this point.

Since the bug report is about avoiding breaking the anticipated float designs that <figure> was supposed to be good for, data about existing sites doesn't work as a guide except for examining cases where <figure> is emulated with <span class>.

FWIW, from a web-designers perspective, spreading the ugly "<p> auto-closes when someone sneezes near it" behavior to new elements is really annoying.  I would vastly prefer <p> never auto-closing in any situation that wasn't explicitly required by legacy content.

(That includes things like <p><section>, which you could justify with "well, that doesn't make sense".  I don't care.  It will be put to use somewhere, and more magical auto-closing won't help anyone.)

<figure> isn't allowed in <p>; it's flow content, not phrasing content.

(In reply to comment #7)
> <figure> isn't allowed in <p>; it's flow content, not phrasing content.

Please change the conformance definition to allow <figure> in <p>.

Making <figure> phrasing-level seems at odds with its semantics. When would you ever want <figure> in the middle of a paragraph?

Having it at the start (as per comment 0) or end of a paragraph makes sense, but is completely compatible with just putting the <figure> before or after the <p>.

<figure> is supposed to be equivalent to <div class="figure">, not <span class="figure">.

In particular, if we made <figure> phrasing, we'd have to also make it scoping, since otherwise you couldn't put <pre> or <p> into <figure> in certain weird cases.

(In reply to comment #9)
> Making <figure> phrasing-level seems at odds with its semantics. When would you
> ever want <figure> in the middle of a paragraph?

Whether putting a figure in the middle of a paragraph makes sense should be irrelevant. I value CSS pragmatism over semantics. I think the spec should, too, considering the design principles if you read "CSS pragmatism" as "authors" and "semantics" as "theoretical purity".

> Having it at the start (as per comment 0) or end of a paragraph makes sense,
> but is completely compatible with just putting the <figure> before or after the
> <p>.

My understanding is that it isn't from the CSS formatting model perspective.

> <figure> is supposed to be equivalent to <div class="figure">, not <span
> class="figure">.

I had thought the opposite when I thought adding <figure> was a good idea.

> In particular, if we made <figure> phrasing, we'd have to also make it scoping,
> since otherwise you couldn't put <pre> or <p> into <figure> in certain weird
> cases.

Indeed--as noted in comment 1.

Clearly CSS pragmatism isn't everything, or we'd just give up on semantics altogether, and HTML is a heck of a long way from that. Theoretical purity isn't bad... it's not the only goal, for sure, but it's still a consideration. We are trying to design a good media-independent, device-independent, markup language, not just trying to provide a set of hacks for making pretty layouts.

If all you want to do is align the top of a figure with the top of a paragraph after the figure, with the figure floated, just put the figure and the following paragraph in a <div> together. That will make the top margin of the paragraph collapse with the top margin of the div and the float will align below that top margin.

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: Rejected
Change Description: no spec change
Rationale: Whether something makes sense is absolutely relevant to whether it should be allowed. That's the whole point of having conformance criteria: it allows tools (validators) to help authors who have accidentally done something that doesn't make sense to have those errors pointed out to them. Also, adding more things to the parser that scope is bad, as it just makes the algorithm more complicated.

Escalating per Decision Policy step 5.d.

I volunteer to write a Change Proposal. The key parts of the proposal will be:
 1) Validity should allow <figure> where <img> is allowed
 2) <figure> should not close <p> in the tree builder
 3) <figure> should be scoping in the tree builder
 4) The display property for figure and figcaption should probably not be block in the UA style sheet. (I'm not yet sure what the appropriate defaults would be, but I'm guessing table and table-row respectively.)

Proposed text for Tracker:

Short name:
figure-in-p

Title:
Authors should be able to use <figure> where <img> can be used

Description:
Escalated from http://www.w3.org/Bugs/Public/show_bug.cgi?id=10589

Currently, HTML5 makes it impossible to for HTML authors to use <figure> as a child of <p>, because <figure> automatically closes <p> in the tree builder.

This is bad for authors on the conceptual level, because <figure> is primarily supposed to be a way to express images that have a caption, so being unable to use <figure> in places where <img> can be used is conceptually confusing.

This is bad for authors on the pragmatic level, because given the CSS features available to authors currently and in the foreseeable future, the easiest way to make the top edge of a float align with the top edge of the text in a block regardless of margin/padding/border on the block box is to place the float as the first child of the block. That is, one would want to place <figure> as the first child of <p> when making a floating figure associated with a paragraph. Floating figures are the typical expected use for <figure>.

For <figure> to be useful to authors, it is essential to make it easy to use <figure> where <img> can be used and, in particular, to make it easy to use floating figures within the practical constraints arising from the CSS formatting model as it is available to authors today.

I didn't realize I was empowered to write to Tracker:
http://www.w3.org/html/wg/tracker/issues/128

Setting to VERIFIED, TrackerIssue per Policy.

I started drafting a Change Proposal at http://www.w3.org/html/wg/wiki/ChangeProposals/FigureInP