- From: Sanket Joshi via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Apr 2021 06:20:18 +0000
- To: public-css-archive@w3.org
Summarizing a few approaches based on this thread to guide our vF2F discussion: Approach 1 (what is currently spec'ed): `Highlight` objects are constructed with a name, which guarantees that each highlight will have exactly one name. `HighlightRegistry` is a `setlike` collection of registered `Highlight` objects. Multiple independent highlights may be constructed with the same name, but only one can be registered at any time. To avoid duplicate registrations, the `HighlightRegistry.add` API compares the new highlight's name with all previously registered highlight names. If the name was previously registered, the API throws and fails; otherwise, the `add` operation succeeds. Approach 2: `Highlight` objects are not associated with a name at construction. Instead, they are given a name when they are registered. `HighlightRegistry` is a `maplike` that takes a highlight name as key and `Highlight` object as value. This approach allows the same `Highlight` to be registered under multiple names, which seems problematic because this allows a highlight to have multiple independent sets of styles and no way to prioritize amongst them (see previous comments in this issue for more details). Approach 3: Same as approach 2, but disallow registration of the same highlight under different two names by overriding the `HighlightRegistry.put` API. When registering a highlight, checks the values in the `HighlightRegistry` to see if the new highlight was previously registered. If the highlight was previously registered under a different name, throw and fail. Otherwise, the `put` operation succeeds. -- GitHub Notification of comment by sanketj Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5910#issuecomment-815482437 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 April 2021 06:20:20 UTC