The Storybook that has been set up in the project uses the old Storybook configuration syntax consisting of config.js and addons.js. With the new release, Storybook is moving towards a new syntax with the old one to be deprecated and eventually discontinued.

The goal is to implement the new syntax so that there are no issues in the future.

Description
Currently, there are no instructions available to translators for how to add new translations to Vocabulary.

Problems solved
Lowers barriers for new translations to be added.

Vocabulary has now been split into two repositories:

• style-only library named vocabulary
• Vue component library named vue-vocabulary

This split has left us with rampant misnaming throughout the project, in the HTML titles, in copy texts, in documentations and in links. These mistakes must be resolved going forward. That is the goal of this issue.

Currently in a lot of places, the box-shadow color is set to $color-tone-near-white which looks stunning on white backgrounds but not so much on black backgrounds.

This can be reproduced by replacing the hardcoded color value with a CSS variable using the color palette architecture used in the components.

The shadow should be $color-tone-near-white on white/light background and $color-tone-near-black on black/dark background.

This change only applies to component that implement the mixin Raisable.

The Navigation components looks quite terrible when the number of NavigationLink children are more than the screen can handle. This can be seen by increasing the number of links in the navigation to a large number and is particularly easy to spot on tablets in portrait orientation.

Designing a better navigation bar is a pressing concern, in light of #16.

Description
CC currently manages translations for our Deed and Chooser pages through Transifex. We'd like to move towards managing all translations through Transifex. We should manage Vocabulary translations there and automatically sync new translations.

Problems solved
Consistent translation infrastructure, better access to translators.

Additional context
This issue will require design work before coding starts to ensure that we have our Transifex settings set up right.

Description
Even on a fast Internet connection the styleguide takes a long time to load. While this is understandable, given that the whole documentation for every component in every variant is a single bundle, it is not acceptable.

Reproduction
Just open the styleguide with the cache cleared or disabled using developer tools (F12) and you can see this firsthand.

Expected behavior
The styleguide should load faster, splitting code on a per component or per family basis.

Additional context
Vue Styleguidist has a codeSplit option that might help (although definitely not solve the issue).

Currently locale change is restricted to current page. As soon as page reloads, locale reverts to the default, which is 'en'.

Describe the steps to reproduce the bug

1. Open an page powered by Vocabulary.
2. Change locale.
3. Navigate to a different page.

The locale is supposed to remain the chosen one. But it reverts to the default one. This is because the locale is never given any form of permanence. The goal is to write the chosen locale to the local storage and read from there on every reload. This will allow the locale change to persist across sessions and reloads.

Description
The CC Search browser Extension uses the following cdn for vocabulary styles https://unpkg.com/@creativecommons/[email protected]/css/vocabulary.css

It is not working and thus the styles in the production version of the extension are not rendering. This is a problem because even if we change the CDN link with an updated one and push a new version of the extension to the store, it will take more than a week to pass the evaluation process of the various browser extension stores

Reproduction

• Open the options page of the CC Search extension.

Expected behavior
The full options page must be rendered with Vocabulary styles.

Screenshots

A long text file is a poor way to show all variants of a component. Especially given that all these variants can also be applied simultaneously in any permutation.

An interactive playground where toggles can be turned on/off and variants can be chosen from a list of checkboxes would make it easy to mix and match and overlay variations.

This is offered to some extent by Storybook, but integrating it with Styleguidist is not straightforward. Also I'm inclined towards presenting this interface within the style guide rather than another completely different ecosystem. Storybook has a documentation system coming up so that might bridge the gap or replace Styleguidist entirely.

Anyway Storybook does have some features that Styleguidist lacks (you have to type out code snippets to see them in action, no UI or knobs) so initiating it is nevertheless a step towards the positive direction.

Currently the CSS being bundled by Webpack has a problem. The entire CSS is bundled into one giant vocabulary.css file that must be imported in an all or nothing fashion. That's not good for a component library that prides itself on flexibility and customisability.

The goal is to be able to provide piecewise CSS files and, optionally, also Stylus files on a per component basis in order to be able to better serve the needs of people who are using only a small fraction of the giant library and don't want to bear the burden of all the unused code.

Description
Although added to Storybook, the addon for viewports has not been configured and therefore only presents limited viewport options that are not the most illustrative of the features offered by Vocabulary.

Expected behavior
The addon should offer a richer selection of screen sizes and devices.

Additional context
The documentation for the addon describes the steps to define a new viewport: https://www.npmjs.com/package/@storybook/addon-viewport

Currently controls have been independently styled and are therefore very disparate in terms of their dimensions. So placing these components adjacent to each other leads to a bad look. The goal is to ensure that components have consistent dimensions, mainly heights but also, if possible, widths.

Describe the bug

https://opensource.creativecommons.org/cc-vocabulary/styleguide/ does not link to the GitHub repository

Emoji can only improve an app or library. There is currently no emoji support leading to inconsistent output across browsers.

The simplest example is this different output.

This inconsistency in the output (interestingly, even within the browser) is a major frustration. Clearly, leaving the rendering to the browsers' default is not ideal. An alternative is to agree upon an emoji font, deploy it across browsers and operating systems.

Here are some resources to get started:

• Twemoji
• Twemoji Awesome

The goal is to integrate Twemoji (or another competent emoji library) into the project.

Description
Link for interactive storybook is broken.

Expected behavior
Interactive Storybook link should open

Description
All styling applied to the ProgressBar component vanishes in Google Chrome.

Expected behavior
The styling that appears very nicely in Mozilla Firefox should also work in Google Chrome.

Screenshots

^ Progress bars in Google Chrome

^ Progress bars in Mozilla Firefox

Conditions:

• OS: Linux
• Browser: Google Chrome
• Version: 78

Description
While Vocabulary is a Vue package, not all usages of Vocabulary are or will be. This means that the vanilla CSS distribution of Vocabulary will end up being widely used. This means that the templates that Vue was writing on behalf of the developer will now have to be written by the developers themselves. Some especially complicated ones (such as the footer) are too nested to be written by hand and must be simplified as much as possible.

This essentially means minimising the amount of nesting and the number of classes in use in templates across Vocabulary.

Problems solved
Have a flatter DOM structure makes it easy to manually do the work that Vue templates were doing when using Vue. The goal is to simplify the DOM in components as much as possible.

Currently the component Navigation and it's children NavigationLinks only support single level navigation. This is quite restrictive because a number of sites, particulary those of Creative Commons, do have multi-level navigation.

The goal is to make it so that NavigationLinks be capable of being nested, leading to a navigation tree structure instead of a list.

Currently Vocabulary has been designed only with left-to-right layouts in mind. While this is acceptable for most languages, a number of languages, notably Arabic, are written right-to-left (RTL).

Support for RTL layouts is a crucial part of internationalisation and cannot be overlooked. The goal is to incorporate support for RTL layouts into the framework integrated with Vue-i18n so as to automatically switch to RTL whenever the active locale calls for it.

Description
Sites using Vocabulary as vanilla CSS need to know the ideal structure for HTML so as to appropriately style the components with Vocabulary CSS. This should be presented along with Vue code samples within the style guide itself.

Problems solved
This would enable sites not using Vue to effectively integrate with Vocabulary.

Describe the feature
I think it could be useful to allow popovers when hovering on the LicenseIconography icons! This could be enabled with a prop. I also think it would be a good idea to allow users to pass the contents of the popover for each icon with some object as a prop for more customization as well.

I think that something like this would look good, in terms of style.

Describe any problem solved by the feature
For explanatory/ educational sections involving icons in the cc chooser, I would like users to be able to hover on an icon and be able to get more information about it.

Want to take up?
I could help out, but I'm not sure how much time I'll have to work on it :)

Currently the roundness of any component is governed by two Boolean props, namely isRounded and isPill provided by the Roundable mixin.

Having two Booleans governing one aspect of a component is never ideal, much less so when the pill and rounded styles are just varying intensities of the same property.

A better approach to this is to have a String prop roundness in the mixin that can take the values rounded, pill or any other level of simplicity that could come in the future.

This change requires a round of refactoring across all components and their documentation.

Currently only one or two components have test coverage. This is abysmal, but hopefully understandable given the time-constrained nature of the Summer of Code program under which the library was developed.

This inadequate test coverage has prevented new features from being developed freely because of the looming fear of unknowingly breaking functionality somewhere down the line. The solution is to write tests for all components (from elements to templates).

This is a good way to get familiar with the codebase and get an in-depth introduction to the components. Completing this will also enable us to set up continuous deployment of the library to npm and of the styleguide to GitHub Pages.

Description
Making a framework out of Vocabulary means supporting more than just Vue.js. The first step towards that is having a pure-CSS framework that is tooling-agnostic with a Vue component library merely wrapping over it.

Problems solved
This, in conjunction with #71 and #70 would make Vocabulary independent of Vue.js and integrable into many other CC sites that use WordPress or Lektor or something else.

The ChoiceField component CSS is broken on iOS 12.

This screenshot of the styleguide was taken on Safari on iOS 12.4.

As a library of components with far-reaching scope of use, accessibility is an important aspect of the project that has unfortunately been overlooked due to the time-bound nature of the project's inception under GSoC program.

The goal is to develop a system to validate every components compliance with various accessibility guidelines. Storybooks does have an a11y addon that could help with this and potentially tie in to issue #6.

References:

• ARIA on MDN
• W3C WAI
• WCAG on W3C

Currently all files produced by the build:library task are poured directly in the dist/ directory without any hierarchy or organisation. This causes a lot of clutter and confusion. The goal is to devise a simple folder structure so that the build output is easier to understand and maintain.

Describe the feature

The Styleguide does not define components (ex. Footer).

https://opensource.creativecommons.org/cc-vocabulary/styleguide/#/Patterns/Footer only shows <Footer />. How Footer is defined is not shown (ex. which tone is used).

Currently the Header component uses a weird combination of flex grow and shrink to position elements in a split layout. However MDN suggests a cleaner way under the section 'Alignment and auto margins' in this article.

Using this approach will greatly increase the code quality and remove a lot of assumptions, quirks and hacks under the hood.

Instead of having a docs/ directory in the codebase that must be manually updated by running

npm run build:documentation

we should use a service such as Zeit or Netlify to continuously build and serve the docs whenever new commits are pushed to the branch master.

Description

When visiting the Pattern section of the site the sidebar disappears and allows the main content of the page to fill up the entire screen. Unfortunately this effect does not reset properly causing the main content to be a bit off after leaving that section and going to another.

Reproduction

When visiting the Pattern section of the site the sidebar disappears and allows the main content of the page to fill up the entire screen. Unfortunately this effect does not reset properly causing the main content to be a bit off after leaving that section and going to another.

Expected behavior

the main content should adjust with the sidebar or at least give you and option to hide the sidebar at all times.

Screenshots

Additional context

Want to take up?

[No]

Vocabulary currently has no meta tags for SEO and for rich-snippets in social media posts. The goal is to add meta tags for the homepage, storybook and styleguide. This has some negative impact as it makes sharing the URL to the project unappealing.

Currently the icon, iconList and iconSet props in many components accept just a String that is automatically mapped to the fas subset of FontAwesome icons.

Any deviation from this icon set must be achieved by populating the respective add-on slot housing the icon. This can get cumbersome and unnecessarily verbose.

A viable alternative would be to allow passing each icon either as a String (that is programmatically mapped to ['fas', icon]) or as an array listing the subset and the icon name.

This approach would also simplify template declarations of FontAwesomeIcon components
as this functionality is implemented in the FontAwesomeIcon Vue component itself).

<FontAwesomeIcon :icon="icon"/>

The footer currently shown on the styleguide says

"Generated with Vue Styleguidist"

which isn't helpful at all. A better footer is needed which is more informative.

I particularly like the footer of the Carbon design system.

Our own Footer component is pretty cool too.

This would also resolve #43.

The Trail component breaks down when the text in a TrailCrumb instance is too long. The crumbs should wrap, scroll or nest.

To reproduce, just create a Trail with a very long TrailCrumb child.

Here is an example of a broken Trail.

Description
The newly developed component Popup is a wrapper on Section and therefore lacks the traditional pointing arrow associated with components of this nature.

Problems solved
A popup with an arrow clearly points to the component that the popup is for. This is especially useful if the popup spans multiple lines vertically or multiple words horizontally.

Alternatives
Popups without arrows look and work fine which is why the option must be opt-in using a Boolean prop.

Many examples of code in the documentation, notably for the colours and shades, resort to manually writing examples for every colour and shade. This is a very terrible approach, one that will inevitably lead to hassles when updates are required.

A simpl improvement to this approach would be to use arrays, dictionaries and v-for to programatically generate GridCells. An alternative more intensive approach would be the playground experience suggested in #6.

This v-for methodology has been used to update documentation for the Grid component, which can be used as reference if needed.

Currently GitHub Pages are being used to serve the Vocabulary website. This comes with its own set of shortcomings, the main one being the need for manual builds into the docs/ directory each time documentation is updated in the source code.

Having Netlify installed would allow us to set up an auotmatically deployed, always up to date version of Vocabulary documentation served independently from the codebase.

While Vocabulary has a sizeable collection of components now, it is still far far away from being exhaustive. There are tons of components that need to be developed and this issue will serve to keep a track of components that have been proposed and are being worked on.

This is a discussion thread that will mark all components that have been requested by the community of users.

To request a component, just open a Markdown checkbox with the name of the component. Upvotes (:+1:) and downvotes (:-1:) will determine whether the component must be developed and once developed and merged, it will be checked off.

Example request would contain something like - [ ] Component X which renders like

• Component X

You can and should also add some description, mock-ups or links to other libraries that provide this component.

Currently the simplicity of any component is governed by two Boolean props, namely isBasic and isGhost provided by the Simplifiable mixin.

Having two Booleans governing one aspect of a component is never ideal, much less so when the ghost style is a superset of the basic style. Having a component with the isGhost prop set to true and the isBasic prop unset and defaulting to false causes a semantic paradox and the code stinks.

A better approach to this is to have a String prop simplicity in the mixin that can take the values basic, ghost or any other level of simplicity that could come in the future.

This change requires a round of refactoring across all components and their documentation.

Restyle form input fields according to this design document https://www.figma.com/file/l4Mt3dn3Ndtrvrb4aLcwXI/Vocabulary.-Design-Library?node-id=0%3A250

This will include restyling input[type=text], select and removing the styles for input[type=checkbox] input[type=radio], as these will have default OS styles

The SwitchField component currently lacks a rounded and pill variant. The goal is to add these variants in order to make the component aesthetically compatible with more curved and rounded layouts.

Vocabulary has two front ends, a website built using the components developed inside Vocabulary itself and a styleguide showcasing these components.

Currently the styleguide is being pushed to GitHub pages and is seen at the link. This behaviour should be changed so as to display the website on the given URL and the styleguide at /styleguide.

The Vocabulary home page is beautifully designed and a styleguide is very clearly not the ideal landing page. The home page footer has links to the GitHub repo, the Styleguide and also demos so switching would be incredible.

The old card view for colors worked out well in the past when each color was present in four shades. With each color now having five shades, it is no longer feasible to use cards to present colors. Plus using separate cards for every shade creates the impression that each of this shade is an independent hue in itself, which is decidedly not the case here.

We need a better way to present information, and I personally think a table would be a good way to move forward.

Description

Create a stacking system for all of the elements in vocabulary.

Problems solved

Where elements like sticky footers or headers have to play nice with each other it can be difficult for teams to know what elements take priority. In many cases you may have elements popping up where they don't belong. exp: buttons being viewed over header elements.

Alternatives

Other design systems take advantage of Z-index variables like the morning star design system here
http://designsystem.morningstar.com/visual-language/layering.html

Additional context

Want to take up?

[Yes]

While CircleCI runs both linting and unit trusts on the master branch, none of the jobs are run on any of the PRs.

Running tests on PRs acts as a valuable check on the validity of the PR and removes the need to manually set up the branch locally and see if everything works as expected.

Currently Vocabulary is being manually pushed to npm. This can be automated with CircleCI so that it can automatically build and publish the package once all tests pass successfully.

Best way to do this is to use some mechanism on Github Actions to detect when a new tag is pushed and trigger the run the deploy script. It can't be the release name. It has to be able to detect a new tag, because the tag name matches the version on package.json.

Remove this div inside the <button> element which contains the <slot> content. This makes it difficult for users of Vocabulary to set their own content styles if they choose to.

Description
A number of components support slots for versatility and customization. There is no nice way to test out components with slots using the knobs addon for Storybook.

Problems solved
It would eliminate the need for stories such as withText and allow for a better way to define stories where one could directly enter some Vue code to render within the component.