ithaka / pharos

JSTOR's design system

Pharos Design System

Pharos is JSTOR’s design system for creating cohesive, supportive and beautiful experiences for the intellectually curious.

JSTOR is a digital library for the intellectually curious. We provide a platform for discovering and connecting research, images, and primary sources. As a not-for-profit, we partner with libraries, museums, and publishers to reduce costs, extend access, and preserve scholarship for the future. We do this because we believe in the power of knowledge to change the world for the better.

Build statuses

System	Status
Site
Storybooks

Getting Started

• Check out the core package for more info about Pharos components and how to get started
• Visit the Pharos site to learn about the JSTOR brand, design guidelines, and component usage guidelines
• Explore the web component Storybook or the React Storybook to try the live components
• Test for visual regressions in the Pharos Chromatic project

Packages and configuration

This repository contains a number of packages related to Pharos:

Syntax	Description
@ithaka/pharos	Pharos Component library
@ithaka/pharos-cli	CLI tool for building Pharos components
@ithaka/pharos-site	Site & Documentation for Pharos

In addition to these packages, this repository contains the configuration for Pharos Storybooks.

Contributing

If you'd like to learn more about contributing to Pharos, refer to the contribution guide.

Contributors ✨

Thanks goes to these wonderful people (emoji key):

Robert Niznik 💻	Sayem Quazi 💻	Dane Hillard 💻	Jayshree Bhakta ⚠️	Evan Slawski 💻	Kelsey Cavitt 🎨 📖	Jialin He 💻
Mike Iden 💻	Yanni Mouzakis 💻	Jay Kent 💻	Sean Anggani 💻	Rehan Abbasi 💻	Sean Mitchey ⚠️	Cameron Heard ⚠️
Aparna Bankston ⚠️	Liza-Pagano 🎨 📖	Lori Lundy 🎨 📖	Florence Lee 🎨 📖	Justin Alexander ️️️️♿️ 📖	Matthew Martin 🎨 📖	Elham Islam 💻
Gayla Bassham 💻	Satya AchantaVenkata 💻 📖	K Chingsubam 💻	Christopher Brown 💻	JoshAtITHAKA 💻 📖	Armaan Dandavati 💻	Evan Shoup 💻 📖
Drew Gingerich 📖 💻	Hassan Tanveer 💻	mariadevadoss 💻	Brent Swisher 🐛 💻	Henry Long 💻	Mat Harris ️️️️♿️	david-corneail 🎨 📖

This project follows the all-contributors specification. Contributions of any kind are welcome!

Work with us at ITHAKA

JSTOR is part of ITHAKA, a not-for-profit dedicated to expanding access to knowledge and education worldwide. Our staff makes us who we are. We’re hiring — join us!

• See career opportunities
• Learn more about ITHAKA

License

This project is available under the MIT license. For more information, view the full license and copyright notice.

Copyright 2021 Ithaka Harbors, Inc.

pharos's Issues

Tooltip: Incorrect positioning for image card titles on Firefox

Expected behavior
Tooltips appear at the correct position for all elements on all browsers

Actual behavior
Tooltips are being displayed very far from the trigger element for titles on image cards when using Firefox.

Steps to reproduce the issue
Compare the following code sandbox between Chrome and Firefox and notice the tooltip appears in chrome but is not in the right position on Firefox.

CodeSandbox reproduction

OR

1. Open up firefox and go to www.jstor.org
2. Log into personal account
3. Search for content and save something to your workspace with a fairly long title
4. Go to workspace and enable gallery view
5. Hover over titles and notice that the tooltips are missing (completely out of the viewport) or hundreds of pixels away from where they should be.

Screenshots or code

Screen.Recording.2021-08-09.at.4.00.59.PM.mov

Pharos version
10.5.3

Your environment

• OS: macOs
• Browser: Firefox
• Version: 90.0.2

Additional information
See in the video above about how the inline-flex on a few different pharos elements classes appear to be causing the problem. Removing those places the tooltip properly but causes other problems.

High probability this could be a bug with popper.js or Firefox itself. We've already tried updating to a popper 2.9.3 but didn't notice any difference

Upgrade to Style Dictionary 3.0

The problem

Style Dictionary 3.0 provides at least two major features we may want to leverage:

• Lazily-referenced, multi-pass design token calculations
• Output references

These would enable us to support more dynamic construction of our tokens, and give us a path toward theming. In general it would provide a better "audit trail" of the origin of tokens once they've reached the browser, leading to more internalizing of those tokens instead of their values amongst developers.

The solution

• Upgrade to Style Dictionary 3.0
• Enable outputReferences in the configuration

Additional information

This doesn't seem like it would be a breaking change—anywhere CSS variables and SCSS variables might be used would still have these reference values available, from what I can tell.

Creating a new changeset adds a newline to the end of each existing changeset

Expected behavior
Only the new changeset shows as added in a pull request diff

Actual behavior
Each existing changeset has a newline added to it—if there are 10 unreleased changes, the next change's pull request will have an extra 10 files in the diff, each with only a newline appended.

Steps to reproduce the issue

1. Make a change
2. Create a changeset
3. Observe a newline added to all the changesets

Your environment

• OS: macOS

Additional information
This appears to be because markdown-toc is processing these files via lint-staged. It could probably ignore those particular markdown files, because they won't need and maybe shouldn't ever have a TOC inserted.

Accessibility: Investigate use of `:focus-visible` for focus states

The problem

Focus states provide valuable feedback to keyboard users, low vision users, and more. However, they can be heavy-handed for cases where a user is already actively clicking on an element, as an example.

The solution

Use :focus-visible in judicious ways to make Pharos elements show the focus outline only when necessary.

Alternatives considered

Leaving the focus states as they are could be alright, but it provides unnecessary motion and can draw attention from the task at hand.

Additional information

See this article for a good overview.

Use SassDoc (or equivalent) to document SASS mixins inline

The problem
The SASS mixin documentation is driven by a static TypeScript file, which may grow outdated if we forget to update it when we change/add/remove a mixin.

The solution
Move the documentation for a given mixin into a SassDoc comment that will increase the likelihood of parity with the actual implementation and allow anyone reading the code itself to benefit from the same documentation.

Alternatives considered
Keeping the static TypeScript file but moving it closer to the SASS mixins would help, but would still suffer the possibility to forget to update it with some regularity.

Additional information
I haven't evaluated the state or capabilities of SassDoc in quite some time—any movement in this area needs to make sure to account for anything lurking there.

Remove hard-coded heading level from image cards

The problem
Image cards may appear at a variety of places in a document hierarchy, such that their heading level may be 2 or lower. Sometimes, it may even be desirable not to use a heading at all, instead using styled text that doesn't affect the document hierarchy.

The solution
Allow consumers to change the level, and potentially the tag type, for image card titles.

Link: Add ability to render as a <button>

The problem

Occasionally, it's useful to render something that looks like a link but is a <button> in the DOM.

The solution

Add a variant="link" that makes a Button look like a Link (including hover, focus, and so on), ideally by reusing exactly all the Link styles.

Storybook: Use Vite for Storybook build

The problem
It can be slow to build Storybook from scratch, locally or on Netlify.

The solution
Storybook recently released support for Vite which can significantly improve the speed of builds.

Alternatives considered
We've discussed only rebuilding the @ithaka/pharos code when necessary as one way of speeding up builds, which saw a non-trivial improvement in build time but may necessarily introduce additional complexity into the delivery process.

Additional information
Some Storybook addons still depend on Webpack per the blog post, so we should take care that the addons we're using continue to function properly.

There's one outstanding issue (with corresponding pull request) we may need to land before doing this.

Site: Use aliases to clean up guidelines imports

The problem

The imports for guidelines (example) are tedious.

The solution

• Update the Webpack config to alias the guidelines directory
• Update the guidelines imports to use the new alias

Heading: Require an explicit `level` value

The problem
Information hierarchy is an important aspect of creating pages. Without proper guard rails, it can be easy to forget to specify the hierarchy. Heading currently defaults to level 1 headings. This is also problematic because one is likely to end up with multiple level 1 headings on a page if they forget to specify levels, and multiple level 1 headings is a big no-no.

The solution
Make level a required property.

Tooltip: Fixed strategy tooltips misaligned when browser chrome disappears on mobile

Expected behavior
Tooltips always open directly adjacent to their associated element.

Actual behavior
Tooltips with the fixed positioning are misaligned from their associated element when the browser chrome disappears on mobile

Steps to reproduce the issue

1. Perform a JSTOR search on a mobile browser. I was using Safari on iOS 14.7.1
2. Click "Cite" to open up the citation modal
3. Click "Copy" for one top citations (MLA, APA, Chicago)
4. See citation is misaligned if the browser chrome is not present. Opening the citation again with the chrome present has correctly aligned tooltips

Screenshots or code
Misaligned tooltip with chrome collapsed:

Aligned tooltip with chrome visible:

Pharos version
10.5.1

Your environment

• OS: iOS
• Browser: Safari
• Version: 14.7.1

Additional information
We previously tried injecting the tooltips with the default strategy (without strategy="fixed") and that had bigger issues.

Alert: Remove base variant with no intended use

The problem
The base Alert style was originally created when trying to explore the spectrum between single components with conditional logic and many components using composition and/or inheritance. It was never intended to be used in production context, and as it turns out is not really needed logistically at this point either.

The solution
Remove the base style from Storybook and make status a required property

Unable to view storybook(s) in React components storybook

Expected behavior
When we view Storybook ( React components ), we expect to view the Canvas without any errors displayed.

Actual behavior
When we view the React version of select component storybook, we see an error. This can likely be the issue with other components as well.

Minified React error #62; visit https://reactjs.org/docs/error-decoder.html?invariant=62 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

Steps to reproduce the issue

1. Visit Pharos Storybook for React Components
2. Under the 'Forms' section, select Select component
3. An error message is displayed.

Screenshots or code

Pharos version
PHAROS 9.3.0

Your environment

• OS: macOS
• Browser: Chrome
• Version: 90.0.4430.212

Additional information
Go through all the React Pharos components in storybook and identify other components having same issue.

Checkbox: Add `on-background` property and deprecate `dark` property

The problem
Many components can be asked to display inverse-style colors using an on-background property. The odd one out is Checkbox, which uses a dark property. The on-background property should be added and preferred instead, for both consistency and decoupling from equating the concept of "dark" to the concept of "on-background."

The solution

• Add an on-background property that mirrors the current behavior of dark
• Mark dark as deprecated

"Do's and Dont's" should be "Dos and Don'ts"

Expected behavior
Proper grammar used for guideline titles

Actual behavior
Apostrophes used as plurality, and missing from contractions

Additional context
This is the culprit of the incorrect spelling. Note that the spelling is correct here.

Chrome crashes on combination of pharos-input-group, pharos-heading, pharos-link

Expected behavior
doesn't crash

Actual behavior
crashes

Steps to reproduce the issue

with an input box on the page
and a link inside a heading.
example

<pharos-input-group class="border" placeholder="bla" />
<pharos-heading level="1" preset="2">
    <pharos-link href="/google">
        bla bla bla
    </pharos-link>
</pharos-heading>

type something in the input box
then right click on the input box.
the tab crashes! (only in chrome)(firefox is fine 🦊 and all other browsers)

link to sandbox
link to edit sandbox

Screenshots or code
If applicable, add screenshots or code to help explain the issue.

Pharos version
10.4

Your environment

• OS: macOS
• Browser: Chrome
• Version: 91

Combobox: Keyboard behavior not working as expected

Expected behavior
The down arrow key should expand the combobox and go through the options. The down-chevron should not receive focus but should still be clickable. See example 3

Actual behavior
When focus is put onto the down chevron, you are able to use the arrow key to move through the options but also move page down

Steps to reproduce the issue

1. put focus onto the pharos combobox
2. tab to put focus onto the down chevron
3. click the down arrow key multiple times

Screenshots or code
https://drive.google.com/file/d/1i805BcTuIU0O9ydMAUL31Hz06z1IFGwQ/view?usp=sharing

Pharos version
Pharos.jstor.org (newest I believe)
Your environment

• OS: macOS
• Browser: able to duplicate on all
• Version: Chrome: Version 91.0.4472.114 (Official Build) (x86_64)
• mac: Big Sur 11.2.3

Additional information
If you have any questions or concerns please reach out!

Site: Image card component examples span the width of the content area

Expected behavior
The image card component examples should only be up to a certain width. they shouldn't span the width of the content area.

Actual behavior
the image card component examples look kind of funky on the pharos site because they span the width of the content area

Steps to reproduce the issue

1. Go here https://pharos.jstor.org/components/image-card

Screenshots or code

Pharos version
Indicate which version of Pharos you are using.

Your environment

• OS: macOS
• Browser: Chrome
• Version: 91.0.4472.77

Additional information
Add any additional notes or further context about the issue here.

Infra: Provide solution for duplicate component registration

The problem

Right now Pharos requires using its own @customElement decorator to ensure no runtime errors when a component is registered multiple times. This doesn't cover third-party components we make use of, and doesn't provide deterministic behavior if two differing versions of the component try to register (the first one wins).

The solution

Use the scoped element mixin to provide an axis of freedom in registering components under another name.

Alternatives considered

In the long term scoped custom element registration will help solve this issue natively.

Toggle Button Group: Add documentation to site

The problem
The toggle button group is out and available and we should provide guidelines so that it is used in the appropriate manner.

The solution
I can provide the link to the documentation.

Pagination: Variant with page selector

The problem
I am always frustrated when looking through pages of sorted search results, and I can't select a page deeper into the results right away. This problem is even more annoying when the whole page reloads for each new page of search results.

The solution
Create a pagination component that allows for page selection. Now I can search through results more efficiently.

Alternatives considered
I considered using the standard pagination component and trying to find a way to avoid page reloads when navigating between pages of results, but I do not think there is an easy way to avoid a reload. This is because the list of results is generated in Django.

Additional information
N/A

Slot for heading in image card component

The problem
The workspace headers have a lot of truncation, tooltip, and Mathjax code associated with them. We would like to leverage that code for the headings in the image card component.

The solution
We would like to be able to pass our heading components in a slot instead of passing the title as pure text.

Alternatives considered
Indicate any alternative solutions or features you've considered.

Additional information
Add any additional notes or further context about the request here.

Add pharos-spacing-10-x token

The problem
In more editorial layouts, we want to be able to put just a big honking space between sections and whatnot.

The solution
Create a pharos-spacing-10-x token for use in application styles.

Alternatives considered
We can hard code 10rem which is easy enough, but as with all things design token, we'd like to be able to change what pharos-spacing-10-x means some day and have things naturally update.

Select: option should be selected if the value of select matches option value

Expected behavior
the value of the of the select set the selected option

Actual behavior
the pharos-select selected option is 1 event though the value of the select is 2

Steps to reproduce the issue
https://codesandbox.io/s/frosty-currying-rv34u?file=/src/components/HelloWorld.vue

Pharos version
9.x

Your environment
macOS
firefox

Automate last step of merging main into develop as part of our release workflow

The problem
Currently after making a release we need to manually merge main back into develop and push. We should automate the whole process to avoid the chance of forgetting to do this last step.

The solution

• Add a final step to the release workflow that checks if: steps.changesets.outputs.published == 'true' and then proceeds to merge main into develop and push
• Update documentation

Accordion: A component for collapsible information

The problem

Sometimes a page needs multiple, collapsible sections so that information can be digested incrementally or optionally.

The solution

An accordion component is available that allows providing a title / summary and the detailed content, probably as slots.

Additional information

It could be good semantics-wise to leverage the <summary> and <details> tags within the component.

Image Card: Instill stricter typography styles for slotted content

The problem
When paired with global styles that affect the typography of things like p elements, the Image Card can have slotted content that doesn't adhere to its internally-defined typography styles.

The solution
Provide a consumer-includable SCSS file for Image Card that gives slotted content the appropriate typography.

Alternatives considered
This can be done at the consumer, but can be tedious especially if multiple elements need to be overridden. It's also brittle—if we want to change the Image Card typography later, the consumer would need to as well.

Image Card: Add "source type" property

The problem
An image card is often used to link to content, which may itself be an image, but may also be an editorial article, a journal article, a book chapter, and so on. We want a way to indicate this on the card.

The solution
Add a "source type" property (name not set in stone):

• Only used in the default variant
• Appears above the card title when present
• Is pharos-color-text-40, pharos-font-size-small, and pharos-font-family-body (default) font
• Is all caps

Alternatives considered

We considered the content pattern where the source type could appear below the card title, which would allow us to use the metadata slot to pass this in, but the information hierarchy doesn't work super well and would require more boilerplate.

Infra: Use Custom Elements Manifest v1.0.0

The problem
Custom Elements Manifest is a file format that describes custom elements in a project. It allows tooling and IDEs to give users information about those elements when used in their project. We have been working with the experimental version generated by web-component-analyzer. The spec has now been standardized.

The solution

• Use @custom-elements-manifest/analyzer to generate our custom-elements.json
• Update to a Storybook version that supports the new spec
• Update the React gulp task to parse the new format correctly to generate the TS interface

Alternatives considered
NA

Additional information
storybookjs/storybook#15138

Drop support for Internet Explorer 11

The problem
Internet Explorer 11 (IE11) is nearing the end of its support life. We want to be ahead of the curve and prepared for that change.

The solution

• Determine which set of polyfills can be removed that will still maintain modern browser support, and remove them.
• Remove the per-component imports of tokens, which was to support IE11

Breadcrumb: Items don't break across multiple lines on small screens

Expected behavior
When the screen width gets small enough that it's narrower than the breadcrumbs, they should break across multiple lines so they fit in the viewport.

Actual behavior
The breadcrumbs stay on a single line wider than the viewport.

Steps to reproduce the issue

1. Build a Breadcrumb with a few Breadcrumb Items with a fair amount of text
2. Narrow the screen

Pharos version
Indicate which version of Pharos you are using.

Your environment

• OS: macOS
• Browser: Firefox
• Version: @ithaka/[email protected]

Events stories in Storybook should default to the Actions tab

The problem
When looking at Events stories in Storybook, one would typically prefer to view the Actions tab of the story to see the events that emit when interacting with the component. Most Pharos stories default to the Controls tab, however.

The solution
Default all Events stories to the Actions tab.

Alert: Add ability to close

The problem

Although some things are transient enough that Toast works, and some things are permanent enough that a constant alert works, there are cases where an alert should be closable.

The solution

Add something like a closable property that would render a close button that, when clicked, emits an event indicating the alert should be destroyed.

Alternatives considered
This content can be slotted in and done manually, but it's a usage pattern that pops up often enough that it would be best to codify it for consistency and to ensure accessibility.

Additional context

"Dismiss" is probably a more preferred verbiage here, but "dismissible" and "dismissable" would be hard to remember the correct spelling of, and neither is a dictionary word.

People have been doing the closing something like this:

<pharos-alert>
    <div>
        <div>
           ...
        </div>
        <pharos-icon
            name="close"
            description="Close"
            @click="closePanel()"
        />
    </div>
</pharos-alert>

Where closePanel emits an event to the parent who reacts by hiding the alert on next render.

Docs: Indicate requirement of importing CSS tokens

The problem
In Pharos v10.0.0 the design tokens are no longer included with each component. Thus to ensure our components get styled correctly we need to explicitly state that users must import the CSS variables tokens once in their styles entrypoint.

The solution
Update documentation to explicitly state this requirement.

Additional information
The browsers support and polyfills section in the README should also be updated as we no longer support IE11.

Image-Card hover text extends beyond container when "subtle" on Safari

ONLY ON SAFARI, FIREFOX AND CHROME ARE GOOD

Expected behavior
when an image card is subtle and user hovers. the text displays in a readable way

Actual behavior
The text overflows the card container and is almost invisible as it's white text on a white background (usually)

Steps to reproduce the issue

1. go to jstor search
2. perform search that returns image carousel. ex: "posters"
3. see the images at the top of the search results
4. hover one of the images
5. see that the "subtle" hover text overflows it's container

Screenshots or code
See the 2nd image in this screenshot

Pharos version
9.2.1

Your environment

• OS: macOS
• Browser: Safari
• Version: latest

Badge: A component for quick content identification

The problem

JSTOR has a wide variety of content types, and it's useful to check at a glance what type of content a particular item is across search, browse, and detail contexts. We use a small, all-caps badge to display this information. Right now we're still using Foundation's badge directly, or have re-created that as a one-off in new code.

The solution

Formalize the badge as a new component.

Additional information

The current styling is roughly:

font-size: var(--pharos-font-size-small);
font-weight: var(--pharos-font-weight-bold);
line-height: var(--pharos-line-height-medium);
color: var(--pharos-color-text-40);
text-transform: uppercase;

Icon: Remove height and width from public API

The problem
Changing the height and width props for icons does not actually change their sizing. We wish to keep the icon sizes constant for better consistency across the platform.

The solution
Use @state instead of @prop for height and width.

Infra: Upgrade to TypeScript 4.3 with `noImplicitOverride`

The problem
TypeScript 4.3 is out now with a new keyword override and --noImplicitOverride flag to help reduce errors when extending classes.

The solution

• Update to TypeScript 4.3
• Add noImplicitOverride to tsconfig files
• Update components to use override where applicable

Additional information
Current blockers include:

• Prettier support
• #113

Site: Remove non-breaking space entities in favor of regular whitespace

Expected behavior

Spaces are rendered evenly and allow for natural line breaks in text when the flow calls for it.

Actual behavior

Non-breaking spaces are easy to code inadvertently with an additional space in between to separate words from the HTML entity, and in the right flow situations don't allow the text to break between words, causing too many words to flow to the next line.

Site: Show live component examples just after main heading on component pages

The problem

Each component should present itself in true-to-life fashion on its component page so that people know right away what it's for and can try it out.

The solution

Move the live component examples that are currently the last part of the component page just below the heading and before the component description on each component page.

Additional information

This will require splitting some things up that are currently baked together—right now, all the intro stuff lives in an Intro component. It's possible the live examples could move inside that, but it's not clear whether they'd work in Storybook. If Storybook just doesn't render them, that might be an option.

React Storybook doesn't display component API

Expected behavior
When I use the React Storybook to view a component's documentation, I see its API displayed in the API table on the Docs tab.

Actual behavior
The API table is empty.

Steps to reproduce the issue

1. Run the React Storybook
2. Navigate to a component
3. Navigate to the Docs tab
4. Observe the empty API table

Pharos version

@pharos/[email protected]

Your environment

• OS: macOS
• Browser: Firefox
• Version: 89.0b6

Additional information
This relates to storybookjs/storybook#14118 and hipstersmoothie/react-docgen-typescript-plugin#30

The API is still properly constructed such that you can make use of an IDE's intellisense features.

Missing width between 361px and 767px on the pharos layout

Expected behavior
Width defined for the pharos layout between 361px and 767px. All other screensizes appear to have some width defined.

Actual behavior
No width is defined, which means the width of the content determines the width inside the layout.

This negatively affects the workspace when the folder does not contain any records that are wide enough to take up the full width of the screen

Ex:
https://user-images.githubusercontent.com/13315416/126532083-ff2a13e7-dfb1-4934-a64e-dac6b0bcde8d.mov

Steps to reproduce the issue

1. Go to https://pharos-storybooks.netlify.app/wc/iframe.html?id=components-layout--one-column&args=&globals=backgrounds.grid:true&viewMode=story
2. Open up inspector and enable responsive sizing
3. Change width to 360px and width: 20rem; is applied
4. Change width to 361px and the width disappears
5. Change width to 767px and the width is still not present
6. Change width to 768px and width: 45rem; is applied

Screenshots or code
https://user-images.githubusercontent.com/13315416/126526941-273b6e32-237f-4297-b426-5f4f2dc8cbb1.mov

Pharos version
10.5.1

Your environment

• OS: macOS
• Browser: Chrome, Firefox, presumably all
• Version: 91, 89

Additional information
Would be open to pairing.

Combobox: Unable to clear combo box display value

Expected behavior
On clearing the combo box value attribute(setting it to an empty string), the display value would also be cleared out.

Actual behavior
Setting the value attribute for combo box doesn't update the display value.

Steps to reproduce the issue

1. Select an option from the combo box dropdown.
2. Then try dynamically resetting the combo box value.
3. The display value still persists

code sandbox
https://codesandbox.io/s/eager-black-e9v3j?file=/src/components/HelloWorld.vue

Pharos version
9.1.0

Your environment

• OS: macOS
• Browser: Chrome
• Version: 91.0.4472.114

Tokens: Sizing

The problem

Some components need to have an explicit height or width defined, and it may be beneficial for those values to be tokenized instead of hard coded.

The solution

Creating a new set of "sizing" tokens that can be used to size components. An analysis should be included as part of this that determines which things should be included (or not), and what values to settle out to (we don't want a token for every possible size).

Additional information

Some folks have been inclined to use the existing spacing tokens to represent a size, but these are really separate purposes—one is about how much room a thing takes up, while the other is how much space to place between things.

Image Card: Allow for custom aspect ratio in collection variant

The problem

I want to use the collection variant of the image card to get its showy heading style, but I also have images that aren't 4:3.

The solution

Be able to specify the aspect ratio of the image explicitly instead of hard coding it, or better, allow the card to shrink naturally like it does for the default variant.

Alternatives considered

We could use the default variant to shrink to the image's natural aspect, but it doesn't have a showy heading style. We could create new images that are 4:3, but that doesn't track well.

Additional information

It may be that the "collection" variant is a bit of a tightly-scoped name as well—it's a bit of a "showcase" variant that may not always be showcasing a collection per se. That's really a semantics issue, but good to have language that can be used ubiquitously.

Checkbox: Remove the `dark` property

Following #38, remove the deprecated dark property in a major release.

Carousel: Navigable composition of image cards

The problem
Today on the image detail page, we show carousels that are constrained by height and have flexible widths. This style is not in line with our brand and frequently results in blurry images.

The solution
We would like to redesign the carousel using the image card component (item and collection variants).

Image Card: Create "promotional" variant

The problem
The default variant of the image card has modestly-sized title text, and the collection variant has more prominent title text. Sometimes it's useful to have even more prominent text when emphasizing a particular piece of content.

The default variant allows for images of various aspect ratios, whereas the collection variant forces images to a 4:3 aspect ratio.

The solution

Create a "promotional" variant (name not set in stone) that:

1. Accepts a variety of image aspect ratios
2. Uses preset="4" for titles
3. Requires a call to action(?)

Alternatives considered

This could also be handled as its own component, because it's a different content pattern from image cards at large. We don't want this to be used outside its intended context, so having a separate component might encourage a second thought about whether it's the right thing to use, compared to just being able to change the variant property.

Additional information

This may subsume #146

Remove reference to Wiki on Voice and Tone page

Expected behavior
https://pharos.jstor.org/content-style-guide/voice-and-tone
Ends with "See the Wiki for the latest..." but we don't link to it, and this page is no longer up to date. Let's please remove the last two sentences on that page.

Screenshots or code

Docs: Release strategy for patch/minor versions during development of next major release

The problem
Situations can arise where a bugfix or new feature needs to be released during work towards a new major release. We should have a defined process for doing so.

The solution
A strategy is agreed upon and verified. It will likely involve cherry-picking commits and having a dedicated branch for the other releases (to avoid issues with Changesets). Documentation and/or diagrams are made to inform maintainers.

Additional information
A strategy/discussion may be needed for release families in general. At the very least we should address this circumstance.