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.