Problem

Presently the language of "deed" and "legal code" is output as part of the title styling of the page, and as such causes confusion as visitors may believe that they are part of the license title itself.

So rather than: CC BY-NC-ND 4.0

Individuals might believe the title is instead: CC BY-NC-ND 4.0 DEED or CC BY-NC-ND 4.0 LEGAL CODE.

Description

Current pages:

• deed: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.en, uses walkthrough-page context
• license: https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode.en, uses default-page context

Legacy versions:

• deed: https://web.archive.org/web/20230726193257/https://creativecommons.org/licenses/by-nc-nd/4.0/deed.en
• license: https://web.archive.org/web/20230723170747/https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode.en

Alternatives

As deed and legalcode are descriptor "meta info" they should instead be placed elsewhere, and styled differently from the title itself. The previous design did a better job of creating this delineation.

Additional context

The translations strings may present a challenge in trying to create a solution here.

To resolve this item, a working current state context for the deed and legalcode license-page contexts needs to exist to work from. That work is tracked here:

• #64

Implementation

• I would be interested in implementing this feature.

Description

Likely due to the image-mask applied to the identity logo via svg, the element lacks an appropriate focus indicator when the user navigates to it via the keyboard.

Reproduction

1. Tab through the focusable items, via keyboard
2. See that the logo does not get an appropriate default indicator similar to the other times (i.e. menu links)

Expectation

The logo should have the browser default focus indicator around it, or similar. Generally this would be a border/outline.

We want to keep the svg as a background image, while also correcting the :focus behavior, so that we can still control the color of the svg dynamically. This will likely entail adding/altering the html, likely the CSS, but we want to avoid the use of an embedded <img> here.

Resolution

• I would be interested in resolving this bug.

Description

A few of the VocabularyIcons are executable, but they aren't scripts or command binaries.

Reproduction

Clone repository and then:

find * -type f -perm +111

src/fonts/vocabulary/VocabularyIcons.ttf
src/fonts/vocabulary/VocabularyIcons.json
src/fonts/vocabulary/VocabularyIcons.woff

Expectation

Only scripts or command binaries should be executable.

Environment

sw_vers

ProductName:		macOS
ProductVersion:		13.2
BuildVersion:		22D49

Resolution

• I would be interested in resolving this bug.

Problem

The person-page context is missing the pronouns field from its list of possible rendered fields.

Description

The field needs to be output since it is accounted for in the styling, and is present within the stylings of the Index Project within vocabulary-theme and vocabulary

Implementation

• I would be interested in implementing this feature.

Description

Remove duplicate files (CODE_OF_CONDUCT.md, CONTRIBUTING.md) from the repository to ensure alignment with organizational defaults as outlined in GitHub Repo Guidelines.
Also, update the readme file.

Related to:
(creativecommons/.github#38)

Resolution

• I would be interested in resolving this bug.

Problem

We need a basic, stripped down Page implementation to build out any further "templates" or "contexts" from. The Figma designs offer a route for this and some flexible considerations at large.

Implementation

• I would be interested in implementing this feature.

Description

• The current expand menu button lacks appropriate JavaScript to make it expand the primary navigation menu when it is toggled during a smaller screen responsive state.
• The expand menu button lacks appropriate vocabulary adjacent visual styling
• Button needs to avoid being an icon alone for the sake of adequate UX.

Resolution

• I would be interested in resolving this bug.

Problem

An overarching tracking ticket to keep . (In Draft)

Partials Templates

  graph TD;
      Partials-->all-templates
      all-templates-->Header
      all-templates-->Footer

Page Context Templates

• #16
• #17

  graph TD;
      Templates-->Index;
      Templates-->Default;
      Templates-->Search;
      Templates-->Archive;
      Templates-->blog;
       blog-->blog-Index;
       blog-->blog-Post;
       blog-->blog-Archive;
      Templates-->people;
      people-->Team-Index;
      people-->Team-Person;
      Templates-->Program-Project

Implementation

• I would be interested in implementing this feature.

Problem

Multiple people have asked where the translations went on the CC legal tools. They used to be listed in the content with all languages visible at the bottom of the page, now they are in a drop-down selector at the top of the page.

Description

We should investigate ways to increase the visibility of the languages drop-down selector and/or consider a temporary reminder in content that it is there.

Alternatives

🤷🏻

Additional context

Current screenshot

• green box added
• (https://creativecommons.org/licenses/by/4.0/)

Old screenshot

• green box added
• (https://web.archive.org/web/20230926010849/https://creativecommons.org/licenses/by/4.0/)

Related links

• CC Legal Tools
  • creativecommons/cc-legal-tools-app
  • creativecommons/cc-legal-tools-data

Implementation

• I would be interested in implementing this feature.

Description

The footer links are mostly placeholder #, and need to be set to appropriate baseline URLs. Where possible they are absolute for ones that would likely not change between implementations (social, license, etc.), and relative for situations where it makes more sense for localized implementation (footer navigation)

The footer navigation is set to default to creativecommons.org localized items, whenever implemented should opt for relative links for in-site navigation.

Implementation

• I would be interested in implementing this feature.

For privacy reasons, many people block webfonts loading from Google.

We should move any resources we want to load to ccstatic.org

Problem

The license pages are not included as contexts within index-prototype, and cannot be tested against reliably.

Description

At current the license pages for the legal code and the deed pages are stylized, but are variants of, existing contexts with hyper localized stylings of their own.

html:

• deed: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.en, uses walkthrough-page context
• license: https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode.en, uses default-page context

css:

• base.css: https://github.com/creativecommons/cc-legal-tools-app/blob/3bc446c0343733506f8cd54ca1173654b8cdfac6/cc_legal_tools/static/cc-legal-tools/base.css
• deed.css: https://github.com/creativecommons/cc-legal-tools-app/blob/3bc446c0343733506f8cd54ca1173654b8cdfac6/cc_legal_tools/static/cc-legal-tools/deed.css
• legalcode.css: https://github.com/creativecommons/cc-legal-tools-app/blob/3bc446c0343733506f8cd54ca1173654b8cdfac6/cc_legal_tools/static/cc-legal-tools/legalcode.css

Despite the use of existing contexts, there are several sub-elements and stylings which do not pull from vocabulary core at this time. Neither page exists as a context within this repository, but should. For now, work should start here, and after being finalized it might be possible to generalize it back to a vocabulary core context, for now, it's existence as production markup+styling without a corresponding index-prototype context is out of process, and difficult to both build for and test.

This should be either:

• one generalized local context, such as: license-page
• two similar, but distinct local contexts: deed-page, legalcode-page

Alternatives

There is also a case that this should be a possibility within a robust enough walkthrough-page context, but it does not fully exist yet.

Implementation

• I would be interested in implementing this feature.

Description

When we open https://creativecommons.org and when we zoom out to around 25% there are extra texts appear on the left side of the screen, which are useless

Reproduction

1. Open https://creativecommons.org
2. Zoom out to around 25%
3. See error

Screenshots

Bug:

Expectation

The extra text should not be there.

Environment

• Device: Desktop
• OS: Windows 10
• Browser: Chrome
• Chrome Version: 122.0.6261.95 (Official Build) (64-bit)

Resolution

• I would be interested in resolving this bug.

Description

The Global links in the header need to be set to baseline URLs, rather than placeholder #. There's an argument to be made they should be absolute URLs, so the "Explore" panel items can be the same across use-cases, and not need to account for the relative locality of their implementation environment.

The primary navigation is not covered by this Issue, and should remain placeholder for the time, but whenever implemented should opt for relative links for in-site navigation.

Implementation

• I would be interested in implementing this feature.

Description

The vocabulary.css file could benefit from some level of @layer implementation so that it has its own cascade layer within the bigger stack, and any localized overrides would be more easily done with less specific selectors. It also may allow for easier and more flexible expansion of styles without unruly collisions over time.

Implementation

• I would be interested in implementing this feature.

Description

Favicon not present on website.

Reproduction

1. Go to website
2. See error.

Expectation

There should be a favicon.

Resolution

• I would be interested in resolving this bug.

Description

At current the Newsletter form (an input box, and a submit button) lack the appropriate styling to match with the Figma designs. This should be corrected by drawing from any existing implementation styles and/or drafting new style rules.

Screenshots

Additional Context

The width span of the form itself will likely extend to the full width of the "center column" present in the footer, something the original Figma designs did not adequately account for, and would be an intentional modification.

Implementation

• I would be interested in implementing this feature.

Problem

At present, our product logos are implemented with a graphic, rather than inline text. This makes changing them or making "new" ones difficult and time consuming. Additionally, the graphics do not utilize Accidenz Commons.

Description

Creating a sample Type Specimen using contenteditable will enable a pre-styled product "logo" type area to utilize Accidenz Commons, typeset to match existing Figma product logos of the same.

A user can load the specimen page, doubled click the logo area, and input any text the would like to test the implementation.

Current Figma mockups of Product logos utilizing Accidenz Commons

Additional context

• creativecommons/tech-support#999 (private repo)

Implementation

• I would be interested in implementing this feature.

Description

The singular Blog post/article needs to be setup with semantic html, and appropriately styled design to meet the current needs informed by both the Figma designs and contemporary alterations for current usecases.

Will need to account for the follow featureset:

• multi-author byline
• categories, tags, etc.
• publish date (de-prioritized)
• images within content
• image caption + attribution baseline
• TBD

Implementation

• I would be interested in implementing this feature.