Probably needed in particular for % widths, and the like.

Checked in as WHATWG revision r7644.
Check-in comment: Updates to anchoring for dialogs.
http://html5.org/tools/web-apps-tracker?from=7643&to=7644

I think we want dialog's containing block to be the icb always, but it looks like r7644 just does that for anchored positioning (and not for the "set up the default static position" steps).

Or am I missing something?

Hm. We can't really change the containing block if e.g. 'position' computes to 'static', that would make no sense. I support we could force it also in the case of 'position' computing to 'absolute' if you've gone through show() though ("set up the default static position"). Would that work? Or maybe just always, if 'position' is 'absolute'?

(In reply to comment #4)
> Hm. We can't really change the containing block if e.g. 'position' computes
> to 'static', that would make no sense. I support we could force it also in
> the case of 'position' computing to 'absolute' if you've gone through show()
> though ("set up the default static position"). Would that work? Or maybe
> just always, if 'position' is 'absolute'?

I think either would work. The latter may make implementation slightly simpler. An added benefit is that the appearance and positioning would be consistent with modal dialogs, which are always abspos in the icb, by virtue of being in the top layer.

Actually, is there a good use case for a dialog with position: static (and relatedly, position: relative)? I think most use cases are for abspos or anchored positioning. In my implementation, I'm trying to get it to work for those first. 

So maybe it's worth considering making dialog's containing block always the icb. This can be implemented by moving dialog's renderer in the render tree to be a child of the root.

(In reply to comment #5)
> Actually, is there a good use case for a dialog with position: static (and
> relatedly, position: relative)? I think most use cases are for abspos or
> anchored positioning. In my implementation, I'm trying to get it to work for
> those first. 
> 
> So maybe it's worth considering making dialog's containing block always the
> icb. This can be implemented by moving dialog's renderer in the render tree
> to be a child of the root.

I think most staticpos use-cases are just attempts to do a poor-man's anchorpos.  If anchorpos works fine with the ICB as containing block (which I think it does), then we're great.

What I've done now for Blink is make dialog's containing block the ICB whenever 'position' is 'absolute'.

Relatedly, we probably want offsetParent to evaluate to null, similar to fixpos behavior.

My biggest problem with making <dialog> magic in all cases, e.g. by having it forced to position:absolute (or anything not 'static'), or changing its CB to the ICB in all cases when it has position:absolute, is that it means that <dialog> becomes very magical and unable to act like a normal element. We've got elements like that already, like <fieldset>, and it causes no end of trouble.

I ended up making it work that way anyway. Basically, <dialog> is magic.

Feel free to reopen (or file a new bug) if you don't like the new requirements.

Checked in as WHATWG revision r7981.
Check-in comment: Simplify <dialog> positioning logic. Basically, the CB is always the ICB, and the static position gets reset more often than before.
http://html5.org/tools/web-apps-tracker?from=7980&to=7981

(In reply to Ian 'Hixie' Hickson from comment #9)
> I ended up making it work that way anyway. Basically, <dialog> is magic.
> 
> Feel free to reopen (or file a new bug) if you don't like the new
> requirements.

What if we remove this magic and instead say dialog.show() adds dialog
to the top layer, like showModal()? This would:
- Remove the magical abspos <dialog> handling during layout.
- Allow a modal dialog to pop-up a non-modal dialog above it.
- Make it easy to implement a sane stacking order for non-modal dialogs.
Currently, Blink implements abspos non-modal dialogs by moving its
render object to be parented by the root view. This means z-index
stacking is not respected. In order to respect z-index we'd have to do
some ugly handling to make the dialog positioned relative to its render
tree position but stacked relative to its DOM tree ancestors. We don't
have any element that behaves like that.

One concern is with anchored positioning. It might be you want an
anchored dialog to be stacked relative to its anchor. There are some
ways to approach that:
- Say dialog.show(anchor) doesn't push on the top layer
- Offer anchored positioning as a general feature not limited to
<dialog>. So you might be able to do something like anchor a <dialog
open> or just a <div> without calling dialog.show(), which does
something more powerful.

Another concern is dialog::backdrop styling would kick in for
non-modals. Maybe we need a modal attribute, and a default styling for
dialog[modal]::backdrop instead.

What do you think?

Ian said on IRC he doesn't feel he understands the problem in enough
detail, and is AFK for a few days, so I'll try to explain better in this
comment.

The main problem I'm trying to solve is the magical abspos <dialog>
positioning. Looking at the comments on this bug, no one was so happy
with it in the first place (I was the main advocate).

Related to that, we have a stacking problem with non-modal <dialog>. It
would be difficult for Blink to both magically change <dialog>'s
containing block to the ICB and keep its non-magical stacking context.
Although in theory the stacking context is independent of containing
block, in practice they are related. Blink constructs its stacking
contexts by traversing the render tree, so when we move <dialog>'s
renderer to be under the root (the ICB magic), its parent stacking
context becomes the root stacking context.

So, from an implementor point of view, I want to say: either you get the
magical ICB containing block *and* root stacking context, or neither. 
I.e., I want to say dialog.show() busts out of the containing block and
stacking context. If you want one but not the other, you can't use
dialog.show(). Instead you position and stack using typical CSS
methods.

So, a way to fix both problems is may be to have dialog.show() push
dialog on the top layer.

Another solution could be to say dialog.show() puts the dialogs
immediately beneath the top layer and stacked relative to each other
(either by typical z-index or by the temporal order of dialog.show()
calls).  But it'd be useful to allow a modal <dialog> to pop-up a
non-modal above it.

(In reply to Matt Falkenhagen from comment #12)
> The main problem I'm trying to solve is the magical abspos <dialog>
> positioning.

I don't understand why it's a problem. It seems to work well.


> Related to that, we have a stacking problem with non-modal <dialog>. It
> would be difficult for Blink to both magically change <dialog>'s
> containing block to the ICB and keep its non-magical stacking context.
> [...]
> So, from an implementor point of view, I want to say: either you get the
> magical ICB containing block *and* root stacking context, or neither. 

Ok.


> So, a way to fix both problems is may be to have dialog.show() push
> dialog on the top layer.

That seems reasonable.

We'd also remove and readd <dialog> elements that are already on the top layer, when they are focused, so that the latest focused dialog is actually the top one.


> Another solution could be to say dialog.show() puts the dialogs
> immediately beneath the top layer and stacked relative to each other
> (either by typical z-index or by the temporal order of dialog.show()
> calls).

Introducing yet another layer seems like something to avoid if we can.


Changing "When an element is added to the pending dialog stack, it must also be added to the top layer layer" to just having show() and showModal() do this themselves directly, seems reasonable to me. Would that solve this bug to your satisfaction, or is there more to it?

(In reply to Ian 'Hixie' Hickson from comment #13)
> (In reply to Matt Falkenhagen from comment #12)
> > The main problem I'm trying to solve is the magical abspos <dialog>
> > positioning.
> 
> I don't understand why it's a problem. It seems to work well.

I guess comment 8 put it best. It also demands special casing <dialog> in a core rendering codepath which isn't so great. It seems better to contain the magic so it's not something <dialog> does in all cases.

> We'd also remove and readd <dialog> elements that are already on the top
> layer, when they are focused, so that the latest focused dialog is actually
> the top one.

That's sounds right. I do configure my window manager to not auto-raise focused windows though.

> Changing "When an element is added to the pending dialog stack, it must also
> be added to the top layer layer" to just having show() and showModal() do
> this themselves directly, seems reasonable to me. Would that solve this bug
> to your satisfaction, or is there more to it?

We'll also want to:
- Change "If at any time a dialog element is removed from a Document..." to remove from top layer.
- Change the default styling so that the modal and non-modal dialogs don't have the same ::backdrop. This may require adding a 'modal' attribute.

Actually I guess what needs to happen is that any time the <dialog> starts being rendered, it goes into the top layer, just like it gets mundanely statically positioned at that point. (The show() method with no argument is no different than just setting the open="" attribute.)

The problem with a modal="" attribute is that it makes no sense, fundamentally. You can't set it in a meaningful sense, it's just internal browser state. (That is, consider what a page with <dialog open="" modal=""> would mean.)

The way we normally expose that is via pseudo-classes, e.g. ":modal". I suppose we could introduce something like that. It seems a bit special-purpose though.

The more I think about it, the less sure I am that it's a good idea to put non-modal dialogs into the top layer, actually. What if you have a scrollable area with windows in it? If we move things into the top layer, it no longer works; they no longer get clipped by the overflow mechanism. They just spill out. Do we really want that?

Maybe the right direction isn't to put non-modals in the top layer, but to make non-modals not use the ICB as their containing block... Can you remind me why we had made the ICB the CB for all <dialog>s, even non-modal ones?

(In reply to Ian 'Hixie' Hickson from comment #15)
> The more I think about it, the less sure I am that it's a good idea to put
> non-modal dialogs into the top layer, actually. What if you have a
> scrollable area with windows in it? If we move things into the top layer, it
> no longer works; they no longer get clipped by the overflow mechanism. They
> just spill out. Do we really want that?

Yes, absolutely.  No other platform allows dialogs to be clipped by an overflow mechanism inside the app, because it's a really weird and terrible thing to do.

> Maybe the right direction isn't to put non-modals in the top layer, but to
> make non-modals not use the ICB as their containing block... Can you remind
> me why we had made the ICB the CB for all <dialog>s, even non-modal ones?

You don't want dialogs being clipped by their ancestors.  This'll happen lots by accident, and will just mean that everyone puts their <dialogs> as children of <body> rather than in a reasonable location near where they're used.

~TJ

(In reply to Ian 'Hixie' Hickson from comment #15)
> Actually I guess what needs to happen is that any time the <dialog> starts
> being rendered, it goes into the top layer, just like it gets mundanely
> statically positioned at that point. (The show() method with no argument is
> no different than just setting the open="" attribute.)

Ah, I didn't notice this requirement. Blink just centers the dialog on show().

Having something happen when something starts being rendered is a bit wacky, since it's difficult to predict when something starts being rendered. Setting open="", for example, marks the dialog as needing style recalc and needing to be rendered later on, but it's practically non-deterministic when that will happen. The end result is where the <dialog> is positioned and stacked (given multiple non-modal <dialog open="">) appears random. I think we want to center and push on the top layer on show() and do anything special for <dialog open="">.

> Maybe the right direction isn't to put non-modals in the top layer, but to
> make non-modals not use the ICB as their containing block... Can you remind
> me why we had made the ICB the CB for all <dialog>s, even non-modal ones?

As Tab said, we wanted <dialog> to not get clipped by its ancestors, which is consistent behavior with centering it in the viewport. It's weird to center it yet have it clipped or affected by % lengths of something it's not visibly inside of.

(In reply to Matt Falkenhagen from comment #17)
> I think we want to center and push on the top layer on show() and do anything
> special for <dialog open="">.

Should read: and not do anything special for <dialog open="">

One example of when you'd want something clipped is when you have an scrollable area (could be done as an iframe, but need not be) that shows a big page, and in that page you have a window that's anchored to another UI widget, providing help information. If the user scrolls that widget off the page, you don't want that anchored window to be visible when the widget it's pointing to isn't.

The anchored help window thing isn't hypothetical; Google, for example, does it all the time. The scrolling UI widgets aren't hypothetical either; G+ or Facebook are good examples of that. If you have a help window hovering over some aspect of G+'s UI, and you scroll that up, it shouldn't overlap the header at the top, since then it would be confusingly pointing at some entirely unrelated piece of the page.


(In reply to Matt Falkenhagen from comment #17)
> 
> Having something happen when something starts being rendered is a bit wacky,
> since it's difficult to predict when something starts being rendered.

Yeah. The better way to think about it is just that the requirement always applies, whether it's being rendered or not, it's just that it only really makes sense while it's being rendered. Instead of describing the rendering in terms of a constraint, the way CSS usually does, I described it in terms of algorithms that fire whenever the constraint would change (showing, resizing, etc).

Fundamentally though you should just think of it the same way that the regular static position works, just with a different algorithm (instead of "when the element starts being rendered, lay it out without abs pos, grab the top position of that box, then lay it out with abs pos, and set the static position to that top", you do the algorithm in the HTML spec for working out the position).


> The end result is where the <dialog> is positioned and
> stacked (given multiple non-modal <dialog open="">) appears random.

I don't understand. Why would it be random? It's well-defined, AFACIT.


> As Tab said, we wanted <dialog> to not get clipped by its ancestors, which
> is consistent behavior with centering it in the viewport. It's weird to
> center it yet have it clipped or affected by % lengths of something it's not
> visibly inside of.

I agree that if we clip it we probably don't want to center it relative to the ICB either. We should probably center it relative to the region it can scroll in, or something like that. Or maybe for regular non-modal windows, we just use the regular static position, not centered? Most non-modals aren't going to be centered, they're going to be free-floating.

(In reply to Ian 'Hixie' Hickson from comment #19)
> > The end result is where the <dialog> is positioned and
> > stacked (given multiple non-modal <dialog open="">) appears random.
> 
> I don't understand. Why would it be random? It's well-defined, AFACIT.

AFAIK Blink doesn't guarantee an ordering of attaching renderers. So if you propose putting <dialog> in the top layer when it's rendered, if you have
  <dialog open>
  <dialog open>
  <dialog open>
The stacking between them can come out in any order.

For positioning, it'd also be hard to reason about where a <dialog> ends up especially if there's dynamic DOM/style changes and scrolling. With dialog.show you're guaranteed the centering occurs when dialog.show is invoked.

> 
> 
> > As Tab said, we wanted <dialog> to not get clipped by its ancestors, which
> > is consistent behavior with centering it in the viewport. It's weird to
> > center it yet have it clipped or affected by % lengths of something it's not
> > visibly inside of.
> 
> I agree that if we clip it we probably don't want to center it relative to
> the ICB either. We should probably center it relative to the region it can
> scroll in, or something like that. Or maybe for regular non-modal windows,
> we just use the regular static position, not centered? Most non-modals
> aren't going to be centered, they're going to be free-floating.

I think something like this could be good. What do you mean by regular non-modal windows?

How about use dialog.show() to put on the top layer; and <dialog open> without show/showModal has no special positioning?

(In reply to Matt Falkenhagen from comment #20)
> How about use dialog.show() to put on the top layer; and <dialog open>
> without show/showModal has no special positioning?

I forgot I already proposed that. Alternatively, maybe non-modals just don't have any special positioning?

(In reply to Matt Falkenhagen from comment #20)
> (In reply to Ian 'Hixie' Hickson from comment #19)
> > > The end result is where the <dialog> is positioned and
> > > stacked (given multiple non-modal <dialog open="">) appears random.
> > 
> > I don't understand. Why would it be random? It's well-defined, AFACIT.
> 
> AFAIK Blink doesn't guarantee an ordering of attaching renderers. So if you
> propose putting <dialog> in the top layer when it's rendered, if you have
>   <dialog open>
>   <dialog open>
>   <dialog open>
> The stacking between them can come out in any order.

Well then that's a bug. The stacking order should be the order they were added to the top layer, which would be the order they're added to the DOM, which is the order they're parsed, which is the order they're in the markup, in this case. (At least, assuming we make this put them in the top layer, which the spec doesn't currently say, and which we're debating.)

I agree it would be a problem in the case of the parent element of multiple <dialog open>s being display:none and then it being changed so all three start being rendered simultaneously, but IMHO if we have that problem we should break ties by tree order.


> For positioning, it'd also be hard to reason about where a <dialog> ends up
> especially if there's dynamic DOM/style changes and scrolling. With
> dialog.show you're guaranteed the centering occurs when dialog.show is
> invoked.

I don't understand what would be hard to reason. Can you elaborate?


> > I agree that if we clip it we probably don't want to center it relative to
> > the ICB either. We should probably center it relative to the region it can
> > scroll in, or something like that. Or maybe for regular non-modal windows,
> > we just use the regular static position, not centered? Most non-modals
> > aren't going to be centered, they're going to be free-floating.
> 
> I think something like this could be good. What do you mean by regular
> non-modal windows?

An open <dialog> not opened via showModal().

I think this is what you are proposing when you say "maybe non-modals just don't have any special positioning".

(In reply to Ian 'Hixie' Hickson from comment #22)
> (In reply to Matt Falkenhagen from comment #20)
> > (In reply to Ian 'Hixie' Hickson from comment #19)
> > > > The end result is where the <dialog> is positioned and
> > > > stacked (given multiple non-modal <dialog open="">) appears random.
> > > 
> > > I don't understand. Why would it be random? It's well-defined, AFACIT.
> > 
> > AFAIK Blink doesn't guarantee an ordering of attaching renderers. So if you
> > propose putting <dialog> in the top layer when it's rendered, if you have
> >   <dialog open>
> >   <dialog open>
> >   <dialog open>
> > The stacking between them can come out in any order.
> 
> Well then that's a bug. The stacking order should be the order they were
> added to the top layer, which would be the order they're added to the DOM,
> which is the order they're parsed, which is the order they're in the markup,
> in this case. (At least, assuming we make this put them in the top layer,
> which the spec doesn't currently say, and which we're debating.)
> 
> I agree it would be a problem in the case of the parent element of multiple
> <dialog open>s being display:none and then it being changed so all three
> start being rendered simultaneously, but IMHO if we have that problem we
> should break ties by tree order.

I think we may be talking about different things. To me, "starts being 
rendered" meant when a renderer is attached, which is more of a 
low-level concept than something like "when it starts being painted on
screen".

The renderer attach order isn't necessarily in DOM tree order, but the 
ultimate ordering of the render tree is.

So to do the top layer proposal, I think we'd have to build the whole 
render tree first, then do a pass over the render tree to add dialogs to
the top layer in the correct order.

> > For positioning, it'd also be hard to reason about where a <dialog> ends up
> > especially if there's dynamic DOM/style changes and scrolling. With
> > dialog.show you're guaranteed the centering occurs when dialog.show is
> > invoked.
> 
> I don't understand what would be hard to reason. Can you elaborate?

I think it again depends on what "starts being rendered" means. It can't
be when a renderer is attached, since the height of the document is not
known yet so we can't know the center position. If it's on first layout
of the <dialog>, we have the same problem. If it's the first time you're
about to paint the <dialog>, I guess you can calculate the center
position and relayout the dialog appropriately, because you can probably
assume the whole page has been laid out, but it's a bit weird and maybe
infeasible for painting to reach in and change layout. Furthermore, if
the page still has pending stylesheets or DOM changes, the ultimate
position of the dialog can easily be uncentered.

> > > I agree that if we clip it we probably don't want to center it relative to
> > > the ICB either. We should probably center it relative to the region it can
> > > scroll in, or something like that. Or maybe for regular non-modal windows,
> > > we just use the regular static position, not centered? Most non-modals
> > > aren't going to be centered, they're going to be free-floating.
> > 
> > I think something like this could be good. What do you mean by regular
> > non-modal windows?
> 
> An open <dialog> not opened via showModal().
> 
> I think this is what you are proposing when you say "maybe non-modals just
> don't have any special positioning".

Yeah, that's what I had in mind.

"being rendered" is a term of art defined in the HTML spec as having "any associated CSS layout boxes, SVG layout boxes, or some equivalent in other styling language".

   http://www.whatwg.org/specs/web-apps/current-work/#being-rendered

CSS defines when an element has a CSS box; it has mostly to do with the computed value of the 'display' property, though that's a simplification.


Anyway. I think the proposal here is that we leave the modal dialogs as specified, but we change non-modals to just be regular position:absolute boxes. Does that make sense?

(In reply to Ian 'Hixie' Hickson from comment #24)
> Anyway. I think the proposal here is that we leave the modal dialogs as
> specified, but we change non-modals to just be regular position:absolute
> boxes. Does that make sense?

Sounds good to me. Of course, the author should be able to set position:static or whatever and it will work as a normal element, right? That is, position:absolute is just specified in the default CSS for dialog.

Yeah.

Checked in as WHATWG revision r8448.
Check-in comment: Make non-modal <dialog>s use the regular containing block, since they're not on the top layer.
http://html5.org/tools/web-apps-tracker?from=8447&to=8448

Is that sufficient? Did I miss something?

"it must also be added to the top layer layer and its containing block must be the initial containing block"

will mean fixpos modal dialogs don't act like normal fixpos elements-- the containing block should be the viewport. Since the top layer already specifies  containing block behavior, maybe there's no need to mention containing block in the spec?

Why did we add it in the first place then?

(In reply to Ian 'Hixie' Hickson from comment #30)
> Why did we add it in the first place then?

We added "The containing block of all dialog elements that are absolutely positioned must be the initial containing block." to handle the containing block of non-modal dialogs, which were never spec'd to be in the top layer.

So, now I'm confused. I thought we added that because it was necessary for implementations, but now we're removing it, because of the opposite? Did we change something else about non-modal dialogs to make this less problematic? It seems like we're just reverting back to what I had originally specced, before we added the ICB rule. Which is fine by me, but then I don't understand why we had to change it in the first place...

I thought we're changing the spec to make non-modal <dialog> have no special positioning: it's not centered and has no special clipping or containing block. It's just a normal box.

If that's the idea, the missing piece is to change the "set up the static default position" algorithm to happen only as part of the steps for showModal().

Ah, right. Somehow I missed that.

Ok, how's this:

Checked in as WHATWG revision r8457.
Check-in comment: Make non-modal dialogs not center automatically.
http://html5.org/tools/web-apps-tracker?from=8456&to=8457

Thanks, the new patch is good.

For the record, the Blink implementation currently centers only on showModal() and not (1) when new render boxes are created or (2) the viewport width changes. I'll have to revisit those issues in the implementation.

One minor thing, the "the containing block is the initial containing block" note in the anchored positioning section looks inconsistent with the rest of the text, as we no longer say an abspos dialog's containing block in the ICB.

Yeah, good catch. Ok, I've removed that note.

Marking FIXED; please don't hesitate to reopen if you find another problem! Thanks for your patience in explaining the issues here, sorry I was so dense.

Checked in as WHATWG revision r8474.
Check-in comment: Remove now-redundant paragraph.
http://html5.org/tools/web-apps-tracker?from=8473&to=8474