Addressing github issues.#97
Conversation
|
|
||
| ``` | ||
|
|
||
| _Note Both ```addWords()``` and ```removeWords()``` are essential for this interface. We need ```removeWords()``` to retract mistakes, mirror user unmarks, or track evolving terminology, and prevent dictionary from growing unboundedly. |
There was a problem hiding this comment.
It's not especially clear why one needs to remove during the lifetime of a page, so it might make sense to mention something about single page applications or something. Otherwise I think the assumption is "if it isn't a term, just don't load it in the first place".
| ### 2. A Unified `CustomDictionary` Across Features | ||
| ### 2. A SetLike interface | ||
| <details> | ||
| For the interface, a natural alternative would be [SetLike<DOMString>], which auto-generates a complete Set-shaped surface, familiar to JavaScript authors, composable with standard set algebra. However, we chose not to use it because: |
There was a problem hiding this comment.
composable with standard set algebra
Setlikes don't support .union() and so on, more or less just the core stuff .add(), .delete(), has(), .clear(), .entries(), .keys(), .values(), [Symbol.iterator](), .size (readonly) - as far as I understand (and from looking at exiting stuff)
| <details> | ||
| For the interface, a natural alternative would be [SetLike<DOMString>], which auto-generates a complete Set-shaped surface, familiar to JavaScript authors, composable with standard set algebra. However, we chose not to use it because: | ||
|
|
||
| * Privacy. Exposing the read operations of the interface lets any script with access to the dictionary enumerate or probe its contents. |
There was a problem hiding this comment.
I wonder if we could just keep that shape but make those no-op? Like, .has() could always return false or something? The iterables are always empty? Bc it is really similar already - idk that it makes sense to argue for just "addWords" as opposed to "add"
| For the interface, a natural alternative would be [SetLike<DOMString>], which auto-generates a complete Set-shaped surface, familiar to JavaScript authors, composable with standard set algebra. However, we chose not to use it because: | ||
|
|
||
| * Privacy. Exposing the read operations of the interface lets any script with access to the dictionary enumerate or probe its contents. | ||
| * Batch shape matches caller intent and scales. SetLike's ```add(value)``` is single-element. In most common use cases, callers push lists, so on a SetLike surface they end up coalescing via forEach. Bespoke ```addWords(sequence<DOMString>)``` matches caller intent, batches cleanly, and remains a single operation. |
There was a problem hiding this comment.
This might be the strongest argument really
| ### 5. DOM subtree scoped | ||
|
|
||
| <details> | ||
| Choosing scope for the API largely depends on use cases. For example, Document-scoped is enough for whole-page vocabularies while subtree-scoped wins when multiple forms on one page need distinct vocabularies, or when web components want isolation. We would say that Document scope and DOM-subtree scope are not mutually exclusive — they compose additively. A subtree-scoped API with union-by-default semantics behaves identically to a document-scoped one when no element opts in. |
There was a problem hiding this comment.
Wait do they? Would you really want union-by-default? I think if you are making them subtree based they should be only that language.
| <details> | ||
| Choosing scope for the API largely depends on use cases. For example, Document-scoped is enough for whole-page vocabularies while subtree-scoped wins when multiple forms on one page need distinct vocabularies, or when web components want isolation. We would say that Document scope and DOM-subtree scope are not mutually exclusive — they compose additively. A subtree-scoped API with union-by-default semantics behaves identically to a document-scoped one when no element opts in. | ||
|
|
||
| We have a use case raised by client that requires a per-page vocabulary, which document scope handles directly. We propose to proceed with this first as it's a more conservative, easier-to-spec choice, and it leaves the door open for adding a partial interface HTMLElement later if multi-vocabulary scenarios emerge. |
There was a problem hiding this comment.
I don't know that this first sentence is relevant to the explainer really.
ziransun
force-pushed
the
github-issue-explainer
branch
2 times, most recently
from
e6b335f to
dcb8b46
Compare
ziransun
force-pushed
the
github-issue-explainer
branch
from
dcb8b46 to
41d74e4
Compare
2 participants
#93
#92
#91