Intent to Ship: <dialog> element

[Matt Falkenhagen]

Primary eng (and PM) emails

fal...@chromium.org (eng)

kenji...@chromium.org (PM)

Spec

http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#the-dialog-element

Summary

An HTML element for a pop-up in a web page. Dialogs exist in DOM and can be styled with CSS as usual. They can be optionally page-modal and have special positioning properties (centered within the viewport by default).

Link to “Intent to Implement” blink-dev discussion

This work started in WebKit: https://lists.webkit.org/pipermail/webkit-dev/2012-July/021343.html

Motivation (as it would have appeared in our “Intent to Implement”)

Dialogs are such common UI components today that it makes sense to support them natively. This page shows many real world examples. Web developers have expressed positive interest in this feature.

Hand-rolled dialogs, even those provided by frameworks, often have accessibility problems (pages like here and here detail the difficulties of getting it right). Accessibility is a major motivation for the <dialog> spec, see: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-133 and http://www.w3.org/html/wg/wiki/ChangeProposals/modal

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

Demo link

http://demo.agektmr.com/dialog/

Compatibility Risk

<dialog> is part of the W3C and WHATWG HTML specifications.

The biggest risk is that other vendors are not yet implementing this feature. However, they have commented positively about it. Most seem to agree it's a nice feature to have and is uncontroversial since it basically just provides natively what many existing JS frameworks provide, but they just haven't prioritized its implementation.

For example, when WebKit folks removed the bit-rotted <dialog> implementation, there were comments that they'd like to eventually support it and are not purposely postponing it.

Mozilla has a bug including a testcase.

OWP launch tracking bug?

http://crbug.com/140205

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5770237022568448

[Jochen Eisinger]

lgtm

[Ian Hickson]

On Fri, 13 Dec 2013, Matt Falkenhagen wrote:
>
> An HTML element for a pop-up in a web page. Dialogs exist in DOM and can
> be styled with CSS as usual. They can be optionally page-modal and have
> special positioning properties (centered within the viewport by
> default).

My only concern would be that we should make sure to get the focus stuff
right really soon if we don't do it before we ship. The spec side of this
is still evolving but hopefully should be nailed down soon.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Dominic Mazzoni]

+1 - I'm not an api owner, but this has my support.

On Fri, Dec 13, 2013 at 9:00 AM, Ian Hickson <i...@hixie.ch> wrote:

My only concern would be that we should make sure to get the focus stuff

right really soon if we don't do it before we ship. The spec side of this
is still evolving but hopefully should be nailed down soon.

Agreed that we need to make sure we get this right - but it looks to me like there's consensus about the common case of a dialog with at least one focusable control in it, and the only questions might be about dialogs without any controls, and what happens when controls lose focus. Is that a fair summary? If so, I think it's reasonable to ship with the current implementation because the compatibility risk of small changes to the behavior of corner cases is low.

[Ian Hickson]

There are lots of questions. For example, what happens when you tab from
the last control of a dialog, when you have multiple non-modal dialogs
visible? What gets focus if you open a dialog and then close it again, if
something had focus before?

I'm not saying this should block shipping, just that we should make sure
to have this stuff in mind and be ready to fix it up sooner rather than
later.

Nobody seems to have raised any objections with the proposal yet, so
hopefully I'll be able to spec it out in a few days. (The proposal also
tidies up a lot of looose ends with focus, like what the story is with
'overflow:scroll' regions, which no spec currently talks about, but
which should clearly be focusable.)

[Dominic Mazzoni]

On Fri, Dec 13, 2013 at 10:20 AM, Ian Hickson <i...@hixie.ch> wrote:

There are lots of questions. For example, what happens when you tab from

the last control of a dialog, when you have multiple non-modal dialogs
visible? What gets focus if you open a dialog and then close it again, if
something had focus before?

Great questions, but I don't think I've ever seen a site that rolls its own dialogs get these details right either, so fixing these cases is unlikely to break any early adopters of <dialog>.

I'm not saying this should block shipping, just that we should make sure
to have this stuff in mind and be ready to fix it up sooner rather than
later.

Nobody seems to have raised any objections with the proposal yet, so
hopefully I'll be able to spec it out in a few days. (The proposal also
tidies up a lot of looose ends with focus, like what the story is with
'overflow:scroll' regions, which no spec currently talks about, but
which should clearly be focusable.)

Great!

[Matt Falkenhagen]

On Sat, Dec 14, 2013 at 3:30 AM, Dominic Mazzoni <dmaz...@chromium.org> wrote:

On Fri, Dec 13, 2013 at 10:20 AM, Ian Hickson <i...@hixie.ch> wrote:

There are lots of questions. For example, what happens when you tab from

the last control of a dialog, when you have multiple non-modal dialogs
visible? What gets focus if you open a dialog and then close it again, if
something had focus before?

Great questions, but I don't think I've ever seen a site that rolls its own dialogs get these details right either, so fixing these cases is unlikely to break any early adopters of <dialog>.

Agreed. I figure the new focusing stuff will improve <dialog> but doesn't have to block it particularly since it will mainly impact cases like dialogs with no focusable elements or nested modals. These cases are pretty usable now, and expanding HTML's notion of focus to handle window-focus as proposed should improve usability without majorly breaking users of <dialog>.

[Jonathan Dixon]

Freeriding on this discussion , will a native dialog element allow scope for the mobile experience to be optimised? Many BYO solutions, including the polyfill on the demo site, have problems like:

- can't dismiss modal dialog by tapping outside it

- very easy to "loose" the dialog on a large page as it scrolls with the content. especially if zoomed right in you often have to search around for the close button. (Primarily an issue when viewing desktop site on small screen)

Having modal dialog stick to the viewport (and be sized within the width of it) would help a lot.

Hopefully these are just  implementation issues but wanted to check this would be compatible with the spec?

[Matt Falkenhagen]

Yep, the spec provides room for helping here.

On Mon, Dec 16, 2013 at 3:12 AM, Jonathan Dixon <jo...@chromium.org> wrote:

Freeriding on this discussion , will a native dialog element allow scope for the mobile experience to be optimised? Many BYO solutions, including the polyfill on the demo site, have problems like:

- can't dismiss modal dialog by tapping outside it

By default, tapping outside doesn't close the dialog. The spec says browsers can provide UI to close it, like hitting the Escape key (which is implemented). On mobile, we probably can use the Back button to do so.

Authors can also listen to events on the <dialog> (typically tapping outside will mean tapping on the dialog's backdrop, which means an event is fired on the <dialog>) or the document to close the dialog.

- very easy to "loose" the dialog on a large page as it scrolls with the content. especially if zoomed right in you often have to search around for the close button. (Primarily an issue when viewing desktop site on small screen)

Having modal dialog stick to the viewport (and be sized within the width of it) would help a lot.

By design, modal dialogs scroll with content by default, but authors can use position:fixed and whatever other CSS they want. There's currently no special handling for mobile viewport for <dialog> elements specifically.

[Ian Hickson]

On Mon, 16 Dec 2013, Matt Falkenhagen wrote:
>
> By default, tapping outside doesn't close the dialog. The spec says
> browsers can provide UI to close it, like hitting the Escape key (which
> is implemented). On mobile, we probably can use the Back button to do
> so.

We can also make tapping outside trigger the dialog the cancel path.
(That's a UI!)

> By design, modal dialogs scroll with content by default, but authors can
> use position:fixed and whatever other CSS they want. There's currently
> no special handling for mobile viewport for <dialog> elements
> specifically.

Yeah. The scrolling behaviour around <dialog> is the topic of this which I
haven't responded to yet:

http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Nov/0011.html

I recommed replying to that e-mail descrbing the model you'd like specced.
I'm not currently sure what I'll end up doing.

[Eric Seidel]

This intent is still open.  Has there been an update on the "focus stuff" so that we can make a final decision for shipping?  It sounds like folks are very much in favor of the feature, but a spec editor saying that the spec isn't ready is obviously concerning. :)

[Elliott Sprehn]

On Tue, Jan 7, 2014 at 9:59 AM, Eric Seidel <ese...@chromium.org> wrote:

This intent is still open.  Has there been an update on the "focus stuff" so that we can make a final decision for shipping?  It sounds like folks are very much in favor of the feature, but a spec editor saying that the spec isn't ready is obviously concerning. :)

I've been working in the render tree construction code recently and I have to say I'm not a fan of the magical absolute position that the HTML spec has added either. It violates the principles that Dimitri has posted recently and means we end up with an if(dialog) doSomethingSpecial() inside render tree construction and also inside RenderView::layout().

ex. https://codereview.chromium.org/118333005/

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/rendering/RenderView.cpp&l=173

Older versions of our implementation used to just set top/left which was at least explainable and allowed implementing <dialog> as a custom element. Hixie@ pushed us to implement a version that cannot be explained in web primitives which I think was a mistake. The current version of the spec cannot be implemented in terms of JS, even with a top layer primitive, because it needs to hook the render tree construction to make the ICB it's containing block.

The current code isn't right either:

https://code.google.com/p/chromium/issues/detail?id=332133

I think we should push back on the <dialog> spec to not introduce more magical behavior that cannot be explained in terms of our existing CSS primitives and JS (plus a top layer primitive since that explains both dialog and full screen).

[Ian Hickson]

On Tue, 7 Jan 2014, Eric Seidel wrote:
>
> This intent is still open. Has there been an update on the "focus
> stuff" so that we can make a final decision for shipping? It sounds
> like folks are very much in favor of the feature, but a spec editor
> saying that the spec isn't ready is obviously concerning. :)

Implementing is fine. I just said that we should be sure to update it as
the spec is updated. Sorry for any ambiguity.

[Ian Hickson]

On Tue, 7 Jan 2014, Elliott Sprehn wrote:
>
> I think we should push back on the <dialog> spec to not introduce more
> magical behavior that cannot be explained in terms of our existing CSS
> primitives and JS (plus a top layer primitive since that explains both
> dialog and full screen).

We can always add a primitive for this behaviour, but it's not clear that
it would have any other use cases.

[Elliott Sprehn]

On Tue, Jan 7, 2014 at 11:28 AM, Ian Hickson <i...@hixie.ch> wrote:

On Tue, 7 Jan 2014, Elliott Sprehn wrote:
>
> I think we should push back on the <dialog> spec to not introduce more
> magical behavior that cannot be explained in terms of our existing CSS
> primitives and JS (plus a top layer primitive since that explains both
> dialog and full screen).

We can always add a primitive for this behaviour, but it's not clear that
it would have any other use cases.

I don't think we should be adding more primitives if there's only one user either. <dialog> should be explainable in terms of the CSS primitives we already have plus top layer.

We should go back to setting top/left and get rid of this special if (dialog and position absolute) case.

- E 

[Ian Hickson]

The behaviour <dialog> needs isn't describable in terms of CSS today. So
either we need new primitives, or we need new dedicated features. Right
now, we have a mixture of both; several of which are shared with the full
screen API, which has similar problems. For example, the "top layer" isn't
a primitive you can invoke directly, but it is used by <dialog> and full
screen. ::backdrop is only created for these two, but that one is one you
can reference. The default static position logic for <dialog>'s internal
'position: absolute-anchored' is similar to the default static position
logic for the CSS-standard 'position: absolute', but like the static
position in 'position: absolute', it's not something you can directly
manipulate. The anchoring itself is something for which the HTML spec
_does_ give a primitive, the 'anchor-point' property; however, it's not
useful except in conjunction with <dialog> right now (though I wouldn't
object to a primitive to make use of this elsewhere). The inertness
mechanism has a primitive (inert=""), but it doesn't quite work the way
that <dialog> does it, because the use cases differ. The pending dialog
stack isn't something you can directly interact with. The focusing logic
is something for which we're developing primitives, though, since that
makes sense to interact with from script. Etc.

It's not entirely clear to me which part of this you're objecting to, or
what you think it should be replaced with. But I don't think we should shy
away from dedicated features where it makes sense. If it was possible to
design a dialog box entirely from JS without any new logic, then we really
wouldn't need to do any of this. The reason HTML has a <dialog> element is
that this is a problem for which primitives don't exist, and for which all
the relevant primitives really shouldn't exist since they're only useful
in this one case. It _is_ the primitive.

[Nat Duca]

Just a drive-by commet: some of us working on graphics use cases [popup menus inside divs, http://jsfiddle.net/6rUyf/] have had a nagging feeling that stacking-context based specification of z-ordering is itself broken. In that space, the stacking contexts plus translate-forces-stacking context causes a strong coupling between how you arrange your DOM and what the final drawing order is.

It would be really nice if we discovered a core primitive that preserved the modularity ideas of stacking context, but allowed popups, overlays and dialogs to be attached to their logical DOM owner, instead of having to be reparented to the body to workaround stacking/etc.

[Matt Falkenhagen]

On Wed, Jan 8, 2014 at 3:52 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Jan 7, 2014 at 9:59 AM, Eric Seidel <ese...@chromium.org> wrote:

This intent is still open.  Has there been an update on the "focus stuff" so that we can make a final decision for shipping?  It sounds like folks are very much in favor of the feature, but a spec editor saying that the spec isn't ready is obviously concerning. :)

I've been working in the render tree construction code recently and I have to say I'm not a fan of the magical absolute position that the HTML spec has added either. It violates the principles that Dimitri has posted recently and means we end up with an if(dialog) doSomethingSpecial() inside render tree construction and also inside RenderView::layout().

ex. https://codereview.chromium.org/118333005/

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/rendering/RenderView.cpp&l=173

Older versions of our implementation used to just set top/left which was at least explainable and allowed implementing <dialog> as a custom element. Hixie@ pushed us to implement a version that cannot be explained in web primitives which I think was a mistake. The current version of the spec cannot be implemented in terms of JS, even with a top layer primitive, because it needs to hook the render tree construction to make the ICB it's containing block.

To be fair, the current implementation and spec is the outcome of lots of discussion and iteration with layout experts (including you, of course) as well as on spec bugs.  It's not just that "Hixie pushed us" :)

I don't think it's fair to say <dialog> is not explainable in CSS/JS. It is: the containing block of an abspos dialog is the ICB, and show/showModal causes its static position to be set up such that it's centered.

There were pros and cons to the top/left without reparenting implementation. We wanted dialog to bust out of its containing block, not just for positioning, but also so it's not affected by DOM ancestors for things like percent lengths and overflow. Having dialog's containing block be ICB accomplished that in a fairly clean way.

The layering principles are good to keep in mind, but I'm not sure it's desirable or realistic to adopt a hard criteria that elements be implementable in JS. Even the top/left implementation isn't purely implementable in JS; we mutate the computed value not the specified value.

[TAMURA, Kent]

This thread has some comments about the specification. So it seems the specification isn't mature yet.  We should not ship <dialog> yet.

--
TAMURA Kent
Software Engineer, Google

[yio...@gmail.com]

http://aui.github.io/artDialog/doc/index.html
在 2013年12月13日星期五UTC+8下午5时08分00秒，Matt Falkenhagen写道：

[Ian Hickson]

On Tue Jan 07 2014 at 11:37:54, Ian Hickson <i...@hixie.ch> wrote:

On Tue, 7 Jan 2014, Eric Seidel wrote:
>
> This intent is still open.  Has there been an update on the "focus
> stuff" so that we can make a final decision for shipping?  It sounds
> like folks are very much in favor of the feature, but a spec editor
> saying that the spec isn't ready is obviously concerning. :)

Implementing is fine. I just said that we should be sure to update it as
the spec is updated. Sorry for any ambiguity.

I was asked off-list to clarify the spec status here.

For the record, what I wrote above still applies: implementing is fine, just make sure to track any updates to the spec. This is the same status as everything else in the HTML spec, whether it's something that was first specced out in 1994 or something that was first thought of yesterday.

Specifically with regard to <dialog>, there are two outstanding issues that I know of. One is that it doesn't support vertical text; this bug is blocked on CSS vertical text being more widely implemented. The other is with regard to focus; I'm adding a few new APIs to handle dialogs containing focusable elements, and being focused themselves. The spec will require what is proposed here, since I haven't gotten any negative feedback:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475#c16

I'm actually integrating that into the spec as we speak. This affects <dialog>, but it also affects <map> and <area> and <img> and <input> and viewports and Documents, so unless we're also removing our implementation of images and Documents and viewports, it shouldn't affect work on <dialog> either.

-- 

Ian Hickson

[Elliott Sprehn]

Sorry I haven't gotten around to replying, but I don't think we should implement this API. That's way too much API surface just for dialog focusing. For example dialog.parentDialog can be implemented by just walking up the DOM, and all this dialog focus logic on document doesn't make sense to me either. <dialog> doesn't need to be some huge magical thing. I think we need to be aiming for something simpler.

In particular Android's dialog system is self contained, the ViewManager doesn't have special focusing logic or any of this.

[Ian Hickson]

On Fri, 14 Feb 2014, Elliott Sprehn wrote:
>
> Sorry I haven't gotten around to replying, but I don't think we should
> implement this API. That's way too much API surface just for dialog
> focusing. For example dialog.parentDialog can be implemented by just
> walking up the DOM, and all this dialog focus logic on document doesn't
> make sense to me either. <dialog> doesn't need to be some huge magical
> thing. I think we need to be aiming for something simpler.

The API isn't really the interesting part of this. Dropping it is fine;
the only reason for including it is that without it the existing API is
kinda confusing (since it doesn't know about dialogs, and so it can't
really give a clear answer to anything). The proposed new API attributes
just provide a way to walk up the focus hierarchy and walk down the
hiearchy to find out what's focused. (It's just four attributes: one to
find the child focused dialog, one to find the dialog's parent, one to
find the child focused control, and one to find the control's parent.)

> In particular Android's dialog system is self contained, the ViewManager
> doesn't have special focusing logic or any of this.

Not sure what you mean here. Android certainly has support for multiple
modal dialogs, and you can't tab from controls in one to controls in the
next. Dialog has plenty of methods, too, it's not like it's a trivial API.

In fact, in comparison, the proposed Web API for dialogs is really simple.
There's a few methods for different ways to show the dialog, one to close
it, one to focus and one to blur, one to find out what's focused inside
the dialog, and one to find out which dialog the dialog is in.

It's true that parentDialog specifically doesn't appear to be on the
Android API; I would guess Android doesn't support MDI-style nested
dialogs. On the Web we more or less already support this anyway due to
nested <iframe>s; even if we banned nested <dialog>s at the per-page
level, we couldn't sanely prevent them via nested <iframe>s, so there's
not much point IMHO banning them at a per-page level (it doesn't prevent
authors from doing anything, it just makes it more complicated for them).

Not including parentDialog explicitly wouldn't remove any functionality;
as you point out, you can just walk up the tree and manually check each
element to see if it's an owner dialog. This is just a convenience API.
But I think that misses the overall picture. Removing this particular
attribute doesn't meaningfully change the complexity of the proposal. The
bulk of the proposal's complexity is actually about defining the legacy
Web focus model, which we'd never properly done before.

[Elliott Sprehn]

Given that we've removed the magic absolute positioning and containing block code, and haven't added any of the new focus stuff yet, I think we should move forward with shipping <dialog>.

The existing <dialog> + show() + showModal() model seems fine and something we can extend in the future. It has some things missing, but the existing API is enough for most developers and seems like a good improvement to the platform.

[rosa maria palacios juncosa]

[Dominic Mazzoni]

With the magic absolute positioning gone, where does a dialog show up if the author does nothing? Is it still in a "magic" z-index above everything else?

What's the status of the spec, are there proposals to fix the magic absolute positioning requirements?

What would happen if another browser implemented the full spec, including the absolute positioning? How much of a compatibility risk would it be if a developer started using <dialog> and did their own positioning using css, but then ran that code in a browser that does the magic positioning?

- Dominic

[Anne van Kesteren]

On Fri, May 30, 2014 at 7:19 PM, Dominic Mazzoni <dmaz...@chromium.org> wrote:
> With the magic absolute positioning gone, where does a dialog show up if the
> author does nothing? Is it still in a "magic" z-index above everything else?

It's defined in terms of fullscreen, so it's no less "magic" than
that: http://fullscreen.spec.whatwg.org/#new-stacking-layer


--
http://annevankesteren.nl/

[Ojan Vafai]

It sounds like we've addressed the concerns expressed about this API. We should restart this intent to ship so we can get this code out from behind the flag.

LGTM to ship.

[Jochen Eisinger]

My lgtm still stands

[Darin Fisher]

LGTM

[TAMURA, Kent]

LGTM4