bikeshed: window.getScreens().screens is an odd naming pattern

[quisquous]

Feedback from @cterefinko. It looks like all of the examples call the value that getScreens() returns to be screensInterface to avoid saying screens.screens. Maybe there's a better name for getScreens?

[quisquous]

Also mentioned on the tag review: https://github.com/w3ctag/design-reviews/issues/602#issuecomment-792919351

[michaelwasserman]

Here are some notes I took during API design sessions aiming for more consistent and reasonable naming. I added @kenchris's ScreenDevices suggested alternative interface name from the TAG review too.

• Screen{Device,Detail,Configuration,Info[rmation],Space}[s], Display*?
• getScreens(): getScreenConfiguration(), getScreenInformation(), getScreenDetails(), getScreen()
• Screens: ScreensData, ScreensDetails ScreenConfiguration
• ScreenAdvanced: ScreenAugmented, ScreenExtended, ScreenWithExtendedInfo[rmation], ScreenInfo[rmation], ScreenDetails, ScreenSupplement[al], ScreenAugment, ScreenAddition[al], ScreenExtension, ScreenExtra, ScreenConfiguration, Display
• isExtended: isOnlyScreen (how to resolve a single mirrored screen?), isExtendedScreenAvailable

I could try to add more color to all the options, but I generally believe that a getScreens() function, a Screens interface, and a screens FrozenArray member are reasonable, despite the minor potential awkwardness of code like (await getScreens()).screens or let screens = await getScreens(); let myScreen = screens.screens[0];, etc.

[kenchris]

I like getScreenDetails().screens - makes a lot of sense

[michaelwasserman]

Thanks for the feedback here, we'll make this change soon, and may rename some interfaces in tandem:

• Screens -> ScreenDetails
• ScreenAdvanced -> ScreenDetailed?