[dialog element] <dialog> positioning should be describable in CSS

[smfr]

HTML describes the "centered alignment" of a dialog element in somewhat opaque prose.

Blink's implementation of this is a hack in their rendering code

This needs to be described in terms of CSS (ideally as some rules in the UA stylesheet). Apparently it's not implementable in CSS, which is a problem. First, UAs should not have to add custom layout code for the dialog element, and second authors should be able to achieve the same positioning behavior for their own elements.

[annevk]

There's also <center> and <div align>, which use https://html.spec.whatwg.org/multipage/rendering.html#align-descendants apparently. Seems weird indeed that HTML has so many non-CSS centering mechanisms.

[tabatkins]

<center> and [align] should both be describable via justify-items: legacy center; (/legacy right or legacy left); that's what we designed those values for. It does depend on browsers implementing justify-self on display: block, which hasn't happened yet. We'd be very interested to know if there are quirks we aren't handling there.

As for <dialog>, if I'm reading it correctly it means:

• at the time the dialog is first rendered, lay it out as an abspos non-replaced element.
• if the height is less than the height of the viewport, center it in the viewport, adjusting 'top'/'bottom' appropriately to achieve this. (Note: abspos positioning, not fixpos positioning! Scrolling the viewport should allow the dialgo to scroll off the screen!)
• if it's taller than the viewport, adjust 'top'/'bottom' to align it with the block-start edge of the viewport.
• if the size of the viewport changes, redo the layout+centering
• if the dialog stops being rendered, then starts again (display:none then non-none, for example), redo the layout+centering

I think that's it?

So the centering behavior, first, is a basic align-self: safe center; into the alignment container.

The missing piece is just setting up the alignment container, as neither abspos nor fixpos give the desired rectangle. This instead requires a stateful rendering-sensitive "snapshot" of the current viewport position relative to the rest of the document. The timing issue already exists for things like animations, which start their timeline when an element first generates a box, so we can lean on that concept.

I forget - I think dialog is supposed to display in the top layer, too? Is that a necessary thing to capture here?

[smfr]

Top layer rendering is clearly speced, so this is just about positioning.

[annevk]

(Though note https://fullscreen.spec.whatwg.org/#rendering. Moving that to CSS would be appreciated as well.)

[css-meeting-bot]

The CSS Working Group just discussed <dialog> positioning, and agreed to the following:

• RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description
• RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering

The full IRC log of that discussion

<TabAtkins> Topic: <dialog> positioning
<astearns> github: https://github.com//issues/4645
<TabAtkins> github: https://github.com//issues/4645
<fantasai> ScribeNick: fantasai
<fantasai> TabAtkins: Dialog layout description, two modes
<fantasai> TabAtkins: 2nd one is a very long run-on sentence that's weird and not described in CSS
<fantasai> TabAtkins: Behavior is useful, but unfortunate not in CSS
<fantasai> TabAtkins: So a few things to do
<fantasai> TabAtkins: First question, is this worth trying to put into CSS?
<fantasai> TabAtkins: Next, quick description of what it is and what might be involved, to get an idea of how it would work
<AmeliaBR> Define in CSS please!
<fantasai> TabAtkins: Thoughts on whether to describe in CSS, or treat as a special one-off case in HTML
<fantasai> florian: In general, think it's better to do in CSS
<fantasai> florian: but if extremely complicated * low value, maybe not
<fantasai> smfr: Authors might want to use the same type of positioning for their own fake dialogs
<fantasai> smfr: so better to have in CSS
<AmeliaBR> Defining in CSS also makes it easier to modify / override with CSS (e.g., by media queries, interactions with other CSS).
<fantasai> TabAtkins: Aim to get a resolution to add this to CSS, does anyone object to me putting this into some spec, probably css-position?
<fantasai> TabAtkins: I'm taking the silence as assent
<fantasai> tantek: Any security considerations wrt lowering barriers to making fake dialogs?
<fantasai> TabAtkins: Can do in JS already
<fantasai> TabAtkins: So can we take a resolution to that?
<fantasai> RESOLVED: Define dialog positioning in CSS terms, probably in css-position, with aim of replacing HTML's one-off description
<fantasai> fantasai: ...
<fantasai> TabAtkins: ...
<fantasai> emilio: It's a stateful position, because you don't want to reposition the dialog when you scroll or relayout
<fantasai> TabAtkins: here's the basic description
<fantasai> TabAtkins: Ignoring stacking context aspect
<fantasai> TabAtkins: but for positioning bit
<fantasai> TabAtkins: It's basically abspos
<fantasai> TabAtkins: where we figure out the offset to apply when it first comes into existence
<fantasai> TabAtkins: such that it's safe-centered into viewport
<fantasai> TabAtkins: from that point on, it's just abspos -- you scroll the page, it scrolls off
<fantasai> TabAtkins: if you dismiss the dialog and regenerate, it will recalculate its position
<fantasai> TabAtkins: interesting question is when do we clock thispoint in time?
<fantasai> TabAtkins: Answer should be when animation starts
<fantasai> iank_: Another way to define is in the DOM layer
<fantasai> iank_: for the DIALOG element it could query what the layout is and set the top directly via CSS
<fantasai> TabAtkins: Essentially built-in JS
<fantasai> iank_: We do this for other things
<tantek> is it not fixedpos? huh
<fantasai> iank_: It's not great, but might be impler
<TabAtkins> nope, it scrolls if you scrol lthe page
<fantasai> s/imp/simp/
<fantasai> emilio: My objection wrt when boxes are created is that engines create boxes at different times
<fantasai> emilio: When you change the display value, Blink will reposition, because it destroys the box and loses the state
<fantasai> TabAtkins: If you go from not having boxes to having boxes, you reposition. Having boxes to having boxes, you don't reposition
<fantasai> TabAtkins: Ian's description was also quite good, smfr what do you think?
<heycam> fantasai: to describe Ian's suggestion, at the point the dialog is launched, the UA sets the top/bottom/left/right to be an absolute position edges of the viewport
<heycam> ... and then, we use the alignment properties to center it within that area
<heycam> ... then you don't have to calculate the centering
<heycam> ... just use the inset properties to bring the abspos range to match the current viewport range when the dialog is launched
<heycam> smfr: sounds like you're snapshotting the layout viewport
<heycam> fantasai: you're assigning abspos inset properties so that you're creating a box that overlaps exactly the fixedpos containing block
<heycam> smfr: wondering if it should be defined in terms of the layout viewport somehow
<heycam> TabAtkins: the HTML spec does require recalculating the position if the viewport changes size
<heycam> ... guess that's still possible, it's just a ResizeObserver on the window
<heycam> smfr: another question is if the user zooms. same behavior as fixpos?
<heycam> fantasai: as abspos, if the user wants to zoom in to see the dialog they should be able to
<heycam> TabAtkins: don't want fixpos magic. abspos with magic setting at a particular time
<heycam> fantasai: I think that this works and is simpler than creating a new magic model with timing implications
<heycam> fantasai: question I have is, if you have a dialog that's inside one of these containing block trapping elements, how do you get this element to escape and become contained byt the containing block
<heycam> TabAtkins: that's answered by top-layer
<heycam> ... in this mode it's always kicked into that
<heycam> ... do need to specify top layer rendering
<heycam> fantasai: putting something there changes stacking context and containing block?
<heycam> TabAtkins: yes
<heycam> ... abspos containing block becomes the root
<heycam> fantasai: how does that interact with transforms or contain layout?
<heycam> TabAtkins: layout containgment should still be fine with escaping
<heycam> ... and transforms it changes its parent
<heycam> ... it's no longer transformed
<heycam> iank_: yes. it's weird
<heycam> fantasai: so it sounds like what we're doing is defining a way to put something into the top layer, out of the box tree, into this parallel box tree (list) where the containing block is the size of the entire page
<heycam> TabAtkins: I think that's the right thing
<heycam> TabAtkins: think it's the whole page
<heycam> heycam: interactions with full screen? they'll both be in the top layer
<heycam> TabAtkins: we'll need to deal with that
<heycam> ... separate but intersecting topics
<heycam> smfr: top layers will stack up
<heycam> ... if you have full screen and dialog
<heycam> fantasai: what's the stacking order?
<heycam> smfr: whichever's created first
<heycam> ... but we need to define that
<heycam> fantasai: it's not as much of a mess as fieldset/legend...
<heycam> iank_: painting wise this is more interesting
<heycam> smfr: part of me wonders if we need to maintain compat with dialog layout. is this sensible behavior in HTML? or should we define something different
<heycam> ... think only Chrome has shipped
<heycam> TabAtkins: I've used dialogs in personal projects and enjoyed it
<heycam> iank_: are we the only ones shipping it?
<heycam> TabAtkins: I think so
<heycam> iank_: I would be up for potentially investigating what compat risk there is if there's a more sane model that we think we can ship
<heycam> ... the compat thing will be the question
<heycam> ... Simon what caused you to start investigating this?
<heycam> smfr: I was just looking at how the implementation would work in WebKit
<heycam> ... and I dug into the Blink code and found a function deep down
<fantasai> i/fantasai: to describe Ian/scribenick: heycam
<heycam> ... in block rendering
<heycam> ... didn't want to do the same thing
<smfr> s/in block rendering/in block layout/
<heycam> RESOLVED: Define dialog in terms of top layer and a snapshotted abspos position and alignment property for centering
<heycam> smfr: can we also resolve on specifying top layer behavior in CSS somewhere?
<heycam> ... it needs to live along with paint order and z-index
<heycam> ... wherever CSS 2.2 Appendix E will go
<heycam> fantasai: probably CSS Position?
<heycam> smfr: or a new spec
<heycam> smfr: I feel like a paint order spec is probably necessary
<heycam> dbaron: I think we need a spec for a bunch of rendering stuff, including common terminology
<heycam> ... if you remember the big table of horrible test cases for stacking contexts, etc., we need a spec to cover that
<heycam> fantasai: so new spec for the painting order
<tantek_> perhaps that could include hit-testing which is directly related to stacking order etc.
<heycam> dbaron: CSS Rendering Model or CSS Painting Model?
<tantek_> more than just painting, the stacking order affects hit-testing
<fantasai> scribenick: fantasai

[keithjgrant]

I would love to be able to transition/animate these in and out, too, though that may be a separate problem altogether

[fantasai]

Details on the proposal:

• The dialog is assigned to the "top layer" (which probably should be defined in css-position-3 once it's rewritten).
• DOM snapshots the top/bottom of the viewport as inset property values when the dialog is opened, and rewrites those values if the viewport is resized.
• The dialog is also assigned align-self: safe center; this takes care of the centering within the viewport.

I think the one question I can think of wrt CSS interaction is where the inset values are injected, if it's at the preshint level or into the style attribute or something else. Depends on what's reasonably implementable and what's reasonably Web-compatible...

@keithjgrant Together with selecting on [open], I think this should allow for animations and transitions of most aspects of dialog layout.

@annevk Does that make sense, or do you need more info for the HTML spec parts of this?

[annevk]

That sounds like an okay plan. I'm not sure I understand "Closed Accepted by CSSWG Resolution" as there still seems to be quite a bit of work outstanding.

@tabatkins for <center> and align="", is there some issue to track on that?

[keithjgrant]

Together with selecting on [open], I think this should allow for animations and transitions of most aspects of dialog layout.

When browsers first added support, this allowed for animating in, but not animating out. Once the dialog closed, it was immediately removed from view by the browser and no CSS I tried was capable of altering this behavior...

This still seems to be the case in Chrome, though Firefox has improved things a little. In Firefox, display: block can be used to show a "closed" dialog (so e.g. a fade-out animation can be applied on close). Firefox positions the dialog with an inline top and z-index, which are only present while open, so these would have to be manually re-calculated to match after the close attribute is removed. In any case, it seems browsers are taking a kind of "whatever works" approach to how these are styled & stacked in a top rendering layer — getting those clearly defined will be a win.

[SebastianZ]

This still seems to be the case in Chrome, though Firefox has improved things a little.

It has to be said that Mozilla has not shipped its implementation yet.

In Firefox, display: block can be used to show a "closed" dialog (so e.g. a fade-out animation can be applied on close). Firefox positions the dialog with an inline top and z-index, which are only present while open, so these would have to be manually re-calculated to match after the close attribute is removed.

As far as I can see, top and z-index are not set inline, at least on Windows 10, though here are the styles that are currently used for the element:

Sebastian

[keithjgrant]

Oh right. I forgot I'm on FF Nightly here

[fantasai]

@annevk That mapping is covered by whatwg/html#3428

Afaict, this issue is basically solved on the CSS side, except insofar as the "top layer" is still defined in Fullscreen rather than in a CSS spec. If that should be moved over, it deserves its own issue since it's not about DIALOG specifically...

I'll copy over the conclusions from this issue into the WHATWG issue.

[fantasai]

Filed the "define Fullscreen rendering in CSS" issue in #4998

[emilio]

@fantasai @annevk what about having two attributes on the dialog that map to these properties? That would reuse the general attribute-mapping mechanism which seems sane to me.

[emilio]

(This is about the viewport insets, of course).

Context: Gecko is looking at implementing dialog positioning, and having a layout engine hack seems really sad.

[emilio]

We could potentially also do it without magic attributes and just storing the offsets in the HTMLDialogElement instance itself, I guess, then injecting the rules in the cascade at the pres hints level, but I'm not sure if there's a precedent for such a thing.

[annevk]

So to be clear, the problem here is

DOM snapshots the top/bottom of the viewport as inset property values when the dialog is opened, and rewrites those values if the viewport is resized.

right? It wasn't entirely clear to me how we would implement that specification-wise. Are new values that act like that another possibility we could consider? If this is a useful primitive, I'm not sure why CSS shouldn't offer it natively.

(Using content attributes for styling seems to go against separation of markup and style, but I might be misunderstanding something. Your final solution would work, but would still make HTML own some layout logic it probably shouldn't.)

[css-meeting-bot]

The CSS Working Group just discussed [dialog element] <dialog> positioning should be describable in CSS, and agreed to the following:

• RESOLVED: We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data

The full IRC log of that discussion

<dael> Topic: [dialog element] <dialog> positioning should be describable in CSS
<dael> github: ttps://github.com//issues/4645
<dael> github: https://github.com//issues/4645
<dael> emilio: Started looking into dialog and whole positioning for abspos dialog is weird. Have to snapshot scroll psoition at time you open.
<dael> emilio: I think it's not common since most dialogs I know are fixedpos and height of screen at most
<dael> emilio: Some discussion in the past. I wonder what is model people feel we should have. fantasai prop snapshot scroll position in dom and apply that
<dael> emilio: I think I would like simplier and make dialogs fixedpos, scrollable with max-height is the screen height. Only Chrome ships dialog so I'd like to know their feelings
<dael> TabAtkins: Played a bit. Does ability to anchor a dialog to a mouse event exist or is it limited to dialog center on screen
<fantasai> issue was about describing the behavior specced in HTML, didn't look into making fundamental changes to it :)
<dael> emilio: I don't think we can attach to an element
<dael> TabAtkins: If we ever do want to attach to an element some mech is the thing being used to position non-anchor dialogs. If we switch non-anchor to fixedpos we have to figure out how to do it for non-anchored.
<dael> iank_: I think a different solution for anchoring down the road
<dael> iank_: I tried to work out where this originally came from. It was something like 8 years ago. Only concern I have is webcompat. Given we're only shipping it might be fine. Want to add use counters to see what sites are triggering. Otherwise changing to fixed height and overflow auto sounds fine
<dael> emilio: Other weird thing is reposition dialog when viewport resizes. That just feels weird.
<dael> iank_: Dialog should always be centered given abspos constraint
<dael> emilio: Agree. Whole snapshot is redone when viewport is resized
<dael> iank_: Sure. DOn't disagree this is crazy behavior
<dael> iank_: I'll add a blink use counter to determine when we're snapshotting a non-0 scroll position. That should cover it and give us insight in web compat
<dael> TabAtkins: Okay resolve pending data showing we can't this is the way to go?
<dael> iank_: fine
<dael> TabAtkins: Prop: We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data
<dael> smfr: Only for mobile and therefore in top layer?
<dael> TabAtkins: Yeah
<dael> smfr: Don't have to worry about transforms b/c not in top layer?
<TabAtkins> s/mobile/modal/
<dael> TabAtkins: Yeah
<dael> chrishtr: Does thia mount to styling same as fulls creen element?
<dael> TabAtkins: Yeah
<dael> chrishtr: It would just allow a margin?
<dael> iank_: top left at 0 but margins are auto which centers
<dael> chrishtr: Only difference it margins, sounds good to me. Recently reviewed full screen so this is not a problem
<dael> hober: Seems good if they converge since intended to use same underlying
<dael> astearns: Do we need to be explicit about connection?
<dael> hober: Are since use notion of top layer. A lot of refactor on full screen spec that could move some of this to other specs
<dael> chrishtr: Is dialog in a css spec?
<dael> TabAtkins: Just in ?? right now
<dael> chrishtr: Can we define where we'd put it when work is done?
<dael> TabAtkins: I think it's still fine for special styling rules to live in html spec. Only if we're adding new functionality should it be in css.
<dael> chrishtr: THe rendering monkeypatches need to be moved
<AmeliaBR> s/??/HTML/
<dael> tab: We're planning to kill those
<dael> AmeliaBR: One new magic thing is idea of top layer. Is that desc?
<dael> TabAtkins: Have an open issue for it in positioning spec
<dael> AmeliaBR: Needs to be defined and than html can define dialog as rendered in top layer with these properties. Than we solve dialog being desc by css tems in the html spec
<dael> chrishtr: Sounds right and same for full screen
<dael> florian: And if there is not css terms to desc we should create it rather than have it be magic
<dael> fantasai: Desc top layer is a sep open issue
<dael> astearns: Any magic aside from top layer?
<dael> TabAtkins: Assuming we use prop from earlier no. It's just a fixedpos container
<dael> chrishtr: top layer is in a special place b/c it's above scrollbars
<dael> TabAtkins: Yes. As fantasai said describing the top layer is a sep issue
<dael> astearns: Have open issue for top layer, we will define that. For this issue we're going to resolve that We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data
<dael> astearns: Any objections?
<dael> RESOLVED: We switch dialog positioning to rely on centered fixed container with max-height and overflow:auto pending use counter data
<dael> astearns: Good to get to top layer definition soon so we can remove the magic.

[gregwhitworth]

TabAtkins: If we ever do want to attach to an element some mech is the thing being used to position non-anchor dialogs. If we switch non-anchor to fixedpos we have to figure out how to do it for non-anchored.

iank_: I think a different solution for anchoring down the road

I think we should open a separate issue for this because authors do want this capability outside of the specific <dialog> need (eg: tooltips, dropdown menus, etc). So this should be thought about sooner rather than later. In the research that @annevk shared there are many examples that are not centered and are anchored to an element. While I get the implementation concerns I'm also curious of making the dialog itself the scroller via overflow behavior is the right way. Most of the scenarios that come to mind however normally don't fit in what seems to be the primary definition (based on what is shipping) as a <dialogue>.

cc: @melanierichards

[bfgeek]

Agenda+ for whatwg/html#5936 (comment)

[fantasai]

@bfgeek I think this deserves its own issue? Also are there other use cases for :modal or is it just for flipping the DIALOG element between position: absolute/fixed in the UA default style sheet?

[LeaVerou]

Regarding :modal, it seems to me that modal should really be an attribute, just like open. Then, not only would that state be targetable with normal attribute selectors, but with the added benefit of being able to create modals with HTML. It always puzzled me why there is an open attribute, but not a modal attribute.

[gregwhitworth]

+1 to what @LeaVerou - ironically we had this discussion in March of 2019 and likewise wanted an attribute

https://twitter.com/LeaVerou/status/1102862914749452289

[css-meeting-bot]

The CSS Working Group just discussed Dialog element, and agreed to the following:

• RESOLVED: Add a hidden pseudo-class for this purpose, in order to solve styling issue while leavine open the possibility of HTML improving its API

The full IRC log of that discussion

<florian> topic: Dialog element
<fantasai> github: https://github.com//issues/4645
<florian> TabAtkins: there's a discussion in HTML about fixing the dialog element to use CSS instead of being a hack
<florian> TabAtkins: they realized that there's a big difference between
<florian> TabAtkins: when it's opened normaly vs as a moal
<florian> s/moal/modal/
<florian> TabAtkins: it's based purely on which js method you use to open it
<florian> TabAtkins: so we need some way to distinguish, and a pseudo class seems most natural
<leaverou> q+
<florian> TabAtkins: the proposal is :modal
<astearns> ack leaverou
<florian> TabAtkins: seems good to me, but we need to make sure we don't want to use it for something else
<florian> leaverou: feels like defining a pseudo class to work around a problem with the API
<florian> leaverou: seems to me that there should be a modal attribute
<florian> leaverou: don't see why we need to fix it in css
<fantasai> +1
<emilio> q+
<miriam> +1
<brandon> +1
<florian> leaverou: seems weird that you need to use JS, and cannot do it in markup
<astearns> ack emilio
<leaverou> s/seems weird that you need to use JS, and cannot do it in markup/seems weird that you need to use JS, and cannot do it in markup, when you can already use the `open` attribute to open it in a non-modal way/
<florian> emilio: toggling the attribute is not the same as calling dialog.open
<florian> emilio: it's bad, but that's the way it is
<emilio> https://github.com/whatwg/html/issues/5802
<florian> iank_: it is a strange API, don't want to add more attributes to it
<smfr> q+
<leaverou> if the API is messy, maybe it needs more work before we add things to CSS for it?
<florian> gregwhitworth: if this is so bad, and is so confusing, why are we ducktaping this?
<florian> iank_: many sites use it, so there's a big compat risk
<florian> iank_: we aren't happy with how the modal works today, and we're willing to change
<florian> iank_: ... to make it describable in css
<florian> iank_: if we were doing it from scratch today, we'd do it differently
<florian> SimonSapin: modal go in a magic layer of over the page
<smfr> s/SimonSapin/smfr/
<florian> smfr: ...
<florian> iank_: ......
<gregwhitworth> smfr: I would like to define the top layer to be used by other elements, it could be used here
<fantasai> scribenick: fantasai
<fantasai> smfr: I suggest to use UA stylesheet rules to also describe the top-layer behavior of the modal dialog
<fantasai> iank_: Broadly speaking, this is what the HTML pull request does today. It adds one new pseudo-class, :modal, and removes all of the special-case rendering logic
<fantasai> iank_: and replaces it basically with one additional UA stylesheet rule
<fantasai> iank_: What gives me confidence in this approach is that this is what Gecko does today, using an internal pseudo-class
<fantasai> iank_: One thing it doesn't describe, broader issue, is how does the "top layer" work.
<fantasai> iank_: Tab has previously wanted to explain how that works somewhere else
<bkardell_> q+
<smfr> q-
<fantasai> iank_: This fixes all the special-casing text that was there previously, except fixing top-layer
<fantasai> iank_: Moves us significantly closer
<astearns> ack bkardell_
<fantasai> bkardell_: There are a few proposals going back to 2014/15 or so
<fantasai> bkardell_: to explain top layer
<fantasai> bkardell_: not in CSS
<fantasai> bkardell_: but there's prior attempts that exist that are worth looking at
<TabAtkins> fantasai: Going back to Lea's point, why isn't this an attribute on the element?
<TabAtkins> fantasai: We could do all this in the UA stylesheet keyed off an attribute, wouldn't that be more consistent?
<TabAtkins> fantasai: Maybe removing/adding modal doesn't do anything because it's really the show()/hide() methods and how they sync with [open] that's important...
<fantasai> iank_: the open attribute is very special and strange
<fantasai> iank_: wouldn't want to add anything like that
<fantasai> emilio: adding/removing the open attribute doesn't fire the relevant events
<fantasai> emilio: dialog element is expected to be used via JS APIs
<gregwhitworth> iank_: emilio and it wouldn't be web compatible to add those linkages?
<fantasai> emilio: already weird that it has this reflection already
<fantasai> gregwhitworth, if you're talking to someone, use a comma
<fantasai> gregwhitworth, that looks like you're correcting the minutes
<fantasai> emilio: ...
<fantasai> astearns: Her proposal is to add a new modal attribute, not to re-use open
<fantasai> leaverou: can the issues be fixed?
<fantasai> emilio: tangential to this
<fantasai> emilio: removing [open] doesn't fire the right events and fix the behavior currently
<gregwhitworth> q+
<fantasai> emilio: it's not great
<fantasai> emilio: might want to fix it, but it's a separate issue
<astearns> ack gregwhitworth
<fantasai> gregwhitworth: I agree fixing them is a separate issue, but not separate wrt this discussion
<fantasai> gregwhitworth: because I like what leaverou is proposing here
<fantasai> gregwhitworth: In order to make dialog more cohesive, I think we should go back and fix it
<fantasai> gregwhitworth: Is there a massive web-compat problem with making open do the right thing and fire all the events?
<fantasai> iank_: There's a few other pressures here
<fantasai> iank_: I would be concerned with any compat change around that area. Been there for a long while.
<fantasai> iank_: Took us 6 months to do compat analysis just for this change
<fantasai> iank_: and it's a bit pressing
<fantasai> iank_: and with any major compat change, the window closes the longer it exists
<leaverou> it seems to not have shipped in Gecko or WebKit, how popular can it be? https://caniuse.com/?search=dialog
<fantasai> iank_: Yes, we can potentially fix open and how that work, yes we can add modal, but that would take a long time
<fantasai> emilio: My other concern with magic attributes that fire events is XSS
<fantasai> emilio: ? fires an event even when you parse it
<fantasai> emilio: and we only realized about DETAILS way too late
<fantasai> s/?/DETAILS/
<fantasai> iank_: I don't think having an attribute API for dialog is a good idea
<fantasai> iank_: I would push back against adding a modal attribute on that basis
<fantasai> gregwhitworth: Then, channeling Rossen from Grid, I think we should be going for symmetry
<fantasai> gregwhitworth: Not fixing open maybe but get rid of it
<fantasai> astearns: This discussion seems to be opening wider and wider. Maybe kick over to Open UI?
<fantasai> astearns: to discuss pseudo vs. attribute vs. no attribute?
<emilio> q+
<fantasai> iank_: If we want to get rid of Chrome's special dialog behavior here, we can only do this for another few months
<fantasai> iank_: People will be relying on dialog, and will rely on our behavior. So would like a decision now.
<fantasai> iank_: At the request of this group and other browser vendors, did a lot of compat analysis
<fantasai> iank_: ...
<gregwhitworth> fantasai, I'll scribe ya
<fantasai> emilio: My other bit about why I think modal attibute is not a great idea is that it breaks how the JS APIs structure
<astearns> ack emilio
<fantasai> emilio: Whether modal pseudo-class applies depends on how you open the dialog
<fantasai> emilio: but you could toggle modal attribute while the dialog is open
<leaverou> re: webcompat, <dialog> is used in <0.005% of websites (6000 in HTTPArchive): https://docs.google.com/spreadsheets/d/1Ta7amoUeaL4pILhWzH-SCzMX9PsZeb1x_mwrX2C4eY8/edit#gid=781932961
<fantasai> emilio: At the point you can toggle modal, ...
<fantasai> emilio: I think that would be great
<fantasai> emilio: but fixing dialog positioning is important, would rather not get side-tracked
<TabAtkins> q+
<astearns> ack fantasai
<gregwhitworth> fantasai: so I agree with iank_ we should fix the styling issue for compat
<gregwhitworth> fantasai: clearly, it will take a while for a modal attribute - maybe that's still a possibility
<gregwhitworth> fantasai: one is that we intro a new pseudo class that everyone can use
<gregwhitworth> fantasai: other option is to do one internally the way that FF is doing
<gregwhitworth> fantasai: then we decide how to move forward via a pseudo class and attribute
<leaverou> q+
<astearns> ack TabAtkins
<fantasai> TabAtkins: We seem to have fairly broad implementer agreement that they likely don't want to add modal
<fantasai> TabAtkins: Going back, we could maybe pursue removing open attribute
<fantasai> TabAtkins: so that's a possibility for us
<astearns> ack leaverou
<emilio> q+
<fantasai> leaverou: Adding a modal attribute is just a possibility. Could alternately add a value to open
<fantasai> leaverou: open=modal
<fantasai> leaverou: But goes back to ???
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<fantasai> leaverou: Introducing HTML elements that can't be used without JS is an issue
<fantasai> leaverou: Shouldn't we fix this generally?
<astearns> ack emilio
<leaverou> It sounds like the same arguments apply to <details> as well
<leaverou> Is the direction we want to go to be adding interactive HTML elements that can't work without JS?!
<leaverou> shouldn't these issues be addressed instead of giving up on HTML attributes altogether?
<fantasai> emilio: leaverou, and gregwhitworth, would you be opposed to defining a hidden pseudo-class, so we can move forward with the styling issue without changing the public API of this ?
<fantasai> emilio: It's nice to expose the pseudo-class from the UA stylesheet
<fantasai> emilio: but also fine with keeping it internal
<iank_> i can live w/ that as well.
<fantasai> emilio: and address the open/modal attributes separately from this
<fantasai> astearns: So proposed solution is to add a hidden :modal pseudo-class for now.
<fantasai> florian: Do we need to define that a hidden pseudo-class exists? Do we need to spec anything?
<fantasai> TabAtkins: no
<fantasai> emilio: Define in HTML spec using prose instead of a pseudo, but that's fine
<fantasai> astearns: We'd spec as browser-internal thing, and then if it proves out, then we write spec text to expose it
<fantasai> leaverou: Is a hidden pseudo-class undocumented or unusable by authors?
<fantasai> TabAtkins: only usable in UA style sheet
<fantasai> gregwhitworth: I think it's a good compromise.
<fantasai> gregwhitworth: Deals with compat issue, but leaves the door open to imprve the API
<fantasai> gregwhitworth: Maybe worth noting it somewhere?
<fantasai> iank_: We'll be adding this to the HTML spec , most likely way to specify this
<TabAtkins> Yes, this is the correct way to do it
<fantasai> iank_: is to define the :modal pseudo-class and define that it's only usable in UA stylesheet
<fantasai> iank_: maybe call it :-internal-modal
<fantasai> RESOLVED: Add a hidden pseudo-class for this purpose, in order to solve styling issue while leavine open the possibility of HTML improving its API
<TabAtkins> ScribeNick: TabAtkins

[gregwhitworth]

emilio: might want to fix it, but it's a separate issue
...
iank_: I don't think having an attribute API for dialog is a good idea

@bfgeek @emilio @LeaVerou the aspect of open being an attribute

I would like to call attention to a resolution in Open UI regarding the open attribute/property on the <select> that would behave the way in which authors would expect it to (eg: open/close based on the attributes existence).

openui/open-ui#236

cc: @una @dandclark @melanierichards

[mangelozzi]

I see this issue is closed, but I don't understand how one is supposed to position the dialogue? E.g. some wish to position the dialog at the top of the screen?

[SebastianZ]

As shown in my previous comment, the dialog is centered via margin: auto; by default. So, you can position it at the top by adding margin: 0;.

Sebastian