Features that only make sense in one form factor should still be considered Baseline

[atopal]

Screen orientation lock is currently only available in Chrome on Android, and is therefore marked as not available in Chrome in the MDN banner, but even if it was supported in all mobile browsers, it would still not be considered Baseline according to our definition.

I suggest that we extend the definition to consider the form factor, and in cases where the feature is expected to be used almost exclusively used in one form factor, we consider the feature Baseline. That is in cases where developers don't have an expectation for a feature to work in another form factor, we don't state that the feature is not ready yet, as that would go against one of the goals of Baseline: Baseline status aims to identify features of developers’ contemporary, workaday web.

[foolip]

@ddbeck mentioned that he thinks this could be handled with editorial override. Trying to imagine what that would look like, there, I don't think there's actually some edit to screen-orientation-lock.yml that would have the intended effect. I've sent #1058 to show the information that needs to be conveyed, where N/A would mean "not supported and that's OK".

But do we want to do this per-browser, or divide the browsers into desktop and mobile and have something like relevant_on_desktop: false?

[foolip]

@LeoMcA until we can figure this out, would you mind suppressing the baseline banner for screen orientation lock?

[ddbeck]

When I mentioned that I thought this could be handled with an editorial override, I did mention that it would be blocked on #915. If we're going to do an override along the lines of "this doesn't make sense on desktop" then I think we also need a way to say something directly to explain to developers why they'd see both a Baseline status and partial implementation or unimplemented iconography together.

[captainbrosset]

Chiming in quickly on this. I do like the N/A approach demonstrated in https://github.com/web-platform-dx/web-features/pull/1058/files, but this should probably come with a note too.

I'm not as keen on separating desktop vs. mobile. I don't think this has the same chances of enduring the passage of time.

Something like:

name: Screen orientation lock
status:
  baseline: false
  support:
    chrome:
      value: "N/A"
      note: The feature doesn't make sense on desktop operating systems

feels both simpler and more flexible.

[captainbrosset]

Discussed in today's WebDX CG call (notes). Technically, we can already achieve this with editorial overrides. But having data to support this as proposed in the previous comment seems desirable.

[foolip]

HTML media capture is another feature to consider. For some reason it's only supported on mobile browsers, and it's always been like that. It seems like it could be supported on desktop platforms, so I'm not sure what to make of it.

[captainbrosset]

I looked for features that:

• either felt like they only made sense on one device type
• or were blocked from baseline status because they were implemented in desktop but not mobile, or vice versa.

I'll paste the list below, it may be incomplete, but probably covers most cases already. I'll also add a bit of analysis for each of them.
I'm afraid my conclusion is that there's no clear boundary between mobile and desktop, and we may need to make editorial override decisions for some of them to grant them baseline status even when they're not implemented on certain device types. And we may need to revisit these decisions as time goes by and new devices emerge, with new capabilities.

---

The list:

• WCO

  WCO only makes sense on desktop operating systems since it allows devs to hide the title bar of an installed app window. This concept doesn't (currently) translate on any other type of device.
  The feature is not implemented in Safari or Firefox anyway, so this isn't holding baseline status or anything. But showing Chrome Android as not supported makes no sense here.

• Cursor styles

  Cursor styles makes no sense on devices that don't actually display a cursor.
  It appears that this feature is marked as supported on Chrome and Firefox for Android anyway. But it's not supported on Safari for iOS, effectively blocking baseline high status for no good reason.

• wheel events

  Wheel events don't apply on devices that don't support scrolling with a wheel.
  It appears that this feature is marked as supported on Chrome and Firefox for Android anyway. But it's not supported on Safari for iOS, effectively blocking baseline status for no good reason, and since 10 years.

• touch events

  This is similar to wheel events, but the other way around. Touch events do not make sense on devices that don't have a touch screen.
  Firefox, Chrome, and Edge all support it, on both mobile and desktop because those browsers work on devices that have touch screens, whether they are mobile or desktop devices.
  Safari iOS supports the feature, but Safari desktop doesn't, effectively blocking baseline status. As of today, there are no versions of Safari for desktop that work on touch devices. Apple desktop/laptop computers don't have touch screens, but perhaps could in the future.
  Baseline status has been blocked for 8 years because of this.

• pointer lock

  There's no mouse cursor on mobile devices. This feature likely doesn't make sense on mobile devices.
  Safari iOS doesn't support it, effectively blocking baseline status since 8 years.

• fullscreen

  Unclear if fullscreen should work on mobile or not. Safari for iOS doesn't support it.
  Edit: given the answer and comments on this SO question, it seems like it should work on iOS: https://stackoverflow.com/questions/12822739/full-screen-api-html5-and-safari-ios-6

• autocapitalize

  This attribute only makes sense on devices that support virtual keyboards, so mobile in theory. It's still marked as supported on desktop versions of Chrome, Edge, and Firefox though. But not on Safari Desktop, effectively blocking baseline status.
  MDN says "It affects the behavior of [...] voice input", which makes me think this therefore applies to desktop as well.

• virtual keyboard

  This feature doesn't apply to devices that only have physical keyboards. Unfortunately this is a bit of a blurry line because desktop devices such as Windows devices with touch screens pop up a virtual keyboard when you tap on a text input field. This keyboard isn't a floating overlay, but instead does take actual space from the viewport, therefore making the API useful on both mobile and desktop devices.
  The feature is not supported on Firefox or Safari, irrespective of devices. And Apple has shared concerns with the API. Even if Safari implemented it, it's unlikely that it would do so on iOS, effectively blocking baseline for a feature that won't make sense on their device.

• window management

  This is implemented on desktop versions of Chromium browsers only.
  The feature is only relevant to devices that support multiple screens which, in theory, could be all devices (think of mobile devices connected to an in-car entertainment system such as CarPlay for example). However, the feature only makes sense for devices that have a windowing system which lets users arrange and move windows around, including between various screens. This is not the case for mobile devices, even if they're displaying content on multiple screens, at least currently.
  It's therefore very unlikely that the API would ever be supported on mobile versions of our core set browsers.

• device posture

  Although mostly targeted at foldable devices, there's no reason this API shouldn't also be implemented in all other devices types.
  It just shipped with Chromium (132).

• screen orientation

  Although primarily interesting for mobile devices, this also works on some laptop devices (e.g. I can switch the display orientation in Windows, and that does affect the value of screen.orientation.type in the browser).
  This API is marked as supported across all browsers already.

• screen orientation lock

  This prevents the automatic rotation of the screen. Since screen orientation is supported on both mobile and desktop, it could make sense for orientation lock to also be supported across both types. However, it's only supported in Chrome for Android, but not Chrome Desktop, likely because (at least currently) only mobile devices auto-rotate based on their physical orientation (on my Windows laptop, I can only do it via a setting, not automatically).
  This isn't a problem today because baseline is blocked by Firefox and Safari, but if/once they implement it, this is one of the features that shouldn't be blocked because Desktop isn't supported.

• orientation sensor

  This feature only makes sense on devices that have an orientation sensor. So holding up baseline status because the API itself is not supported on certain devices might not make sense. Like the previous one though, not a problem today because this isn't implemented in Firefox or Safari anyway.

• device orientation events

  This is a weird one that's supposedly been supported everywhere for a long time, but only partially according to caniuse.
  Some of the event types don't make sense on all platforms. But, since this is already baseline high, not much to worry about here.

[ADTC]

Hello, I found this because I find that MDN's baseline banner will blanket-consider Touch Events as totally unavailable on Safari which is incorrect and highly misleading to developers depending on baseline banners. I come here from my original issue: mdn/content#37736

Instead of baseline being simple "yes or no" (true or false) it should really be the following:

• Baseline widely available (true)
• Baseline widely available on desktop ('desktop')
• Baseline widely available on mobile ('mobile')
• Limited availability (false)

So the spec should change to support four states instead of two, and once the spec changes, then the MDN banner needs to change its rendering to show all four states.

The MDN banner's icon for each browser should also be in four states instead of two:

• a ✅ tick,
• a 🖥️ desktop icon,
• a 📱 mobile icon, and
• a ❌ cross,

which would correctly show when a feature is available on both desktop and mobile in a certain web browser even if it's only "baseline available" on mobile across all browsers.

[tidoust]

For each case, it may be useful to consider what breaks if an app uses the features while it's not supported. For example:

• wheel events
  Wheel events don't apply on devices that don't support scrolling with a wheel.
  It appears that this feature is marked as supported on Chrome and Firefox for Android anyway. But it's not supported on Safari for iOS, effectively blocking baseline status for no good reason, and since 10 years.

I don't think anything really breaks when wheel events are not supported:

• element.onwheel = function () {} should not throw. It just won't create a real event handler.
• apps should not rely on wheel events being emitted in any case

The only thing that would break is if the code called new WheelEvent() but I think we already concluded we would not be looking too much into event constructors, because they are useless in most common scenarios.

[...]

• pointer lock
  There's no mouse cursor on mobile devices. This feature likely doesn't make sense on mobile devices.
  Safari iOS doesn't support it, effectively blocking baseline status since 8 years.

Here, I suppose calling element.requestPointerLock() throws an exception on Safari iOS.

In the former case, it seems fine to say the feature is Baseline high, period. In the latter case, it seems important to call out that feature detection is recommended.

[atopal]

Thank you for compiling that list @captainbrosset It's so much better having actual features to discuss.

One additional thought here. The list is quite short, less than 20 items out of 1000 items, and in some of those cases the missing form factor is a non-issue. I'm thinking that given the scale of the issue we probably want to adjust the definition and the visualization appropriately and not make things significantly more complex for the other 98% of features.

[captainbrosset]

Given the low number, we could deal with this by overriding the baseline status manually, only for those few features. It would be nice, however, to have a real editorial_overrides_notes field of some kind to not only record our decision, but to communicate it to consumers of the data, in a machine readable way, as well.

[controversial]

There are some cases where marking these features as “baseline” can be misleading even if they “don’t make sense” on the platforms where they’re unsupported.

For example, code like

if (myEvent instanceof TouchEvent) {
  // ...
}

will throw a runtime error (“Can't find variable: TouchEvent”) on desktop Safari

Even though the “touch events” feature is “not applicable” to desktop Safari, the absence of the API can still cause errors

but I might be led to believe that this code is safe if I see that TouchEvent were given a “widely available” baseline

[ADTC]

It's @controversial ! (Sorry couldn't resist 😜)

That's a fair point. Indeed, that could be misleading too. And as I like to say:

Safari: Apple's "Internet Explorer"