On Tue, May 21, 2024 at 9:39 AM Raphael Kubo da Costa <raphael.kubo.da.co...@intel.com> wrote: > > Op 17-05-2024 om 16:59 schreef Philip Jägenstedt: > > What will be the behavior on Android, will the API appear to work but > > never invoke the observer callback? If so, would it make sense to > > disable the feature on Android instead? > > I'd just like to check if there's a general guideline for cases like this. > > On Android, calls to observe() will reject with NotSupportedError, which > I thought was fine. Does it mean that when a given API is not expected > to be implemented for a certain OS it is better to avoid exposing its > surface altogether, even if the binary size doesn't change as a result?
I don't think we have written guidelines, but my rule of thumb would be to hide the whole API. This is what happens when there's a runtime flag in the IDL and it's enabled for some platforms and disabled for others. Exposing the API makes feature detection harder, and makes idlharness.js tests pass for a feature that doesn't work. An exception to this would be when some API is supported on most/all browsers and not exposing it might be a site compat risk. But this isn't the case when we first ship a feature, it's something we might see when wanting to remove an API and outright removal would break too much. Best regards, Philip -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYc_QviycC_U6B99bZJWrPoX_5QnPTWtHHyWC7Fb6VSkzg%40mail.gmail.com.
