The popup attribute should allow the empty string value

[domenic]

I had an offline discussion with @mfreed7 regarding invalid, empty, and missing values which I wanted to relay here. Summary: I think popup (or, equivalently, popup="") should be allowed and should be equivalent to popup=popup. This does not cause forward-compat issues and makes the API more pleasant.

As background, remember that in HTML, attribute is the same as attribute="". There's nothing special about an attribute with no equal sign; it's just a shorthand for setting the attribute's value to the empty string. In particular there's no special booleanness vs. stringness for attributes; attribute values are strings, if the attribute is present at all. (Some parts of the spec will interpret certain attributes as booleans, by saying any string value, including the empty string, is treated as "true", and a missing attribute is treated as "false".)

Also as background, the popup attribute is slated to be an enumerated attribute. These have states and keywords. Keywords are the developer-facing API, and are the strings that appear inside the attribute value. States are the underlying model.

It looks like you have the following states: no-popup, popup, hint, and async. (Some or all of these might be renamed per #491 and #532, but I'll use these names for now.)

Then the question is how to map attribute presence/values to those states. It seems like there's broad agreement on the following:

• ASCII case-insensitive match for hint will map to the hint state
• ASCII case-insensitive match for async will map to the async state
• Missing attribute will map to the no-popup state. (In spec terms, this is the missing value default.)
• Garbage value (e.g. foo) will map to the no-popup state, for forward compatibility. (In spec terms, this is the invalid value default.)

The question is what values should map to the popup state. I think the empty string should map to that state. That gives a nice DX, where the default behavior is expressed with just <div popup>. It has many precedents in other enumerated attributes: crossorigin, translate, hidden, contenteditable, and spellcheck are all cases where the empty string maps to some sort of "default useful state", and that default useful state is different than the missing value default.

Separately, you probably want an explicit non-empty string keyword to also map to the popup state. Let's call it popup, although per #491 both the state and keyword will probably be renamed.

There is another option, which is to just have the empty string be the only keyword mapping to the popup state. In that case the bikeshedding in #491 becomes much less urgent because the state name is a spec-internal concept and not part of the web developer-exposed interface. But all the example attributes I listed above have a non-empty string keyword as well as the empty string, and it's probably good to stay consistent.

[mfreed7]

Thanks for opening this issue @domenic. After listening to your arguments, I think I agree that it sounds like a good option to make <div popup> mean the "standard" popup, equivalent to <div popup={#491}>. There were some concerns expressed over something like myPopup.popup=true not working, but I think those are probably outweighed by the convenience of the shorthand.

One question: if we go this route, and recalling our resolution to only IDL-reflect valid values, what should this return?

myPopup.popup = 'invalid value';
myPopup.popup; //  ??? 

It would seem "bad" to return the empty string, since that would round trip unfortunately:

myPopup.popup = 'invalid value';
myPopup.popup = myPopup.popup;
myPopup.popup;  //  'popup' (or whatever #491 decides)

It seems like null or undefined would be appropriate, but thoughts appreciated.

[domenic]

For reflection, you have two choices in the current spec:

• DOMString attribute whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values
• nullable DOMString attribute whose content attribute is an enumerated attribute

The former seems like it would work well if you added a keyword for the no-popup state (e.g., popup=none). The latter seems like it would work well if you'd prefer not to do that.

We could also explore adding new reflection variations, but I'm not sure that'd be necessary.

[mfreed7]

The former seems like it would work well if you added a keyword for the no-popup state (e.g., popup=none).

I think this makes the most sense to me. There'll need to be an enum value (there already is in Chromium) that means "none", so let's expose it directly.

I'm going to add this to the Agenda for next week, since we just resolved to rename the main case to popup=auto. I'd like to get this one resolved also, so we can be done changing the popup attribute.

Proposed resolution: For the popup attribute, an empty string ("") value should map to popup=auto. Also add a specific attribute value, popup=none, which behaves identically to when the popup attribute is missing completely.

Any objections?

[zcorpan]

There's a third choice

• nullable DOMString attribute whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values

crossOrigin has this setup, and also has the empty string being a state that's different from the missing value default.

Limited to only known values is good for feature-testing, so IMO it's a choice between having none as a synonym to missing attribute and the IDL return none, or no synonym and the IDL returns null.

Returning null for the no-popup state and non-empty strings for the other states allows for truthy/falsy checks in JS, which seems a bit nicer in terms of developer ergonomics.

[domenic]

Simon, I can't find that in the reflection section for some reason... Is crossOrigin just not well specified? Otherwise, yeah, that does seem a bit nicer.

[mfreed7]

There's a third choice

• nullable DOMString attribute whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values

crossOrigin has this setup, and also has the empty string being a state that's different from the missing value default.

Limited to only known values is good for feature-testing, so IMO it's a choice between having none as a synonym to missing attribute and the IDL return none, or no synonym and the IDL returns null.

Returning null for the no-popup state and non-empty strings for the other states allows for truthy/falsy checks in JS, which seems a bit nicer in terms of developer ergonomics.

Ohh I like the third choice. I do agree returning null is nicer for truthy/falsy checks. Given that's a possibility, here's a new proposed resolution:

Proposed resolution: For the popup attribute, an empty string ("") value should map to popup=auto. The IDL will be limited to only known values, meaning it will return null for both invalid content attribute values and when the popup attribute is missing entirely. Do not add a specific attribute value meaning "no popup", e.g. popup=none.

[zcorpan]

@domenic I think it falls under

If a reflecting IDL attribute is a nullable DOMString attribute whose content attribute is an enumerated attribute, then, on getting, if the corresponding content attribute is in its missing value default state then the IDL attribute must return null, otherwise, the IDL attribute must return the keyword value associated with the state the attribute is in. If there are multiple keyword values for the state, then return the conforming one. If there are multiple conforming keyword values, then one will be designated the canonical keyword; choose that one. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value.

but indeed it seems like there's a spec bug since crossOrigin is defined to be "limited to only known values" but also nullable.

Searching for "attribute DOMString? " in the spec it looks like it's only crossOrigin that's affected currently.

[mfreed7]

If a reflecting IDL attribute is a nullable DOMString attribute whose content attribute is an enumerated attribute, then, on getting, if the corresponding content attribute is in its missing value default state then the IDL attribute must return null, otherwise, the IDL attribute must return the keyword value associated with the state the attribute is in. If there are multiple keyword values for the state, then return the conforming one. If there are multiple conforming keyword values, then one will be designated the canonical keyword; choose that one. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value.

but indeed it seems like there's a spec bug since crossOrigin is defined to be "limited to only known values" but also nullable.

I, perhaps incorrectly, assumed there was an implied "and the IDL attribute is limited to only known values" in that paragraph.

In non-spec language, here are my assumptions about what we want:

HTML	IDL
<div popup=auto>	div.popup === 'auto'
<div popup=AuTo>	div.popup === 'auto'
<div popup=hint>	div.popup === 'hint'
<div popup=async>	div.popup === 'async'
<div popup>	div.popup === 'auto'
<div popup="">	div.popup === 'auto'
<div>	div.popup === null
<div popup=foobar>	div.popup === null
<div popup=true>	div.popup === null
<div popup=none>	div.popup === null
<div popup=" auto "	div.popup === null

[mfreed7]

Would this look like the right WebIDL for the above table?

[Unscopable, CEReactions, Reflect, ReflectOnly=("auto","hint","async"), ReflectEmpty="auto"] attribute DOMString? popup;

There's no way to use ReflectMissing or ReflectInvalid since we want them to be null, not a string. Right?

[zcorpan]

The table looks right to me.

As for the WebIDL, Reflect and Reflect* are non-standard chromium extensions I believe.

The current spec text for reflecting nullable enumerated attributes says to return null for the missing value default state, but we also want to return null for the invalid value default state, so the definition needs some massaging to allow for that.

[mfreed7]

As for the WebIDL, Reflect and Reflect* are non-standard chromium extensions I believe.

Right, of course. Thanks.

The current spec text for reflecting nullable enumerated attributes says to return null for the missing value default state, but we also want to return null for the invalid value default state, so the definition needs some massaging to allow for that.

Is that something that seems easy to add to the spec? @domenic thoughts?

[domenic]

Yeah, it's easy to add, and in fact something we need to do because currently the spec for crossOrigin is broken. I plan to do that sometime this week.

[domenic]

So I tried to work on a spec edit here and it appears crossOrigin is already working OK. Basically it appears nullable DOMString enumerated attributes are always implicitly "limited to known values". Whenever you are in the missing value default state, then you get back null. So if you want to get back null for invalid values too, then just make sure your invalid value default is equal to your missing value default. (That is not what crossOrigin does.)

So for the table above I think you want the following spec:

• Enumerated attribute
• DOMString?
• invalid value default = missing value default = no-popup state
• No explicit keyword for the no-popup state

[mfreed7]

Great, thanks!

[css-meeting-bot]

The Open UI Community Group just discussed [Popup] The popup attribute should allow the empty string value, and agreed to the following:

• RESOLVED: For the popup attribute, an empty string (`<div popup="">`) value should map to `popup=auto`. The IDL will be limited to only known values, meaning it will return `null` for both invalid content attribute values and when the `popup` attribute is missing entirely. Do *not* add a specific attribute value meaning "no popup", e.g. `popup=none`.

The full IRC log of that discussion

<gregwhitworth> Topic: [Popup] The popup attribute should allow the empty string value
<gregwhitworth> github: https://github.com//issues/533
<gregwhitworth> masonf: last week we resolved to have popup=auto
<gregwhitworth> masonf: this was opened to allow a boolean like syntax
<gregwhitworth> you could just have popup="" or just popup
<una> q+
<gregwhitworth> masonf: that would mean the same thing as popup=auto, there is nice easy way to spec this
<gregwhitworth> masonf: in participation of this resolution I have implemented this
<gregwhitworth> masonf: curious what people think
<gregwhitworth> ack una
<JonathanNeal> +1 to `popup`/`popup=""` being the same as `popup="auto"`.
<gregwhitworth> una: I really like this
<gregwhitworth> una: do we still need popup="auto"
<JonathanNeal> q+
<gregwhitworth> una: do we still need it if we agree on this?
<JonathanNeal> ack Jonathan, Mason has what I was going to share covered.
<gregwhitworth> masonf: there is an IDL reflection, you get a string - it feels better to get auto rather than ""
<JonathanNeal> ack JonathanNeal
<gregwhitworth> masonf: it only reflects valid values and see if it is supported for feature detection
<gregwhitworth> una: I don't mean to open this bag of worms
<gregwhitworth> una: we use default in CSSWG
<JonathanNeal> In CSS, I think we do also use `auto`, e.g. `margin: auto`.
<gregwhitworth> una: we decided to not go with default but there seems to be more precedence for default rather than auto
<gregwhitworth> masonf: we did discuss this for CSS which means the "normal thing"
<gregwhitworth> gregwhitworth: +1 to having a boolean approach
<gregwhitworth> una: +1, I like just popup
<masonf> Proposed resolution: For the popup attribute, an empty string (`<div popup="">`) value should map to `popup=auto`. The IDL will be limited to only known values, meaning it will return `null` for both invalid content attribute values and when the `popup` attribute is missing entirely. Do *not* add a specific attribute value meaning "no popup", e.g. `popup=none`.
<gregwhitworth> una: we have this with checked and there are multiple values
<dandclark> Resolution LGTM
<gregwhitworth> masonf: this is an enumerated values/cases, so it's not pure boolean
<gregwhitworth> q?
<JonathanNeal> +1 to the proposed resolution. +1 to what Una said, too. I heart boolean attributes.
<masonf> RESOLVED: For the popup attribute, an empty string (`<div popup="">`) value should map to `popup=auto`. The IDL will be limited to only known values, meaning it will return `null` for both invalid content attribute values and when the `popup` attribute is missing entirely. Do *not* add a specific attribute value meaning "no popup", e.g. `popup=none`.

[emilio]

FWIW, I don't have permission to reopen, but it seems a bit more consistent to me to treat invalid popup values (like popup="blah") to be still a popup (just like the type="" attribute in <input>), probably with the default behavior of popup=""?

It seems a bit of a better default, specially if we implement new popup types in the future? <div popup="fancy"> will not show up at all on the versions of the browser that support the new attribute, but will be a regular element (or fixed-pos block as per #561), which seems really unfortunate / a pretty bad failure mode?

[mfreed7]

It seems a bit of a better default, specially if we implement new popup types in the future? <div popup="fancy"> will not show up at all on the versions of the browser that support the new attribute, but will be a regular element (or fixed-pos block as per #561), which seems really unfortunate / a pretty bad failure mode?

So the point of the existing behavior is forward compatibility, generally. The thing that worries me about making <div popup=foobar> behave like <div popup> is what happens if later we actually add popup=foobar as a supported value, with different behaviors? This will break the site, and if the breakage is large enough, we won't actually be able to ship popup=foobar.

Can I ask the flip-side question? Why do you want to support <div popup=foobar>? What's the use case?

[emilio]

So the point of the existing behavior is forward compatibility, generally. The thing that worries me about making <div popup=foobar> behave like <div popup> is what happens if later we actually add popup=foobar as a supported value, with different behaviors? This will break the site, and if the breakage is large enough, we won't actually be able to ship popup=foobar.

Just to clarify, your concern is (let's call this "scenario A"):

• Site uses popup=foobar before it is supported.
• Site gets popup="" behavior and carries on, because it works.
• We want foobar to do something else.
• Suddenly popup=foobar behaves differently, in a way significant enough. The site breaks.

Is that right? If I got that right, let's consider two other scenarios.

Scenario B:

• Sit uses popup=foobar before it is supported.
• Site gets the proposed "no popup" behavior and carries on, the div is just regular content, or a fixed-pos div.
• We want foobar to do something else.
• Suddenly popup=foobar becomes a popup, and gets hidden, with no code to show it in the site. The site breaks.

Scenario C:

• Site doesn't use popup=foobar.
• We want foobar to do something else.
• Site starts using popup=foobar, but developer doesn't test in old versions of browsers (or other browsers that don't support popup=foobar yet).
• Suddenly, in users of other or older browsers, page has a visible popup out of the blue, that users have no way of hiding without devtools.

Scenario B and C seem a bit worse to me that scenario A. In the (unlikely) case of A happening, we have alternatives (easiest one being "choose another string that's not in-use"), while B and C seem a bit less in our control, and worse for users.

Can I ask the flip-side question? Why do you want to support <div popup=foobar>? What's the use case?

Preventing scenario B and C, basically, which I think are worse than scenario A. But it might be the case that there's another scenario that I'm not considering.

I think there's value in consistently hiding all elements with [popup] by default (due to the popup behavior). That seems better, to incrementally hiding them as we add new values, which makes adding values not so trivial.

How bad B/C are depends a bit on how we expect authors to style popups. If we expect authors to effectively do:

[popup]:not(:top-layer) {
  display: none;
}

[popup]:top-layer {
  display: block; ...
}

Then the concerns are a bit less, I think (but then again, maybe we should put that in a UA sheet). When discussing #561, it was my assumption that authors would just style the element regularly:

#mypopup {
  display: flex;
  ....
}

And what would take care of controlling the visibility of the popup would be something along the lines of:

[popup]:-internal-popup-hidden { display: none !important }

in the user-agent sheet. But I see that's not the case (there's no !important there), so... how do you envision the styling for authors that want to style their popups with e.g. display: flex? Along the lines of what I wrote above (:not(:top-layer))? Something else?

[mfreed7]

You make some good points. I had been more worried about Scenario A, since it seems more likely to me. I.e. a developer who reads about the popup attribute, doesn't read the values, and just picks something that sounds right. If it happens to work, they keep it and move on. I suppose Scenario B (developer has never heard about the popup attribute, and uses it for their own purposes) is also possible. And Scenario C is a concern also, which I hadn't thought about.

I'm ok with making the Invalid Value Default equal to "auto", meaning popup=foobar behaves the same as popup=auto. In that case, feature detection is still possible, but slightly modified:

function supportsPopUpType(type) {
  const div = document.createElement('div');
  div.popUp = type;
  return div.popUp === type.toLowerCase();
}

Not as easy as a null check, but not terrible. This would also mean we could go back to a non-nullable DOMString for the .popUp attribute. @domenic, thoughts/objections?

Your other point about the missing !important is interesting. I did that on purpose, back when animations were troublesome, to make it easier to animate to/from the hidden state. I didn't think about this side effect that you cannot set display:{not-none} without also then having to do your own management of showing vs. hiding. Now that animations are handled, I'm inclined to say we should add back the !important to the display:none rule. (I'll comment on #561 to point to this conversation.)

[domenic]

That change makes sense to me. I wonder about the Invalid Value Default choice of manual vs. auto? Manual seems like maybe a better fallback behavior for "we didn't understand what you asked for", but that's just my first impression; I didn't analyze all of scenario A/B/C for each choice.

[mfreed7]

That change makes sense to me. I wonder about the Invalid Value Default choice of manual vs. auto? Manual seems like maybe a better fallback behavior for "we didn't understand what you asked for", but that's just my first impression; I didn't analyze all of scenario A/B/C for each choice.

Hmm, I tend to agree with this. I originally said we should default to popup=auto but I think that's just because that's the default for plain popup with no value. This is different, as you said, "we didn't understand". In that case, popup=manual confers just the basic pop-up behaviors (hidden by default, responds to .showPopUp, etc.) without all of the interactions with other pop-ups (via one-at-a-time behavior, etc.). That seems not only more correct in some sense, but likely also the safest for forward compat.

[mfreed7]

Seems like we might already be close to consensus. I'll put this on the agenda for next week.

[tbondwilkinson]

+1 to popup="manual" for cases where the attribute is unclear.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] The popup attribute should allow the empty string value #533, and agreed to the following:

• RESOLVED: Change the Invalid Value Default for `popup` to be `manual`.

The full IRC log of that discussion

<hdv> topic: [popup] The popup attribute should allow the empty string value #533
<hdv> github: https://github.com//issues/533
<hdv> masonf: we talked about this one several times in the past… current behavior is if you assign a value to `popup` attribute that is invalid, then it is invalid and will result in no popup behavior to happen, so it will be a normal element, but won't have popup behavior
<hdv> masonf: we have been discussing the standard UA stylesheet for a popup
<hdv> masonf: the proposal is: if you use any attribute value that is invalid for popup, you would get the popup=manual behavior
<hdv> masonf: this doesn't break feature detection, you could still do that and the issue has code for how to do it
<JonathanNeal> q?
<hdv> masonf: so I would like to change from not supporting invalid popup values to supporting them as if they were popup=manual
<hdv> JonathanNeal: any comments?
<masonf> Proposed resolution: Change the Invalid Value Default for `popup` to be `manual`.
<dandclark> Seems reasonable to me.
<JonathanNeal> I find it reasonable, as well.
<hdv> bkardell_: I thought this was an interesting discussion, I wanted to think about it but didn't have time for it this week
<hdv> +1 seems reasonable to me
<hdv> JonathanNeal: let me phrase it differently, does anyone have objections ?
<hdv> bkardell_: only that we spent a long time debating and got to the opposite conclusion, I would like to understand why that was wrong… it's pretty minor, but I would not want us to revert again
<hdv> masonf: I think when we discussed it the first time we were kind of learning together how these kinds of attributes work… having looked at it more it looks like it is actually possible to feature detect
<hdv> masonf: I can also add Domenic was one of the people pushing for the old resolution and he agrees now with the new one
<JonathanNeal> q?
<hdv> JonathanNeal: based on that, would you want to go ahead with resolution?
<hdv> masonf: maybe we resolve now and we can always revisit later?
<flackr> +1 to the proposal
<hdv> JonathanNeal: feel free to jump in anyone if you feel against this resolution
<masonf> RESOLVED: Change the Invalid Value Default for `popup` to be `manual`.

[scottaohara]

+1 to this as well. my only concern was that if manual would be the expected default behavior... but if someone is putting unsupported values into the attribute and they don't get the behavior they're expecting.... well... this will be a signal to them to check their values?

[mfreed7]

+1 to this as well. my only concern was that if manual would be the expected default behavior... but if someone is putting unsupported values into the attribute and they don't get the behavior they're expecting.... well... this will be a signal to them to check their values?

Right. I like manual for two reasons:

1. It is the "minimal" set of pop-up behavior. For an invalid value, it seems like we should do the minimum.
2. It feels like the most likely value to cause developers to realize that the pop-up isn't behaving as they expect, since it doesn't light dismiss or dismiss other pop-ups.