@plinss and I took a look at this during our virtual f2f today.

We think that a boolean argument (popup=0 or popup=1) is not extensible, if in the future authors want to select between more than these two kinds of window UI, whereas a keyword-based argument (e.g. type=popup) would not have this problem.

As a side point, this sentence in the explainer was unclear:

The window.open() API is currently confusing to use, in terms of trying to get it to open a popup vs. a tab/window.

until I read this section on MDN:

Most modern browsers (listed below) don't allow web content to control the visibility of UI parts separately. [snip] UI-related items of windowFeatures are used as a condition to whether opening a popup or a new tab, or a new window, and UI parts visibility of each of them is fixed.

Furthermore, we understand that this method has a long history, but if it were designed today we would strongly recommend using a dictionary instead of a serialized string that has to be parsed and re-serialized, see: https://github.com/w3ctag/design-principles/issues/213. It may be worth considering allowing users to pass a dictionary in place of this string for future enchancements, similarly to what was done for addEventListener().

We generally encourage people to seek feedback before features have already shipped in browsers. Given that this has already shipped in both Blink and Gecko, it seems too late to have any of our feedback taken on board. Therefore we're closing this issue, feel free to ping us if there's anything further to discuss.

Thanks for the review! I agree that it would have been better if this was brought to the TAG earlier. (I am merely the humble Chromium implementer - this change was primarily driven by others.) I do tend to agree with you that type=popup leaves more space for changes later. Though... this was discussed. It was proposed here on the issue, and then there was a discussion on the spec PR that resulted in the spec editors both agreeing that a boolean was better. I think the primary rationale was that a boolean was more parallel to the other recent additions to windowFeatures, such as noopener, noreferrer, etc.

I will post a heads-up back to that thread, pointing here, in case people want to take some action!

I think everyone likely agrees with you that a dictionary would have been better than the serialized string for windowFeatures, but that ship sailed a very long time ago.

Thanks again for the review!

@mfreed7 We know that the serialized string has a long history, our point about the dictionary is that it's not actually too late to change that. The method could take either a string or a dictionary for that argument, like how addEventListener was extended to take a dictionary or the legacy boolean. New features, such as this one, could possibly be restricted to the dictionary to help incentivize people to modernize their code (especially anything that would require extending the micro-syntax). Too late for this feature, but food for thought for the next one.

Ahh very good point! Sorry I missed your point the first time. I brought up the point about type=popup on the issue thread, so I’ll also toss this one over there too. This was a recent change, so it’s possible there’s still room to change. But if not, yeah, next time. Thanks again!

I proposed such a redesign of window.open() in https://github.com/WICG/conversion-measurement-api/issues/130#issuecomment-819784281 (for a different feature) but @annevk wasn't very interested, and instead suggested continuing to use the features string.