ithaka / pharos Goto Github PK
View Code? Open in Web Editor NEWJSTOR's design system
Home Page: https://pharos.jstor.org
License: MIT License
JSTOR's design system
Home Page: https://pharos.jstor.org
License: MIT License
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.
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
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.
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
if: steps.changesets.outputs.published == 'true'
and then proceeds to merge main
into develop
and pushThe 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.
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.
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.
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;
The problem
The imports for guidelines (example) are tedious.
The solution
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
Steps to reproduce the issue
width: 20rem;
is appliedwidth
disappearswidth: 45rem;
is appliedScreenshots or code
https://user-images.githubusercontent.com/13315416/126526941-273b6e32-237f-4297-b426-5f4f2dc8cbb1.mov
Pharos version
10.5.1
Your environment
Additional information
Would be open to pairing.
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.
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
Your environment
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.
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.
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.
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):
pharos-color-text-40
, pharos-font-size-small
, and pharos-font-family-body
(default) fontAlternatives 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.
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
Screenshots or code
https://drive.google.com/file/d/1i805BcTuIU0O9ydMAUL31Hz06z1IFGwQ/view?usp=sharing
Pharos version
Pharos.jstor.org (newest I believe)
Your environment
Additional information
If you have any questions or concerns please reach out!
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
on-background
property that mirrors the current behavior of dark
dark
as deprecatedThe 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.
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
Screenshots or code
Misaligned tooltip with chrome collapsed:
Aligned tooltip with chrome visible:
Pharos version
10.5.1
Your environment
Additional information
We previously tried injecting the tooltips with the default strategy (without strategy="fixed"
) and that had bigger issues.
Following #38, remove the deprecated dark
property in a major release.
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.
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.
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).
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.
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.
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
Select
componentPharos version
PHAROS 9.3.0
Your environment
Additional information
Go through all the React Pharos components in storybook and identify other components having same issue.
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
.
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.
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.
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:
preset="4"
for titlesAlternatives 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
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
Screenshots or code
Pharos version
Indicate which version of Pharos you are using.
Your environment
Additional information
Add any additional notes or further context about the issue here.
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
code sandbox
https://codesandbox.io/s/eager-black-e9v3j?file=/src/components/HelloWorld.vue
Pharos version
9.1.0
Your environment
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
Pharos version
@pharos/[email protected]
Your environment
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.
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
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
Screenshots or code
See the 2nd image in this screenshot
Pharos version
9.2.1
Your environment
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.
OR
Screenshots or code
Pharos version
10.5.3
Your environment
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
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.
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.
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
Pharos version
Indicate which version of Pharos you are using.
Your environment
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
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.
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.
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.
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.
The problem
Style Dictionary 3.0 provides at least two major features we may want to leverage:
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
outputReferences
in the configurationAdditional 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.
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
custom-elements.json
Alternatives considered
NA
Additional information
storybookjs/storybook#15138
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
noImplicitOverride
to tsconfig filesoverride
where applicableAdditional information
Current blockers include:
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.