Explore more conditional logic for `placeholder data` vs `input data` vs `desired output mark`

Open
  • Is something wrong?
#608 2 comments 0 reactions 0 assignees View on GitHub

@TechGenie-awake is already working on this.

Since Jan 20, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
css, html, javascript
Domain
frontend

Research direction

Start by tracing how placeholder data flows between the Attribution Fields and the Marking format areas. Compare the proposed clearing, field-disable, and output-exclusion alternatives, then define one behavior for omitted fields; done means users can leave a field blank without an erroneous placeholder appearing in the final marking statement.

Written by the indexing model from the issue text.

Description

✨ goal: improvement 🏁 status: ready for work 💻 aspect: code 🟩 priority: low

Problem

At present the default placeholder data does a good job of displaying a connection between information input into the Attribution Fields and the connected output in the Marking format areas.

This placeholder data is replaced by user input data when input. However, if a user would like to omit a field, that isn't currently possible.

Should a user wish to not include the date, they might leave it blank; but the placeholder data persists; which would then require them to input a correct date or get a final marking statement that includes an incorrect erroneous date.

Description

There are several possibilities to explore here, the primary one should likely consider clearing all placeholder data once a user inputs any data in any of the Attribution Fields. This would let the intuitive connection remain up until user input, and at that point all information that is not input would be cleared.

Alternatives

Other alternatives that could be explored would be some kind of disable mechanism on the fields themselves, or somewhere else in the interface.

There is also the possibility of not including the placeholder data in the marking statements at all, but this would decrease the binding of input fields to output tokens, which is strongly not desired.

There is of course the option of leaving as-is and that the forcing the user to input all the fields improves overall marking statements and that providing an option to include less data should be something people can do manually on their own and that the Chooser should support best-practices and not all possible use cases.

Additional context

There are likely other routes, this is just an exploration, so feel free to add further ideas in the comments.

Implementation

  • I would be interested in implementing this feature.
Dominant language
CSS
Stars
162
Forks
199
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from creativecommons/chooser

All issues in creativecommons/chooser

Similar issues

More Web Dev issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.