A bookmark answers “where?” A reusable source card should also answer “which version did I open, what was supplied, and what is still unknown?”
I built a small browser-side Source Card Builder demo around that distinction. It is an original JavaScript form example, with no external libraries or server submission in the demo code.
1. Model observation separately from verification
A populated form is not evidence that a resource is reliable. The output therefore keeps three different categories:
- Observed metadata: title, source URL, page type and access date.
- Optional attribution: author/reviewer, edition/translator/version and the update date displayed on the page.
- Reader work: an open question that still needs investigation.
Missing attribution is serialized as JSON null. It is not replaced with the site owner's name, today's date or a plausible version. An access date describes my visit; it does not describe the publisher's last update.
The demo always emits resourceVerified: false. That field is a boundary, not a score: generating a card has not performed any source verification.
2. Parse an address, then apply your own acceptance policy
The URL constructor provides parsing. It does not decide which protocols your application intends to accept. The source-card form uses an absolute URL and then rejects unsupported schemes and embedded account credentials:
function readSourceUrl(raw) {
const url = new URL(raw.trim());
if (!['http:', 'https:'].includes(url.protocol) ||
url.username || url.password) {
throw new Error('Use HTTP/HTTPS without embedded credentials.');
}
return url.href;
}
This is input-policy enforcement. It does not prove that the destination exists, that it is safe to visit or that its content is accurate. The demo does not fetch the destination. If a future server fetches user-entered URLs, that introduces a separate security problem requiring its own safeguards.
3. Treat the exported card as text
The output is rendered using output.textContent = JSON.stringify(card, null, 2). User-entered titles and questions remain text rather than being inserted as HTML. MDN's textContent reference explains the relevant DOM behavior.
A nearby live status region reports validation errors and successful generation. Required titles are trimmed; access dates are required. Supplied dates must match an ISO calendar date rather than simply looking date-shaped. Optional fields remain visibly unknown when the reader has not checked them.
4. Keep example metadata honest across domains
The three presets illustrate different questions using projects I operate:
- A market-dashboard guide prompts a reader to distinguish score from quality.
- A health-calculator directory prompts a reader to inspect an individual tool's purpose and limitations. The card does not assess clinical suitability.
- A poet and author directory prompts a reader to record a specific text and edition next. An index is not an attribution certificate.
None of these presets supplies an invented author, edition or update date. The point is the form contract, not an endorsement of every page reachable from a directory.
5. State what was actually checked
Six browser checks passed for the published demo: each of the three presets produced the expected URL with missing attribution preserved; a JavaScript scheme, an address containing account credentials, and a blank title were rejected. These checks cover those interactions, not a complete accessibility or security audit.
The demo code has no persistent storage or outbound submission. Its hosting platform may have its own analytics. Enter public resource metadata only; keep personal health details, account secrets and private trading records out of the form.
Disclosure: I am Ali Gürtuna, creator of AGProLabs and operator of the linked projects. This article and the original demo were prepared with AI assistance and reviewed against the published interface. They are technical examples, not medical or trading recommendations.
Top comments (0)