Re: [w3ctag/design-reviews] Element.isVisible review (Issue #734)

Sorry for the late reply.

Without considering existing features, I still believe that this function should be synchronous. The intended use-case for this feature is for the developer to check in the existing element with current styles for visibility to see if a further measurement is appropriate. Something like the following:

```js
if (e.checkVisibility())
  return e.getBoundingClientRect();
else
  return null;
```

The reason this pattern is useful is the way `content-visibility: hidden`, for example, works: if one just invokes `e.getBoundingClientRect()` and `e` is in a subtree of a `content-visibility: hidden` element then that will cause an update in an otherwise skipped subtree. The `checkVisibility` function, on the other hand, would only update the rendering while still respecting skipped elements, then can check that `e` is indeed under a `content-visibility: hidden` and return `false`

Having this function be asynchronous puts a burden on the developer to ensure that the function is either called in an async function with an await, or to restructure the 'natural' flow to account for the fact that the visibility check will happen at a future time. It isn't clear to me whether the guidance to prefer asynchronous APIs to avoid forced rendering updates should take precedence. It is my humble opinion that in this case it should not, and the function call should remain synchronous.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/734#issuecomment-1190494436
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/734/1190494436@github.com>