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

> 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`

We had some trouble following this, how does making the API async complicate this use case?

> 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.

This applies to any async API, doesn’t it?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/734#issuecomment-1289275846

You are receiving this because you are subscribed to this thread.

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