@thehammer/template-verification 0.2.15 → 0.2.16
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +11 -4
- package/dist/components/VerifiedField.vue.d.ts +20 -0
- package/dist/context.d.ts +0 -9
- package/dist/style.css +1 -1
- package/dist/template-verification.js +289 -246
- package/dist/types.d.ts +56 -27
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -30,10 +30,17 @@ itself is two products fighting over one viewport — in a frame that cannot rea
|
|
|
30
30
|
any of the viewers the embedding app already has. Reviewing a value now happens
|
|
31
31
|
in that app, which opens the citation and the record beside the letter.
|
|
32
32
|
|
|
33
|
-
`initVerification` still **accepts** `saveOverride` and
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
33
|
+
`initVerification` still **accepts** `saveOverride` and ignores it. That is
|
|
34
|
+
compile-time compatibility for already-built templates, whose `App.vue` is
|
|
35
|
+
generated from a snippet that still passes it; it is not a feature. See
|
|
36
|
+
`src/context.ts`.
|
|
37
|
+
|
|
38
|
+
`detailUrl` was the same story until SG-689, when gpt-manager's wiring snippet
|
|
39
|
+
and its server-side sidecar both stopped emitting it — it is no longer part of
|
|
40
|
+
`InitVerificationConfig` at all. An already-built template's source that still
|
|
41
|
+
names it keeps building (the template build does not type-check) and keeps
|
|
42
|
+
harmlessly passing an unread property, same as before it had a name in this
|
|
43
|
+
interface.
|
|
37
44
|
|
|
38
45
|
## Install
|
|
39
46
|
|
|
@@ -84,6 +84,26 @@ import type { MetaCarrier } from "../types";
|
|
|
84
84
|
* back to full opacity with higher selector specificity than either hover
|
|
85
85
|
* rule, so a keyboard user tabbing to the mark while the pointer happens to
|
|
86
86
|
* be resting on the value still sees it clearly.
|
|
87
|
+
*
|
|
88
|
+
* ==== SG-693: THE DEFAULT SLOT RENDERS MARKDOWN, WHICH IS BLOCK-LEVEL ====
|
|
89
|
+
*
|
|
90
|
+
* The inline-anchoring contract above ("ANCHORING TO THE TRAILING EDGE OF
|
|
91
|
+
* WRAPPED TEXT") assumes `.tv-field-value`'s content is plain inline text
|
|
92
|
+
* flowing across possibly-several lines. The markdown fallback (see the
|
|
93
|
+
* template below) renders through danx-ui's `CodeViewer`, which is a `<div>`
|
|
94
|
+
* — block-level, not inline — wrapping a `<p>` (or `<ul>`/`<table>`/etc. for
|
|
95
|
+
* richer markdown). A `<span>` containing an in-flow block box gets split
|
|
96
|
+
* into anonymous block boxes around it per CSS2.1 §9.2.1.1, so the mark
|
|
97
|
+
* anchor no longer lands on "the end of the last wrapped line" the way it
|
|
98
|
+
* does for plain text — it lands after the whole rendered block instead.
|
|
99
|
+
* This is a real, deliberate trade-off, not an oversight: every real
|
|
100
|
+
* self-closing `<VerifiedField>` usage in the two in-scope templates
|
|
101
|
+
* (TPL-1/TPL-2 — see SG-693's investigation) is already the SOLE content of
|
|
102
|
+
* its own `<p class="dl-prose">` wrapper, never inline mid-sentence, so the
|
|
103
|
+
* mark simply sits at the end of that paragraph either way. A future caller
|
|
104
|
+
* that binds `<VerifiedField>` truly inline within running prose (not as a
|
|
105
|
+
* paragraph's only child) would see the mark detach from the trailing text
|
|
106
|
+
* for exactly this reason — worth revisiting if that usage shape appears.
|
|
87
107
|
*/
|
|
88
108
|
type __VLS_Props = {
|
|
89
109
|
source?: MetaCarrier;
|
package/dist/context.d.ts
CHANGED
|
@@ -42,15 +42,6 @@ export interface InitVerificationConfig {
|
|
|
42
42
|
* {@link ../lib/hostBridge.DataPointActivatedMessage}.
|
|
43
43
|
*/
|
|
44
44
|
workflowInputId?: number | string | null;
|
|
45
|
-
/**
|
|
46
|
-
* ACCEPTED AND IGNORED, for the same reason as `saveOverride` above.
|
|
47
|
-
*
|
|
48
|
-
* This was the Inspector dialog's lazy per-field detail endpoint. The
|
|
49
|
-
* Inspector is gone, and the embedder fetches a data point's citations and
|
|
50
|
-
* history against its own authenticated session rather than against a
|
|
51
|
-
* token-sealed url handed into an iframe.
|
|
52
|
-
*/
|
|
53
|
-
detailUrl?: string | null;
|
|
54
45
|
/** Seeds the overlay toggle ONLY when localStorage holds no prior value. */
|
|
55
46
|
defaultEnabled?: boolean;
|
|
56
47
|
/**
|