- From: Di Zhang <notifications@github.com>
- Date: Tue, 19 Nov 2024 14:54:15 -0800
- To: w3c/selection-api <selection-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/selection-api/issues/2/2486914569@github.com>
The slides were written quickly and don't have all the implementation details. Apologies and I will work on a spec PR soon that does include everything. The composed range is not computed on the fly. It is tracked by the selection. Overall, my proposal is as follow: In Selection API, we change the wording to say: "Each selection is associated with a single composed range." And in the DOM spec, we define what a composed range is: A **composed range** is the range associated with a selection. Its start and end share the same shadow-inclusive root. A **composed range** can be associated with a **[live range](https://dom.spec.whatwg.org/#concept-live-range)**. `1 Selection <=> 1 Composed Range` `1 Composed Range <=> 0 or 1 Live range` > I also don't really understand the slides unfortunately. They suggest that getRange(0) allocates, but I think the range stays 1:1 with the selection for the lifetime of the selection. And changes to the range are reflected in the selection and vice-versa. You could do some lazy initialization perhaps, but that would in fact be an implementation detail and would not need to be specified. I see your point. We can remove that implementation detail and leave it to the user agent. We can just say return the live range associated with the this's composed range. > Similarly the steps under what setBaseAndExtent() would do are confusing. First it updates this's composed range and then it replaces it? First, it updates the composed range. Then, it updates the live range associated to this composed range. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/selection-api/issues/2#issuecomment-2486914569 You are receiving this because you are subscribed to this thread. Message ID: <w3c/selection-api/issues/2/2486914569@github.com>
Received on Tuesday, 19 November 2024 22:54:19 UTC