[popup] Standardize the basic CSS for an element with the popup attribute

[mfreed7]

Akin to the <dialog> element's standardized styling, I think it'd be helpful to authors to get a very basic set of standardized styles that the UA applies to pop-ups by default. Otherwise, <div popup>Hello!</div> is just the word "Hello", and isn't set apart from the page at all, which can be a bit confusing.

The default styles can be almost identical, I think, to the ones for dialog, perhaps only changing position:absolute to position:fixed:

[popup="" i],
[popup=auto i],
[popup=hint i],
[popup=manual i] {
  position: fixed;
  inset-inline-start: 0;
  inset-inline-end: 0;
  width: fit-content;
  height: fit-content;
  margin: auto;
  border: solid;
  padding: 1em;
  background-color: Canvas;
  color: CanvasText;
}

It would seem to make sense for this UA rule to come before any rules that match specific elements, so that element-specific CSS overrides these.

Generally, thoughts? Objections?

[mfreed7]

Similarly, the fullscreen spec contains this set of standard styles that apply to the ::backdrop pseudo element:

::backdrop {
  position:fixed;
  top:0; right:0; bottom:0; left:0;
}

*|*:not(:root):fullscreen::backdrop {
  background:black;
} 

As written, and apparently as implemented in at least Chromium, the above CSS is used for both fullscreen elements and modal <dialog> elements.

For a pop-up element, I think the most common usage pattern would be to not style the ::backdrop, because the pop-up isn't modal and doesn't want to obscure the page. But it seems helpful to at least include the sizing rules, and perhaps manage pointer events more carefully? How about this?

[popup="" i]::backdrop,
[popup=auto i]::backdrop,
[popup=hint i]::backdrop,
[popup=manual i]::backdrop {
  position: fixed;
  top:0; right:0; bottom:0; left:0;
  background: transparent;
  pointer-events: none !important; /* So that clicks on the page can light-dismiss the pop-up */
}

[scottaohara]

I think the thing I'm most unsure of is the initial positioning.
ideally these popups would be positioned based on their anchoring element, where applicable. They wouldn't necessarily be fixed all the time?

Other question, so long as the attribute can be used on any element, i would expect some of these UA styles to be rather weak - e.g., the hidden attribute's display: none, to ensure that the base UA styles of a specific element (let's say blockquote) or other author styles take priority. The latter not so much being a question as an expectation, but just trying to cover all the basis.

[mfreed7]

I think the thing I'm most unsure of is the initial positioning. ideally these popups would be positioned based on their anchoring element, where applicable. They wouldn't necessarily be fixed all the time?

Hmm, interesting point. I think the problem is that technically you don't need to use the Anchor Positioning API to position a pop-up - you can put it top-left, or centered on the screen or whatever. I'm not sure what default style we'd apply that would "typically work" in the case that the pop-up has an anchor attribute. Perhaps a rule like:

[popup][anchor] {
  top: anchor(bottom);
  left: anchor(left);
}

That feels odd to add to the standardized CSS though.

Other question, so long as the attribute can be used on any element, i would expect some of these UA styles to be rather weak - e.g., the hidden attribute's display: none, to ensure that the base UA styles of a specific element (let's say blockquote) or other author styles take priority. The latter not so much being a question as an expectation, but just trying to cover all the basis.

Totally agree - I'm not exactly sure how to specify that though. But that's what I meant by this sentence:

It would seem to make sense for this UA rule to come before any rules that match specific elements, so that element-specific CSS overrides these.

[scottaohara]

yeh, thinking about it more, maybe if those anchoring styles were put in place (and if an rtl style where it was right: anchor(right) instead of left), then it would be on the author to do the rest. that seems like the best reasonable default.

and sorry, don't know how that last sentence you had in there about UA style positions didn't register for me.

[mfreed7]

I think we likely also need to pull in a few more lines from the The rendering section of the spec for <dialog> under the "when its is modal flag is true" section, particularly these:

  inset-block-start: 0;
  inset-block-end: 0;
  overflow: auto;

The <dialog> rendering section also includes these two rules, which seem like they must have some history. Not sure whether they should be ported to <div popup> or not:

  max-width: calc(100% - 6px - 2em);
  max-height: calc(100% - 6px - 2em);

I'm sure @domenic knows where these come from and whether they are required here.

[tbondwilkinson]

For simplicity, I would remove border and padding from the default stylings and set background color to transparent. I can imagine most people overriding this.

I agree that you'd only want anchor positioning when you have an anchor element, but I'm not sure how you would style that from the UA.

[mfreed7]

For simplicity, I would remove border and padding from the default stylings and set background color to transparent. I can imagine most people overriding this.

I just copied those nearly verbatim from <dialog>'s styling. The rationale, I imagine, was to set the <dialog> off from the page at least a little, by default. If you remove the border and make the background transparent, when you first start playing with <div popup>Hello!</div>, it can be confusing, since you can barely find the word "Hello!" overlaying other page content somewhere. Adding the padding/border/background makes it very easy. And as you point out, it's very easy to override.

@domenic do you know where the conversation took place about this styling for <dialog>? It'd be interesting to see how we arrived here.

[scottaohara]

While likely to be overwritten, being that this content should work in situations where author styles could be removed or revised (e.g., browser reader mode), I don't understand how it would be ok for the UA default style for an element whose purpose is to overlay other content of the page could have a transparent background.

[domenic]

@domenic do you know where the conversation took place about this styling for <dialog>? It'd be interesting to see how we arrived here.

I can't find anything. In whatwg/html@2fb24fc they arrived in the spec with full default styling. Various Google searches with site:w3.org bugzilla or site:lists.whatwg.org don't give any leads.

I personally like the idea of following the weak precedent provided by <dialog>. At least the background and border. I could be swayed to omit the padding.

[domenic]

Regarding ::backdrop styling, I'm not sure many additional styles are necessary? You already get position, top, right, bottom, and left from the fullscreen spec's general ::backdrop. background should default to transparent. So what's left is just adding pointer-events: none !important; for the popup cases.

[mfreed7]

@domenic thanks for digging, and too bad there's not much context. Also thanks for pointing out that the fullscreen spec already mandates most of the ::backdrop styling. Chromium's implementation is individual per API, which is why I didn't even check.

If I keep the background/border because I heard several supportive comments, leave out the padding, and remove the overlap on ::backdrop styling, here's what's left:

[popup="" i],
[popup=auto i],
[popup=hint i],
[popup=manual i] {
  position: fixed;
  inset-inline-start: 0;
  inset-inline-end: 0;
  inset-block-start: 0;
  inset-block-end: 0;
  width: fit-content;
  height: fit-content;
  margin: auto;
  border: solid;
  overflow: auto;
  color: CanvasText;
  background-color: Canvas;
}

[popup="" i]::backdrop,
[popup=auto i]::backdrop,
[popup=hint i]::backdrop,
[popup=manual i]::backdrop {
    pointer-events: none !important;
}

[popup]:-internal-popup-hidden {
  display: none;
}

Objections?

[domenic]

[popup]:-internal-popup-hidden

This seems bad?

[mfreed7]

[popup]:-internal-popup-hidden

This seems bad?

Sorry, in what sense? The behavior is bad? Or using an internal pseudo notation isn't the right way to express this in specs? (If the former, help me understand why it's bad? If the latter, what's the right way to specify this?)

[tbondwilkinson]

I think an :open pseudoclass kind of implies the possibility for a :closed? That feels like what Domenic might be asking. I think :opening and :closing are useful additional states, where something could be still marked as :closed but also as :opening for styling transitions, perhaps.

[mfreed7]

I think an :open pseudoclass kind of implies the possibility for a :closed? That feels like what Domenic might be asking. I think :opening and :closing are useful additional states, where something could be still marked as :closed but also as :opening for styling transitions, perhaps.

Ahh, you might be right that :closed was what @domenic was requesting? I always wonder whether we really should add negated pseudo classes for everything, when we have :not(). But here, this is interesting, because the "open" state for a pop-up is actually tri-state (hidden, transitioning, and showing). So there is an unobservable state unless we add a specific pseudo for it. Hence the :opening (or :opening-or-open?) suggestion.

[tbondwilkinson]

True, :not(:open) could be the thing that you specify here for display: none; for now?

I hadn't considered the option of a tri-state... or would it be a quad state so you could style transitioning to open and transitioning to close separately? I think people could probably argue for a while about whether to considering something that is "opening" "open" or "closed" so it might be good at least to consider side-stepping that argument by considering that a separate state. I do think people will fall into various categories:

1. Consider open/close to be a binary. Either a popup is open or its not.
2. Consider open/close to have additional edge states for opening and closing. And whether they considering opening/closing to fall under open or close may vary.

[mfreed7]

True, :not(:open) could be the thing that you specify here for display: none; for now?

Can't do that - :open means the pop-up is in the "showing" state. So :not(:open) would mean either "hidden" or "transitioning", and we definitely only want to apply display:none when "hidden". Else transitions are broken.

I hadn't considered the option of a tri-state... or would it be a quad state so you could style transitioning to open and transitioning to close separately? I think people could probably argue for a while about whether to considering something that is "opening" "open" or "closed" so it might be good at least to consider side-stepping that argument by considering that a separate state. I do think people will fall into various categories:

1. Consider open/close to be a binary. Either a popup is open or its not.
2. Consider open/close to have additional edge states for opening and closing. And whether they considering opening/closing to fall under open or close may vary.

Ugh. This is why I hesitated to specify an explicit pseudo state for this. Perhaps this part of the feature needs more discussion before we introduce it. Certainly I don't think it is needed for "v1".

---

Last call for objections to this being the proposed standard CSS for popup:

[popup] {
  position: fixed;
  inset: 0;
  width: fit-content;
  height: fit-content;
  margin: auto;
  border: solid;
  padding: 0.25em;
  overflow: auto;
  color: CanvasText;
  background-color: Canvas;
}

[popup]::backdrop {
    pointer-events: none !important;
}

[popup]:{spec language for "is hidden"} {
  display: none;
}

[mfreed7]

I'm going to close this issue as agreed, for now. I'm very happy to re-open it if something comes up.

Spec-wise, I think the {spec language for "is hidden"} portion is easier to write in spec prose than CSS, so the details we've been discussing above are likely implementation details. @josepharhar FYI, and hopefully I'm correct that there's an easy sentence to describe visibility. Could you please incorporate the updated CSS above into the spec PR?

[josepharhar]

Spec-wise, I think the {spec language for "is hidden"} portion is easier to write in spec prose than CSS, so the details we've been discussing above are likely implementation details

Yes, since the secret pseudo selector we're using in chromium should not be in the spec, I crafted the spec to have the same behavior without any selectors.

Could you please incorporate the updated CSS above into the spec PR?

Done: https://github.com/whatwg/html/pull/8221/files/9e0421c76e82132537c90e7da6e04885689c79de..a2cd6f0457d5d959916e1c01ba5c6a14a72160ee

[scottaohara]

@mfreed7 was playing around with popup today and noticed that the default style for the backdrop was updated so that is has a background of rgba(0, 0, 0, 0.1). That doesn't jive with what's been outlined here though, as the backdrop shouldn't have any background color to it by default.

edit:

i realized this happened because i was using a dialog element that i was using popup=manual on. So, even though it was non-modal, the dialog's backdrop was being made visible.

[mfreed7]

Re-opening this issue to discuss what we need to add to the UA stylesheet to avoid (maybe?) the <dialog popup> getting that background color. Then again, maybe that's the correct background color since it's a <dialog>?

[scottaohara]

thanks @mfreed7. Definitely think this is something that would need to be avoided since a dialog opened via .show() doesn't have a backdrop - which makes sense because its modeless. So a dialog opened via showPopUp - also being modeless - should also not have a backdrop by default.

[mfreed7]

I suppose the right thing to do here would be to modify the UA stylesheet to make sure rgba(0,0,0,0.1) only gets applied to dialog:modal and not dialog:open.

[mfreed7]

I suppose the right thing to do here would be to modify the UA stylesheet to make sure rgba(0,0,0,0.1) only gets applied to dialog:modal and not dialog:open.

Ok, the Chromium implementation has been modified to do this, by making the UA selector

[popup]:open::backdrop {

and adding

background-color: transparent;

@josepharhar is adding the same to the spec. I'm going to close this as re-resolved.