[Popup] Do we need the "open" content attribute?

[melanierichards]

On MSEdgeExplainers #467, @mfreed7 asked:

The "open" attribute was recently re-added to the proposal. I'm wondering what the driving use case is for that attribute. I can see from the explainer that opening a popup on "load" is listed there. Is that it?

An easy alternative to the "open" attribute, for that use case, is:

window.onload = () => {myPopup.show();};

I ask because there are complexities:

1. What if multiple non-nested (or nested!) popups have the "open" attribute?
   1. In this case, only one of them should show, so at least an order needs to be determined. Perhaps the behavior should be as-if the .show() method were called in tree order on all of them?
   2. For the non-shown popups above, should a "hide" event be fired on them?
   3. For the non-shown popups above, should their "open" attribute be removed? If not, then they'll still be wearing the "open" attribute while not actually being displayed. (The UA stylesheet cannot therefore simply use popup:not([open]) {display: none !important;} to hide the popup.)
2. When an open <popup> is removed from the tree, the <popup> plus all of its non-ancestor <popup>s need to be hidden.
   1. Without the "open" attribute, this is relatively easy, because hiding popups doesn't affect the DOM tree, just the layout tree.
   2. However, when the "open" attribute needs to be removed from each of those hidden popups, this gets more tricky. Node removal (in Chromium, and I think by spec, modulo mutation events) is forbidden from modifying the DOM tree. Therefore, the removal of the "open" attribute would need to be done at a later time (micro-task timing?), which would be observable.
3. What if a disconnected <popup open> node is created?
   1. Is it confusing that popup.getAttribute('open') is non-null for this disconnected, non-displayed <popup>?
   2. What if this node is appended to the document? Should it act as if .show() were called upon insertion? If so, some of the same concerns as #2 above apply here - other <popup>s will need to be hidden as this node is inserted into the document.

All of the above can be overcome, but I'm curious if the added complexity is worth the benefit provided by the "open" attribute. I do know that parallelism to <dialog> has been brought up here. But in this case specifically, <dialog> is quite different - many <dialog>s can be open at a time, and they don't close each other. So none of the complexity above applies to <dialog>.

[melanierichards]

We heard this feedback from a few different sources:

• HTML editor feedback, from the perspective of alignment with <dialog>. FWIW Domenic also offered reconsidering that attribute for <dialog>.
• TAG review, "so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector."
• Authors, who were concerned that popup would not have a mechanism for declarative invocation. Part of this is solved by the popup attribute, but there was a specific request or two to have some method for invocation effectively "on page load".

I think those requests capture the extent of my awareness of use cases here:

• Showing a popup before interaction w/ other elements
• Styleability

Before digging into the various technical complexities Mason listed out + finding a resolution for these, I think it would be good for the group to discuss whether there are other use cases for the open attribute on popup, as well as how critical this attribute is for authors given the ability to invoke via 1) the popup attribute and 2) the show() event.

[mfreed7]

Thanks for these pointers! A few replies below...

• HTML editor feedback, from the perspective of alignment with <dialog>. FWIW Domenic also offered reconsidering that attribute for <dialog>.

Here, I note that the feedback is really to make <popup> and <dialog> as close together as possible, and I agree with that. @domenic explicitly states that there are already problems with the open attribute on <dialog>, and says this:

Second-best would be making the affirmative decision in the HTML and implementer community that open="" on <dialog> was just a mistake, and should never be used; we would then deprecate it (i.e. tell web developers not to use it, even if implementations have to support it), and provide another styling hook for open <dialog>s and <popup>s.

I like this option the best, by far.

• TAG review, "so that authors can a) open the popup declaratively and b) target opened popups with an attribute selector."

Here, I think a) just means what is said below: the ability to open the popup "on page load". If the intention is to allow setAttribute('open','') to open the popup, then I'm not sure what the advantage is over popup.show(). As for b), I am curious about the use case for that. When the popup is in the closed state, it is by definition invisible. So popup[open] {my styles} should be functionally equivalent to popup{my styles} because whenever my styles apply, the popup must be open. Help me understand that point, I'm sure I'm missing something. In addition to this, as I mentioned in the OP, since multiple popups can have an open attribute, but per the rules, only one can be shown at a time, selectors of the sort popup[open] will improperly target invisible popups.

• Authors, who were concerned that popup would not have a mechanism for declarative invocation. Part of this is solved by the popup attribute, but there was a specific request or two to have some method for invocation effectively "on page load".

Discussed a bit above, and in my OP, but can you help me understand how/why this is easier/better than just window.onload = () => {myPopup.show();};. Using the open attribute is subject to a lot of ambiguity and confusion (e.g. closed popups that still have the open attribute). Requiring either JS or the popup attribute seems pretty clean.

Before digging into the various technical complexities Mason listed out + finding a resolution for these, I think it would be good for the group to discuss whether there are other use cases for the open attribute on popup, as well as how critical this attribute is for authors given the ability to invoke via 1) the popup attribute and 2) the show() event.

Agreed +100 here. I really don't want to cut off use cases, if there are good ones. I just want to avoid complexity where it isn't needed.

[flackr]

To add on to the example I presented during the discussion, I think we can avoid a lot of the complexities here by following the pattern used by checked on input elements.

In particular,

• The checked html attribute sets the initial state but is not live. The last checked radio button is the one which is ultimately checked (i.e. as if it is done in order).
• The checked IDL attribute is live.

[mfreed7]

Thanks to everyone for the great discussion on this issue. I want to add some comments about what I heard:

• First, the title of this issue really should be "Do we need the 'open' content attribute?". I see the value of the 'open' IDL property (i.e. const popupIsOpen = popup.open) and there isn't any technical complexity around implementing that. This issue is about the content attribute specifically: <popup open>.
• Another thing I heard which is a good point is that we should consider Find in Page: should the content of a hidden <popup> be findable? And when found, should the popup be auto-opened? I've added that as a comment in another issue, for further discussion.
• There was some discussion of another possible attribute (e.g. 'dismissable') that would "turn off" the light dismiss behavior. This seemed like a better use case for the <dialog> element, but the point was also made that <dialog> is a 1-engine element at the moment.
• As mentioned in the comment just now, @flackr proposed a new direction, for a content attribute that only controls the visibility on page load, but doesn't reflect current state, and can't be used to "control" the visibility of the <popup>. I really like this proposal, as it alleviates all of the complexities I brought up in the OP. We'd need to choose a good name - how about initiallyopen? And it would have to be better-defined when exactly it should be opened. On DOMContentLoaded? Before that?

The general tone seemed (to me at least!) to be that it was "ok" not to have a full-featured open content attribute, particularly if the initiallyopen suggestion was available. That's at least what I heard, but I am obviously biased. Please chime in if I missed an important use case for the open content attribute.

[melanierichards]

Thanks so much for dropping in a summary of today's discussion, @mfreed7! This tracks with what I heard as well, and a great place for us to pick up on the next telecon to try and reach some resolutions.

To the rest of the group: as Mason mentioned, please feel free to chime in with use cases if we missed any or you were not able to make today's call!

P.S. Updated the issue title 😉

[domenic]

I like the initiallyopen="" idea, and it seems like it's headed in a good direction. In particular I want to emphasize @mfreed7's point of using a good name (not open="") for the content attribute.

In particular, although the general idea of separating the content attribute and IDL attribute like checkbox does, the specific choices checkbox made are not good and cause a lot of developer confusion. For checkbox, the defaultChecked IDL attribute reflects the checked="" content attribute, and the checked IDL attribute represents read-write live state (which usually does not, but sometimes does, correlate with the checked="" content attribute, depending on form resets and various other fun).

A clean model would be something like an initiallyOpen IDL attribute which reflects the initiallyopen="" content attribute, and a separate open IDL attribute which has no correlation with initiallyOpen/initiallyopen="". (Except, of course, that if initiallyopen="" happens to actually cause the popup to open, then open will be true.)

(As for defaultopen="" vs. initiallyopen="" vs. other ideas, I don't have strong feelings. defaultChecked is a small precedent, but since it's part of a weird model it's not a great precedent.)

[ghost]

I just wanted to chime in and say that for the styling argument, we could simply expose the state through a pseudo class as is the norm. Using a live attribute seems wrong as state has been communicated through pseudo classes for some time now.

It would also allow for consistency with other elements such as detail.

Edited to remove triangle brackets.

[gregwhitworth]

With regards to styling - I completely agree with @BrentARitchie by defining a new pseudo class that applies to certain elements (eg: dialog:open, popup:open). There are enough use-cases where popups are visible on load and so I think that initialOpen content attribute is a solid approach to deal with this scenario.

@domenic thanks for linking in the TAG review as that does highlight a headache we should avoid.

[mfreed7]

With regards to styling - I completely agree with @BrentARitchie by defining a new pseudo class that applies to certain elements (eg: dialog:open, popup:open). There are enough use-cases where popups are visible on load and so I think that initialOpen content attribute is a solid approach to deal with this scenario.

Thanks for all of the comments here. I just wanted to highlight one of them - above. @BrentARitchie and @gregwhitworth can you clarify (e.g. with an example) what could be done with a popup:open pseudo-state that cannot be done with a simple popup selector? See my point above, but TL/DR since the popup is only visible when it is open, I don't understand why you'd need to select only open popups. I'm honestly trying to understand the use case, because I feel like I'm missing something. Perhaps it's just ease of use with querySelector() or something?

[ghost]

In response to @mfreed7, I created a basic demo for a use case using dialog. It has many of the same concerns we are talking about with the Popup element. The the demo is at https://codepen.io/saveoney/full/bGgvQNZ.

Essentially what I am doing is making the Dialog partially visible (bottom left) to denote that something needs attention. When the dialog is clicked the rest of the content is then shown as normal. This is only a single use case. For the popup specifically, I could envision part of it being shown as a hint and then expanded/opened as needed.

This technique uses what is already available to cut down on DOM nodes and JavaScript. To note, this demo does not consider accessibility, and is slightly broken in that respect, but fixable with a little more code. I also don't claim that this is an example of great technique, just something conceivable in the real-world.

[gregwhitworth]

This was discussed in today's telecon - here are the resolutions:

RESOLUTION: will not contain an "open" content attribute. It will still have an "open" IDL attribute that reflects its open/hidden status. It will have an "initiallyopen" content attribute, which is reflected in an "initiallyOpen" IDL attribute. If "initiallyOpen" is present on page load, the popup will be shown.

and here is the resolution regarding styling:

RESOLUTION: the will have a pseudo state (name TBD) which reflects the open state of the popup.

@melanierichards to open a new issue regarding the pseudo selectors.

[davatron5000]

As the lone dissenter from last week's meeting, I wanted to log an opinion in regards to the styling options question.

As an author, I value consistency. In my day-to-day building systems, I encounter a lot one-off inconsistencies in the platform. Especially when crossing between HTML, CSS, and JS. Not to create too big of a strawman, but in order to lazyload an asset, you do the following: <img loading=“lazy”>, <script async|defer>, <link rel=“preload” as=“style”>). Three distinct APIs to do more or less the same thing hints at a lot of one-off bespoke problem solving.

So, as an author, the currently existing way of styling off of [open] offers me a lot of consistency versus a new :open pseudo-class that doesn't exist yet.

An [attribute] in hand is worth two :pseudo-classes in the bush, as it were.

This element in particular introduces a handful of 🆕 attributes and pseudo-classes.

• initiallyOpen
• anchor
• delegatefocus
• popup
• :open

I'm not saying each of these low-level APIs don't have value or solve problems, I'm only pointing out we're inventing quite a few new concepts without a broader plan or strategy.

After reading a handful of Github issues, specifically whatwg/html#5802, I understand the specific problems with [open]. The :open pseudo-state does seem like a better solution so long as other elements (<dialog>/<details>) also get a consistent styling API. Because as it stands, this would introduce an inconsistency where foo.open == true in JavaScript but that wouldn't be reflected in HTML.

[gregwhitworth]

The :open pseudo-state does seem like a better solution so long as other elements (<dialog>/<details>) also get a consistent styling API. Because as it stands, this would introduce an inconsistency where foo.open == true in JavaScript but that wouldn't be reflected in HTML.

Agreed. Given details & summary are widely supported the attribute probably can't be removed and while <dialog> isn't supported everywhere I'm sure there will still be some compat pain. However, I do agree that the pseudo-class should be supported on any element that has an open state. So ultimately, when this pseudo class goes to the CSS WG we would want to ensure that we list out the elements concretely in the spec (and of course update the pseudo class with each new component/control).

I'm not saying each of these low-level APIs don't have value or solve problems, I'm only pointing out we're inventing quite a few new concepts without a broader plan or strategy.

Can you scope in on what you mean by "broader plan or strategy" as it pertains to this issue?

[melanierichards]

Hey folks, for the purposes of agenda-building, anything we want to revisit or discuss on this issue at this week's telecon?

[zcorpan]

From #416 (comment)

I would prefer shorter and easy-to-spell names for HTML, generally. (c.f. misspellings of <script language>.)

initiallyopen might be a bit long and subject to misspellings, alternatives could be initopen or autoopen (to mirror autofocus).

[css-meeting-bot]

The Open UI Community Group just discussed Do we need the "open" content attribute?, and agreed to the following:

• RESOLVED: The popup API should not have a "live" `open` content attribute that reflects open/closed state.
• RESOLVED: The popup API should have an `initiallyopen` content attribute that controls initial openness.

The full IRC log of that discussion

<gregwhitworth> Topic: Do we need the "open" content attribute?
<gregwhitworth> github: https://github.com//issues/311
<hdv> masonf: #311 is an old issue but it still applies, I feel, in the same ways
<hdv> masonf: the proposal has an open attribute that is present wehn the popup is visible and not present when it is invisible
<hdv> s/wehn/when
<hdv> masonf: what I'm starting to think… we probably should keep all of the resolutions we made on #311
<hdv> masonf: including we should not have an open attribute that is live, but instead we should have an initiallyOpen attribute, a bit liked checked, it just controls what happens on page load and is not live
<flackr> +1
<hdv> masonf: and then we would have something in CSS that is a pseudo state that reflects whether the thing is open or not
<hdv> masonf: those were the three resolutions we had for this in #311
<flackr> q+
<scotto> that all makes sense to me
<gregwhitworth> ack flackr
<hdv> flackr: the one thing I wanted to ask, about the top layer behaviour… is that CSS for something that is on the top layer, or something that is tied into a popup being open
<hdv> masonf: whether it is in the top layer is strictly up to the UA
<hdv> masonf: developers would be free to do what they want in CSS land but nothing they would do there would affect whether it was in the top layer
<davidluhr> q+
<hdv> masonf: whether it should be display none important so that you couldn't override, or maybe without important so you could override it… that's still up for discussion
<scotto> q+
<hdv> flackr: I'm leaning towards having something that is overridable
<hdv> masonf: me too
<gregwhitworth> ack davidluhr
<hdv> davidluhr: my understanding is that `open` has some challenges because <dialog> doesn't handle the accessibility well… are we avoiding something that would be more consistent because of problems in an existing element?
<hdv> masonf: there is definitely a consistency argument; we have many things to handle openness in the platform, this may be one of them
<hdv> masonf: the last time we discussed this was in #311… we probably want to move things like <dialog> to this 'better' way
<hdv> masonf: there are architectural things… accessibility is an issue. it is hard to have the UA manage attributes
<hdv> masonf: whereas in CSS it would 'just work'
<gregwhitworth> ack scotto
<hdv> scotto: I wanted to +1 the idea of the simple-ish UA styling
<gregwhitworth> q+
<hdv> scotto: Greg, I remember you mentioned before it might be useful for responsive design purposes to allow a popup to display inline, that could arguably be done with display block… I think that is important to support
<hdv> scotto: I know I was one of the people mentioning the open attribute last time… after reading up on it this morning I would agree not to use `open` here
<hdv> scotto: +1 to not using `open` but using CSS
<hdv> gregwhitworth: +1 as well… to your question, davidluhr, Domenic Denicola has a great writeup in a TAG review somewhere about why you would not want content attributes like in details/summary
<hdv> gregwhitworth: very worthwile reading
<hdv> gregwhitworth: we do have to have that base UA stylesheet solution of enabling browser makers to style to their heart
<hdv> gregwhitworth: spicy sections do have some style things, but overall it is still basic, but they handle responsive design and accessibility out of the box
<hdv> gregwhitworth: we don't want to get to the point where we, like, ship selectmenu and have it so that people can't change some things, like set something to display grid if they want to do that
<BoCupp> re: using CSS instead, was there an answer to the question about why popup:open would be useful over just a plain popup selector given popup elements are only rendered when open
<hdv> gregwhitworth: so I think we need that standardised UA stylesheet that is truly just 'base'
<BoCupp> q+
<hdv> gregwhitworth: I agree with the direction you're taking on this, masonf
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack BoCupp
<hdv> BoCupp: I joined a little later so may have missed some of it… I hear about CSS being preferred to the content attribute
<hdv> BoCupp: why do we need a pseudo class, when it is only rendered when it is open?
<hdv> masonf: I think we will not use display: none!important in the UA stylesheet, therefore we would need a pseudo state
<hdv> BoCupp: so it being in the top layer mean that it is managed by the browser, but visibiltiy is not?
<hdv> masonf: a pseudoclass for it being in the top layer, and a stylesheet rule that says things that are in the top layer as display: none/visibility: hidden, but without !important
<hdv> masonf: and that would also mean you could animate it if you like
<hdv> BoCupp: there's a lot to think about
<hdv> masonf: so most of that is identical to the discussion we already had in #311, there doesn't seem to be a big difference
<hdv> flackr: if you did animate it, you might see a flicker
<hdv> flackr: if during the animation it would go out of the top layer
<hdv> masonf: part of the proposal is that the UA manages being in the top layer… might be an issue?
<hdv> flackr: I don't hav e a good answer
<hdv> flackr: we did talk about some reasonable timeout that could help with this
<hdv> s/hav e/have
<masonf> Proposed resolution: The popup API should adopt generally the same resolutions reached in https://github.com//issues/311, e.g. an `initiallyopen` attribute, no live `open` content attribute, a CSS pseudo class for `:open`, etc.
<hdv> gregwhitworth: seems like there is general agreement but sub issues that might need some more discussion
<masonf> ...subject to sub-issues being discussed.
<gregwhitworth> q?
<BoCupp> q?
<BoCupp> q+
<masonf> maybe change that to `:toplayer` because I think that's better. Subject to bikeshedding.
<gregwhitworth> ack BoCupp
<hdv> BoCupp: I'd like a little more to consider that the UA is going to render the… I'm just processing that
<hdv> BoCupp: would it be without precedence to say that the presence of that attribute means that the display property could be ignored?
<hdv> gregwhitworth: what I'm hearing is… maybe we should split #311 to three different issues, then gain resolutions on those sub issues?
<hdv> masonf: 3 parts are: `initiallyOpen`, the `open` content attribute and some CSS for the pseudo states
<masonf> Proposed resolution: The popup API should not have a "live" `open` content attribute that reflects open/closed state. Proposed resolution: The popup API should have an `initiallyopen` content attribute that controls initial openness.
<hdv> BoCupp: `intiiallyOpen` seems fine to me… might need a little more time for the CSS for pseudo class
<masonf> RESOLVED: The popup API should not have a "live" `open` content attribute that reflects open/closed state.
<BoCupp> q?
<masonf> RESOLVED: The popup API should have an `initiallyopen` content attribute that controls initial openness.

[mfreed7]

Given the resolutions above, I'm going to close this issue. I've opened a fresh issue to discuss the third part of this issue, the CSS pseudo class for top layer status.

Thanks!

[mfreed7]

Well, I don't have issue closing permissions, so I'll just say that I think this issue can be closed, and hope someone does that. 😀