-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2021 Release Proposals #7538
Comments
Transition to Sass ModulesStatus: Proposal Towards the end of 2020, there was an announcement that LibSass, and the corresponding ecosystem, was officially deprecated. As a result, it seemed important that we take a look at leveraging Dart Sass as opposed to Node Sass in our upcoming release. In addition, we have several existing problems that we'd like to see addressed in our upcoming release:
Discussion Link: #7539 Packages impacted
LInks & Resources |
Bringing in IBM PlexStatus: Proposal Currently, we offer support for a handful of font faces (Sans, Mono, Serif) and a handful of weights (light, normal, semibold). We also offer a way for these fonts to be loaded easily through Google Fonts by default. However, it seems like the usage for IBM Plex has grown broadly to include the following use-cases:
Discussion Link: #7531 Packages impacted
Links & Resources |
Convert
|
Icon Modules with
|
Theming the UI ShellCurrently our UI Shell is offered in one variant with custom tokens and is unable to be themed by those using the UI Shell. In the past, we explored sharing variants of UI Shell here and for our next release we would like to find a way to ship the deliverable in that issue. Packages impacted:
Discussion LInk: N/A |
Component Accessibility PrimitivesOur team and those who use Carbon often run into accessibility problems when using the following set of components:
As we've investigated these issues, it seems like certain use-cases are inaccessible when used with these components because of either improper implementation on the component side or teams using a component for a different purpose than which it was intended. The most notable example of this is with tooltips and overflow menus. Often, teams will use these components for their visual style but not their underlying semantics (text-only tooltips, These component primitives include:
Packages impacted:
Discussion Link: TODO |
|
Tooltip RefactorCurrently, our tooltps are a combination of well-intentioned (but inaccessible) ARIA techniques that we need to fix in either an upcoming minor release or in the upcoming major release. In general, our tooltips will be text-only information that can be applied to buttons, links, and inputs. They will visually be rendered using our "Popover" component. As a result, our tooltips should be updated to include the following:
Links & Resources:
Packages impacted:
Discussion Link: TODO |
Notification RefactorCurrently, our Notification components support rendering interactive content inside of the notification itself. This content includes components like links or buttons. Unfortunately, Notifications in their current implementation are unable to correct relay this information to screen readers as all semantics are stripped in the content of a notification. This update to Notification will include some research in order to figure out the correct way to provide accessible options for both text-only notifications and notifications with action items. Links & Resources Packages impacted:
Discussion Link: TODO |
Focus style updatesCurrently, we provide custom focus styles that will trigger when users interact with an interactive element. By default, browsers will choose not to display focus styles but because we specify custom focus styles they will appear. This lead to a question by teams across IBM: is it possible to mirror the browser behavior with custom focus styles? There is a proposal for this behavior, using Links & Resources Packages impacted:
Discussion Link: TODO |
CSS Grid SupportOur grid implementation uses flexbox as the underlying layout mechanism for teams to achieve 12/16 column layouts. As we look towards dropping support for IE11 in our next release, it would make sense for us to provide first-class support for CSS Grid. Packages impacted:
Planning Issue: TODO |
Package bundle performanceOur packages ship more JS and CSS than they need to. As part of our next release, it'd be great to refactor away some of the dead code that is not needed for a package. We could also use this as a chance to move away from dependencies that may be larger than we want to ship, or are unintentionally included even when not used. In terms of CSS, it'd be great to get a handle our the size of each stylesheet. Reducing selector complexity and limiting our use of nested mixins to generate CSS will go a long way to reducing the overall footprint of Carbon's styles. Packages impacted:
Planning Issue: TODO |
Color tokens updateUpdates to the component color tokens with two main objectives:
Links and resources:
Packages impacted:
|
Inline theming[stub]
|
Combine spacing + layout token scalesThere is little value in having two distinct spacing and layout scales. It could easily all be one scale. Need to look at adding a few larger scale steps as well. Packages impacted:
|
Package renames and dependency updatesWe offer up a mix of It would be great if we could simplify this to just one package install across the ecosystem. In other words, if you want to use React you use Under the hood, these packages could internally depend on Packages impacted:
|
Officially deprecate
|
Not listedThis is an umbrella comment for items that we talked about but maybe don't have an official "proposal" attached with them.
|
|
Refactoring test suiteCurrently, our test suite is a mixture of enzyme, custom test setup, and React Testing Library. As part of our push towards v11, it'd be great to consolidate on React Testing Library along with some testing guidelines for what we thing should be covered by the Public API of a component. Packages impacted:
|
Prop Name ConsistencyWe currently vary with respect to prop names and how we name props in functionality added to components. This update would be a great opportunity to finally consolidate these names into a standard set along with guidelines and how we name props in components. Packages impacted:
|
This planning issue is currently a WIP. Everything listed here is subject to change
This umbrella issue is going to be organized into multiple topics. Each topic refers to a proposed change to our ecosystem of packages that will be shipped in our Q2 2021 release. Topics can relate to several packages, or just one, and should have an accompanying discussion linked at the bottom of the section.
Overview
console.warn
size
PropThe text was updated successfully, but these errors were encountered: