- From: Xiaocheng Hu <notifications@github.com>
- Date: Mon, 07 Apr 2025 04:46:38 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1043/2783047685@github.com>
xiaochengh left a comment (w3ctag/design-reviews#1043) Hi @ffiori, the TAG discussed it and still found our concerns unresolved. We understand that this API is the simplest solution to the target use case, but we are concerned with synchronous layout-performing APIs in general, and the introduction of another API in this class might not be the good way to go. 1. Synchronous layout-performing APIs, on their own, violates design principle [be synchronous when appropriate](https://www.w3.org/TR/design-principles/#synchronous): > An API should generally be synchronous if the following rules of thumb apply: > - ... > - The execution time is short and deterministic. 2. There's no way to reliably prevent layout thrashing caused by such APIs, as otherwise we wouldn't have invented Intersection Observer. 3. Consistency with existing layout-performing APIs does not justify the introduction of another one. We should [leave the web better than you found it](https://www.w3.org/TR/design-principles/#leave-the-web-better), and in particular: > Issues that are present with a certain web technology now may be fixed in a subsequent iteration. Duplicating these issues makes fixing them more difficult. By adhering to this principle we can make sure overall platform quality improves over time. For now we are closing this review. We still encourage the exploration of asynchronous alternatives, be it events, observers, Promises, ... -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1043#issuecomment-2783047685 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1043/2783047685@github.com>
Received on Monday, 7 April 2025 11:46:43 UTC