Update security terminology to emphasize curated output approach

[Copilot]

Documentation used blocking/blacklist terminology when describing security features. The library implements an allowlist architecture where only a curated set of safe tags and attributes are recognized—like Rolls Royce selecting quality materials rather than rejecting unsuitable ones.

Changes

Updated terminology across documentation files to accurately reflect the curation model:

• Tag/attribute restrictions: "Blocked" → "not recognized" / "not on the allowlist"
• Pattern enforcement: "Dangerous patterns blocked" → "Examples of patterns not recognized"
• Protocol validation: "Dangerous protocols blocked" → "Examples of protocols not recognized"
• Security approach: Emphasizes "curated output" and "curated set" of safe elements
• Exception: Prototype chain properties remain "blocked" (accurate - they ARE actively prevented, not simply absent from allowlist)

Files Modified

• spec.md
• README.md
• docs/index.md
• nodejs/packages/markdown-it-treebark/README.md

Example

Before:

**Blocked tags:**
- `script`, `iframe`, `object` - XSS vectors

**Dangerous protocols blocked:**
- `javascript:` - JavaScript execution blocked

After:

Only a curated set of safe HTML tags are recognized.

**Examples of tags not on the allowlist:**
- `script`, `iframe`, `object` - XSS vectors

**Examples of protocols not recognized:**
- `javascript:` - JavaScript execution not recognized

The updated language emphasizes what is curated and selected rather than what is rejected. Unsafe elements aren't evaluated and blocked—they're simply not part of the consideration set. The security model is one of careful selection, not rejection.

Rationale

The distinction matters: In a true allowlist model, dangerous elements like <script> aren't "rejected" (implying they were considered and refused). They simply aren't on the curated list of recognized elements—they never "get a ticket" in the first place. This philosophical difference is now reflected in the documentation.

Original prompt

There's a few places is some of the readme's and specs that say "block" when referring to security. I actually think the idea behind this library is an even more secure approach then "blocking/blacklisting" because it's more "handpicked/whitelisting".

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[danmarshall]

@copilot I (personally) don't even think of "rejection" - as in "you came but i didnt let you in" but more of "i didnt even mail you a ticket".

[Copilot]

@copilot I (personally) don't even think of "rejection" - as in "you came but i didnt let you in" but more of "i didnt even mail you a ticket".

Updated in 9ed538e. The terminology now emphasizes that Treebark produces curated output - like Rolls Royce starting with select quality materials, not considering bubblegum in the first place.

Unsafe tags/attributes/patterns are now described as "not recognized" rather than "rejected" or "blocked", since they never make it to the evaluation stage.

Exception: Prototype chain properties (constructor, __proto__, prototype) remain "blocked" since these ARE actively prevented - they would otherwise be accessible but are explicitly stopped.