I'm not sure if this is the best repo to file this issue, but when I created a new Contentful extension using the @contentful/create-contentful-extension package I was surprised to see how big the included component library made the final build. Below is the output I got when I ran npm run deploy on my extension. I am only using one component (TextField) so I'm surprised how expensive it is to use forma-36-react-components. I though Parcel is usually pretty good at this stuff so I wonder if the package itself needs to be changed to better support code splitting?

> [email protected] build /Users/sohara/code/soulcycle/publish-uri
> contentful-extension-scripts build

✨  Built in 7.52s.

build/src.f69400ca.js                                                       391.96 KB    6.96s
├── node_modules/@contentful/forma-36-react-components/dist/esm/index.js    241.46 KB    5.43s
├── node_modules/react-dom/cjs/react-dom.production.min.js                  109.72 KB    2.06s
├── node_modules/contentful-ui-extensions-sdk/dist/cf-extension-api.js       24.27 KB    530ms
├── node_modules/react/cjs/react.production.min.js                            6.41 KB    704ms
├── node_modules/scheduler/cjs/scheduler.production.min.js                    5.41 KB     66ms
├── src/index.tsx                                                             1.98 KB    969ms
├── node_modules/object-assign/index.js                                       1.95 KB    4.86s
├── node_modules/react-dom/index.js                                             374 B     89ms
├── node_modules/scheduler/index.js                                             165 B    3.51s
└── node_modules/react/index.js                                                 157 B     79ms

build/src.f69400ca.css                                                       57.56 KB    5.67s
├── src/index.css                                                                94 B    5.66s
└── node_modules/@contentful/forma-36-react-components/dist/styles.css           50 B    5.66s

build/index.html                                                                209 B    504ms

Extension size: 433 KB from 512 KB allowed.


✨  Successfully created extension:

Space: u860i9c783wb

Environment: dev-test-faq

Your extension: https://app.contentful.com/spaces/u860i9c783wb/environments/dev-test-faq/settings/extensions/publish-path

I would like to propose a pattern to be implemented in all Forma36 components.
ref, classNames and otherProps, testId should always go to the root element.

Currently, the lack of a pattern slows down development with the components. Besides not being consistent about where those props go, there's also inconsistency in their names -- i.e. ref shows up as nodeRef, inputRef, getRef , setRef... -- and their presence in the components.

Hey!

While working on the documentation search last Friday, I played around the navigation to try to improve it a little bit.

The issues I was trying to solve is while scrolling down to read some documentation if you want to go to another page you would need to scroll back up to find the navigation again.
The same thing happens if you want to search for something or click on a social link (Blog, GitHub and Community).

I took inspiration in how other documentation websites deal with this, like:

• CircuitUI from SumUp (Storybook Docs)
• Atlassian design
• Pajamas from GitLab

And I propose moving all the navigation to the side menu. Keeping the logo, the social links and the search fixed in the top left. The list of links for the components documentation would scroll independently from the content (see the gif). Also, we can keep the three categories (Foundation, Guidelines and Components) always expanded.

Home

Documentation Page

Scrolling

Forma 36 bug report

Summary

The SectionHeading component is not documented under "Typography" in Storybook.

Environment

All. :)

Greetings!

I was trying to get started using the forma-36-react-component in a create-react-app v2.1.5, yet when I try to import a component as is shown in the tutorial, I am getting a message that the components are not being exported:

Failed to compile
./src/index.tsx
Attempted import error: 'Button' is not exported from '@contentful/forma-36-react-components'.

My index.tsx is as follows:

import React from 'react';
import ReactDOM from 'react-dom';
import '@contentful/forma-36-react-components/dist/styles.css';
import { Button } from '@contentful/forma-36-react-components';

class App extends React.Component {

  render() {
    return (
      <Button buttonType="primary" onClick={() => {
        console.log('You clicked on Forma36 button');
      }}>
        Click on me
      </Button>
    );
  }
}

I was trying to use the latest version 2.9.2 of the forma-36-react-components.

Forma 36 ProductIcon / NavigationIcon

The problem

Hey there 👋

I would like to propose to extend Forma36 to contain the <ProductIcon /> / <NavigationIcon /> component. This component is used by navigation and headlines of the pages in the webapp. By moving this icons into Forma36 we would improve the visibility of the product related icons, potentially it might be useful for customers that are creating their custom solutions. This would also give us a chance to present our guidelines and recommendations for icons, for developers and designers.
In the future, if we consider moving navigation elements into Forma36, this step could be also beneficial.
We would have all icons aligned, visible and be part of the design system, which would give us more consistency and transparency.

The proposed solution

Proposed component was already created in the Contentful web app. It is used by top navigation items and headlines of the pages:

1. New <NavigationIcon /> in the web app has predefined set of sizes:

  small: '18px',
  medium: '24px',
  large: '32px',
  xlarge: '48px'

I would like to propose to align sizes of Forma36 <Icon /> and <NavigationIcon /> component in terms of sizes, to keep them consistent. We would end up with following set for both components:

  tiny: '16px',
  small: '18px',
  medium: '24px',
  large: '32px',
  xlarge: '48px'

2. Currently <NavigationIcon /> in the Contentful web app takes only 2 colors: colorGreenBase and colorWhite, but we could extend it if needed. Maybe align <Icon /> and <NavigationIcon /> when it comes to colors?

3. I would like to also propose to have an option to define tag type to be 'div' | 'span' within this new component.

4. We could allow this component to display custom SVG just in case it's needed, something like (pseudo code):

{type ? <IconComponent /> : children}

5. Apart of the above, we would also allow testId and className of course.

6. Alignment of the documentation for existing <Icon /> and creating docs for new component:
   I think we could extend our existing documentation to contain more examples of usage. Currently we don't really have much examples and I think it might be useful. We could present how to use icons with text in different sizes - how we propose to align text with icons, what is our recommendation. Also we could show how to use icons in other components, like <Button />. Same approach would apply for new component docs - we could create documentation in the way that it present some use cases.

7. Component was already created in the Contentful web app, so some part of work is already done. We would need to create/re-create component in Forma36 based on the existing one from web app, create storybook (maybe also adjust or extend the storybook for existing <Icon /> component) and create documentation and adjust the existing one. At the end, we would need to replace component in the web app, of course.

Questions

1. Alignment of the sizes require to align existing Icon--large (which is 36px) with the `large: '32px' from the new component. Do you think that would be ok to align them (both 32px) or we would prefer to merge them?
2. Should we align both components in terms of colors right now?
3. Name of the new component: currently it exists as <NavigationIcon /> in the web app but we can change it into something more generic like <ProductIcon /> or anything else that comes to your mind. WDYT?
4. Should we allow custom SVG's to be passed into the component?

And that's it 🎉

It seems that you cannot automatically focus a TextInput component within a DialogExtension modal.

Repro:

• Create a sidebar extension using create-contentful-extension and begin development

Using autoFocus prop

• In the generated DialogExtension component, add a TextInput component, passing the prop autoFocus
• When extension rebuilds, click the button that opens the dialog

Expected: TextInput automatically focuses, enabling typing immediately
Actual: TextInput does not focus, requiring a click to begin typing

Using inputRef and focusing in componentDidMount

• In the generated DialogExtension component, add a constructor:

 constructor() {
    super()
    this.input = React.createRef()
  }

• and a componentDidMount:

  componentDidMount(){
    this.input.current.focus()
  }

• In the Text input, pass this.input as the inputRef prop to the TextInput component

• When extension rebuilds, click the button that opens the dialog

Expected: TextInput automatically focuses, enabling typing immediately
Actual: TextInput does not focus, requiring a click to begin typing

You can confirm refs are passing correctly by adding a Button component with the following onClick prop:
() => this.input.current.focus()
Expected: On click, input gains focus
Actual: On click, input gains focus

We need to add selected?: boolean for those components.

In general, it would be nice to extend CardProps to avoid duplication / or missing type problems between AssetCard / EntryCard / Card components.

👋 F36 community!

I would like to propose to create Flex component for F36. I think there might be cases where we add additional styles just to add flex and position elements with it, or maybe to add flex and specify spacing between elements. It might be useful to have a generic component in the library that could do it for us, like <Flex />. I know that we have <Grid /> already, but I guess there is still room for <Flex /> to handle less complex cases. Flex is still very much in use and it's good to have a choice between those 2 components in the library, in my opinion.

Flex component potentially could take following props:

We could also have options for margins suited for using spacing tokens only:

The proposed solution

At the end this component would end up as something like this:

<Flex
  direction="column"
  alignItems="center"
  justifyContent="center"
>
  <Flex marginRight="spacingL">I have 24px margin on the right side</Flex>
  <OtherComponent />
</Flex>

I'm curious WDYT, thx for any comments or feedback 🙂

I recently made https://github.com/BKWLD/contentful-color-selector and it's small enough to be installed via srcdoc. I read on https://github.com/contentful/forma-36

Forma 36 was designed to use ‘Avenir Next’ as primary font family. If a package is used in the context of app.contentful.com (e.g UI extensions) this font will be provided.

However, I'm not seeing it. I added the f36-font-family--sans-serif class to the body of my component in an attempt to set the font-family correctly: https://github.com/BKWLD/contentful-color-selector/blob/master/src/index.html#L7. I'm loading that CSS here: https://github.com/BKWLD/contentful-color-selector/blob/master/src/index.js#L11.

I have an example of this UI Extension in use here: https://app.contentful.com/spaces/vrkkgjbn4fsk/entries/1VfqdjOBbin8EO6hwalKrU. Here's what it looks like in Chrome:

Here is Chrome's computed styles:

Should I be able to see Avenir here? I want it to be transparent to my user's that they're using a custom field.

Thanks!

Hey F36 Community 🖖

with Forma 36 4.0 approaching we suggest a new project structure that will change the way how we organize and publish react components.

Description

As you're aware we currently manage all components in a single package forma-36-react-components which many times was challenging to us in terms of resulting bundle size and SLA's (alpha components)

To offer more flexibility around component management we envision the future project structure like this.

Packages Structure

└── packages
    ├── components
    │   ├── forma-36-react-button
    │   ├── forma-36-react-dropdown
    │   └── forma-36-react-textfield
    ├── forma-36-fcss
    ├── forma-36-react-components
    ├── forma-36-tokens
    └── forma-36-website

The main difference is that every component will be its own package which means that every component will also be published separately. As I see it the main benefits of this structure are:

1. Atomic imports. The consumer can import just the components they need and not the entire bundle.
2. Independent component versioning
3. Component-based SLA's (alpha components, experimental components)

We'll still keep the forma-36-react-components package as a facade package that imports all components, creates one bundle and also serves the storybook docs.

Any feedback is much appreciated!

Thanks ❤️

Johannes

We came across isssue in our documentation:

Error is coming from components package, we would need to get rid of no-explicit-any from there I guess. For now I added .eslintrc on the documentation side to make it work, but I guess it should not be handled this way.

The problem

The Notification component currently fail WCAG colour contrast accessibility guidelines:

Notification with success intent:

Element has insufficient color contrast of 2.99 (foreground color: #ffffff, background color: #0baa75, font size: 10.5pt (14px), font weight: bold). Expected contrast ratio of 4.5:1

Notification with warning intent:

Element has insufficient color contrast of 2.85 (foreground color: #ffffff, background color: #db8500, font size: 10.5pt (14px), font weight: bold). Expected contrast ratio of 4.5:1

The proposed solution

I'd like to propose some changes to these components to make sure we can consistently meet accessibility guidelines by not setting text on a solid-colour background.

Here are some mockups of what I'd like to implement:

Success

Warning

Error

Forma 36 bug report

Summary

The DropdownList that appears when you click on the context menu icon (3 dots) of the last item in the folder view of the content page (https://app.contentful.com/spaces/{:spaceId}/entries) is cut off of the screen in smaller resolutions, as in the screenshot (unless you zoom out your browser window).

This has as a result that the user cannot click on the Delete button which is the last item in the dropdown list.

Environment

Latest chrome on osx

Steps to reproduce

1. Go to https://app.contentful.com/spaces/{:spaceId}/entries.
2. Find the last list item in the folders view.
3. Click on its context menu button (3 dots)
4. See the dropdown list which is off the screen limits

Expected results

DropdownList is within screen limits and I can normally interact with it.

Actual results

DropdownList is off screen limits and I cannot normally interact with it.

Hi 👋

I'd like to propose a date and time formatting guideline in the Copy section of the Guidelines.

Currently, whenever we need to show a timestamp we lack guidelines on how to show it:

• what format to use? US / UK / International?
• absolute or relative time? is "Today" enough?
• 12-hour or 24-hour? should am / pm be written in lowercase or uppercase?

I'm developing a custom UI extension in which I am using the Forma 36 React Components.
I'm constantly getting the following warning/error;

How should I handle this, 'cause it's a warning/error inside a component that gets automatically generated by the Note-component that I'm using?

Hi,

I'm using forma-36-react-component in leatest ui-extensions. I think it's a great work 💪 !

The problem involve the <ReferenceCard /> component.

In version 2.0.1-alpha.0 the component it's smooth and beautiful:

But in version 2.0.2...

How you can see there is:

• giant font size;
• useless empty space for missing description.

Is it possibile to go back to previus verision? Or can you show me another solution?

Thanks,
Vincenzo

Hi 👋

I noticed that notifications can be sticky when moving the mouse fast, which can be irritating.
This seems to only happen in a more complex application which puts some demand on the browser.

Forma 36 contribution proposal

The problem

There are no existing icons in the library we could use to represent references and tags.

The proposed solution

Use the Local offer and Account tree icons from Material Icons
https://material.io/resources/icons/?icon=local_offer&style=baseline
https://material.io/resources/icons/?icon=account_tree&style=baseline

Breaking changes

No

If the Tooltip is used in a Modal component the z-index of the tooltip is lower then the z-index of the Modal which results in the tooltip being invisible.

Hi,

We had some issues concerning Modals with moderate amounts of content in small windows and the resulting overflow.
Setting allowHeightOverflow to true fixed that for us and it seems there are actually no downsides to setting it.
Should it be set to true by default?

Would be great to be able to create modals which take the entire width of the screen (minus some margin)

Workaround: set the width to 5000px so the modal grows as much as possible but thats rather dirty

Hello Lovely F36 Community 👋

I'm proposing a new Grid component to ease the overhead for developer to write their own layout css.

Overview

• Built on CSS Grid
• Fluid Grid (columns width is relative to the container width)
• Grid Playground - Alpha CodeSandbox
• Fun way to learn css grid: CSSGridGarden

The Grid consists of two components Grid and GridItem :

Grid Component

Represents the Grid container

GridItem Component

Represents the Grid Items

The component usage would be something like this...

<Grid columns={12} rows={3} columnGap={'xs'}>
  <GridItem rowStart={1} rowEnd={2}>
    <p>I'll be in column 1, row 1</p>
  </GridItem>
  <GridItem rowStart={3} columnStart={2}>
    <p>I'll be in column 6, row 2</p>
  </GridItem>
</Grid>

Question

• Shall we introduce optional breakpoints, and make the grid responsive ready?

Let me know what you think 😊

Forma 36 contribution proposal

The problem

In a nutshell: Skinning nested components.

In some cases, you want to apply custom styles to a rather complex component E.g. Autocomplete.

With the current system, the only way to access underlaying components like Dropdown is by CSS selectors of standard html tags (div, ul, li and so on).

The CSS classNames currently used are driven by emotion and don't provide predictable classnames.

(Please correct me if i'm wrong, i have a very limited experience with emotion)

The proposed solution

A dedicated className per component following a standardized f36 convention (tbd).
In case of Automcomplete, it could look like this:

.my-custom-autocomplete .f36-dropdown .f36-dropdown-container .f36-dropdown-list {

}

This would enable more control over nested (not directly accessible) components.

If this could be a way to solve the issue, what would be a good (naming) convention?

Breaking changes

I don't see any breaking changes with this.

First list works. Second list causes an error because we pass the style prop to the ul html tag.

Ideally a List with style="disc" should create a bullet list by appling the value of the style prop to the items as list-style: disc;

The problem

As we expand and scale, we see a rise in requests to add more icons, whether the user is building a feature in Contentful web-app, a separate app or an internal tool, etc.

With the current structure adding more icons will increase the bundle size, and it also increases the overhead on the maintainers to follow up on what goes in and out.

The proposed solution

Moving all icons to a separate new package @contentful/forma-36-icons where users can import only what they need as svg which will get inline within their bundle

This way we can have a huge icons library without worrying about f36 or consumer's bundle size as they only get what they ask for.

Adding extra icons would be simpler, and doesn't require much reviews

Removing icons in the future won't be necessary, and we could avoid potential breaking changes, and easily support backward compatibility

Usage example

import { search } from '@contentful/forma-36-icons`
import { Icon } from '@contentful/forma-36-react-components`

<Icon color="primary" size="m" icon={search} />

Breaking changes

This change will eventually require forma-36 to remove the current icons from our bundle, and consumers will need to migrate accordingly

Other thoughts

Possibly we could upload these SVG icons to S3 bucket and keep only reference inside the package for faster builds?

Description

I identified a problem with the Forma 36 Tooltip component used in the CopyButton component.
I'm not sure if this is a problem with the Tooltip in general, or just inside the CopyButton.

Steps to reproduce

• add CopyButton component.
• hover copyButton instance.

Expected behaviour

• click on copy button component shows "copied!" tooltip with tooltip center on button.

Actual behaviour

• click on copy button component shows "copied!" tooltip with tooltip on former position.

My 5 cents on what happens:
In the described case, the tooltips position doesn't get recalculated when a new content is set.

Please let me know if you need any more information!

Hi there, I've a small note on Switch component...
Label is defined as a <p /> tag. Using label tag is semantically valid, and enables accessibility out of the box.
Happy to contribute, if you guys are okay with the approach!

Description

Our current designs requires an additional last (fixed) item inside an extra DropdownList regardless of the rendered content. This behaviour is possible with Dropdown component, but not with Autocomplete.

Currently, Autocomplete wraps all given children with a DropdownListItem inside a DropdownList.

Expected behaviour

<Autocomplete>
  <DropdownList>
    <DropdownListItem>
      <span>list item 1</span>
    </DropdownListItem>
    <DropdownListItem>
      <span>list item 2</span>
    </DropdownListItem>
  </DropdownList>  
  
  <DropdownList border="top">
    <DropdownListItem>
      <TextLink href="http://contentful.com">This is a Link</TextLink>
    </DropdownListItem>
  </DropdownList>  

</Autocomplete>

Actual behaviour

<Autocomplete>
  <DropdownList border="top">
    <DropdownListItem>
      <span>list item 1</span>
    </DropdownListItem>
    <DropdownListItem>
      <span>list item 2</span>
    </DropdownListItem>
    <DropdownListItem>

      <DropdownList border="top">
        <DropdownListItem>
          <TextLink href="http://contentful.com">This is a Link</TextLink>
        </DropdownListItem>
      </DropdownList>

    </DropdownListItem>
  </DropdownList>
</Autocomplete>

Please let me know if you need any more information!

Forma 36 bug report

Summary

Not a bug per se, but we're currently missing documentation for how to use alpha components.

Environment

Steps to reproduce

Expected results

Actual results

I would like to propose an extension to the Table Component (more specifically the TableBody)
The case is that, in some places, we fill tables with async data, right?
Well, one way of dealing with that would be, let's say, showing a spinner in the page and only after the data is fetched show the table.
A better pattern for the users would be mimicking the final look of the table after with the Skeleton Component that forma already have (take a look on the gif ⬆️ ).

Initially, my idea is that we could pass a bool prop to TableBody and while this is true we render a "SkeletonRow" instead of the TableBody's children. Something like:

<TableBody loading={true}>
    <TableRow>
        // ... n TableCells here
    </TableRow>
</TableBody>

And in /TableBody.js

<tbody data-test-id={testId} className={className} {...otherProps}>
    {loading ? <SkeletonRow /> : children}
</tbody>

This would render a pretty standard skeleton row. In case the table needs a more personalised skeleton setup, you could do it without the prop by just setting the load yourself as a children (I guess... more cases will show up as this gets developed hahaha)

This is just an initial thought and I would love to know what you think about it.
And if we can already have some suggestions 😄

Hey Forma 36 Fam ✌️

I'm proposing a package that will provide 3 components to format date and time absolute and relative following our guidelines: https://f36.contentful.com/guidelines/date-and-time/

The components would look something like this:

import { FormattedDate, FormattedRelativeDate, FormattedTime } from '@contentful/forma-36-react-formatted-date-time'

<FormattedDate date={new Date()} /> // 13 Aug 2019
<FormattedRelativeTime date={new Date()} /> // 4 hours ago, today, 2 days ago, 3 weeks ago, 4 months... 
<FormattedTime date={new Date()} format="12" /> // 12pm

WDYT? Any feedback is much appreciated!

🖖

Navigation styling

• There should be a hover state on the menu items
• There shouldn't be such a strong difference between the items that have children
• There's not really a need for a background color in the navigation — if we set it to white it would improve the contrast

Search

The position of the search right above the website navigation is a bit misleading — it implies that it's a filter for navigation items, rather than a fully powered search across the whole website. I suggest we put the search in the top bar and trigger it with a button.

Decided to leave the search as it is for now.

For tree shaking (thus smaller bundle sizes) have you considered instead of distributing only a styles.css to also publish the source code?

In some cases if I only import <Button> I'd like to avoid including in my UI extension the CSS for all components.

The type definition for @contentful/forma-36-tokens states that tokens is a default export, which leads the TS compiler to expect import tokens from '@contentful/forma-36-tokens'; to be the syntax, but this fails at runtime. The correct syntax to make the app run is import * as tokens from '@contentful/forma-36-tokens';, but that causes a compiler error because of the type definition.

Hey lovely people 👋

I'm here with another proposal about date components.
One artifact of the brand new scheduled publishing feature is 3 UI components to enter and select dates, time and timezones. I want to move these components to Forma 36 for you to reuse so I'm proposing a new package called forma-36-react-date-components.

This package will include the following components:

DatePicker

TimePicker

TimezonePicker

FormattedDate -> Utility component the formats date in Forma-36 compliant formats

Why is this a new package?

These components will have a peer dependency on moment.js (or date-fns up for discussion..) which I don't want to force the consumer of our forma-36-react-components package to install.

Ideas & comments are as always much appreciated ❤️

Thanks!

Hi all,

Description

There is an easy win out there called tether see docs and source. The library focuses on the very specific problem of attaching an absolutely positioned element to another.

Pros

• Solves one problem and it does it well
• Well maintained since major components depend on it
• Great API and docs

Cons

• Yet another dependency
• Adds 5kb gzipped

Since I'm working on porting the Autocomplete we can have an example using tether which might help towards a decision.

Your awesome point of view is an absolute must ;)
Aris

I am creating a Contentful UI extension and I'm using the forma-36-react-components and its styles. I am using Select-component and a Note-component underneath eachother, but that gives me the following result:

I would like some margin between these components, but I haven't been able to override these styles.

I would be nice to increase a clickable area of this button to improve usability and a11y. As for me, that click at right right corner should always trigger an action. Right now I miss almost every second time.

Hello folks!

I happen to look into forma-36-react-components styling out of interest.
My compliments. All looks very nicely structured.

I noticed a couple small issues regarding CSS variable references. Just to let you know:

• color-blue-base reference
  I noticed the following: background-color: var(---color-blue-base); in
  

  forma-36/packages/forma-36-react-components/src/components/Button/Button.css

  Line 87 in 7c91f8a

  background-color: var(---color-blue-base);

  It looks like color-blue-base CSS variable is referred to with three dashes instead of two.

• glow-warning reference
  I also noticed var(--glow-warning) does not exist in https://github.com/contentful/forma-36/blob/master/packages/forma-36-tokens/src/tokens/box-shadows/glows.js

Hey F36 Community 👋

I'm proposing a new component that will reduce the overhead of writing CSS for spacing purposes. I many times see the same code being written to add margins and paddings, and I think we'd benefit from a Box component that will add a spaced box around its children. This component would simply expose padding and margin CSS properties to be set with our tokens.

Box PropTypes

<Box paddingTop="xs" margin="l" element="span">
  {children}
</Box>

Let me know what you think 😊

Is there any reason that you're not exporting TableSortingLabel from index.tsx? This causes missing css style even though I can import the component like this way: import { TableSortingLabel } from '@contentful/forma-36-react-components/dist/components/Table/TableCell';.

When using TypeScript and react in interface of Text Input doesn't exist the events(onKeyPress, onKeyDown, onKeyUp). In this case I need to capture the enter key in an input to get the value and add this value to the state of component.

When I set an href attribute on the Button component, with a buttonType="primary" I get a gray border as opposed to the normal bluish border.

See screenshot below:

Bug is reproducible in forma-36's storybook, if you set the href prop.

Forma 36 bug report

Summary

It can be reproduced on the Storybook if you add something like this abomination as a text

Hello world jashjr hjqwh4j 23ghjgh4 g2hjghj21gh3zg21hg3auh21tbyu321yfb3yd12av3ruy21svyu312vyu32ayv3rty21vr3ty12rdyu3v12vg3cb12g3h g12hj fegwfghrfwghrfg3f4gh2fg4f12gf3g12f4yut21361245261853675126451267t3yu12feghasftefaster6w5467521ytesagertw4567254uygdshatdyas

Environment

Latest Chrome, (v83), latest MacOS 10.15.5

Steps to reproduce

Described above

Expected results

No transparent background.

Actual results

(with a different background for better visibility)

I'm using the EntryCard component and trying to add a DropdownList to edit and remove entries.

The DropdownList position seems to be calculated incorrectly or I'm missing something

`return (

    <EntryCard
      title={colorName.en}
      contentType={sys.id}
      thumbnailElement={
        <div
          style={{
            height: '100%',
            width: '100%',
            opacity: opacity || 1,
            background
          }}
        />
      }
      dropdownListElements={
        <DropdownList>
          <DropdownListItem isTitle>Actions</DropdownListItem>
          <DropdownListItem onClick={() => {}}>Edit</DropdownListItem>
          <DropdownListItem onClick={() => {}}>Remove</DropdownListItem>
        </DropdownList>
      }
    />
  );

`

Forma 36 contribution proposal

The problem

In the feature that I'm working on we had to create a FAQ section for a page. But the content of around 6 questions is quite long to be always on the page, also a user may want to know about one thing only so scrolling over the other 5 questions would be annoying or make the user miss what they a looking for.

The proposed solution

Let's create an Accordion component. It would also need an <AcordionHeader /> and an <AcordionPanel />

prototype

Accordion Header:
Label for or thumbnail representing a section of content that also serves as a control for showing, and in some implementations, hiding the section of content.
Accordion Panel:
Section of content associated with an accordion header.
(taken from WAI-ARIA)

Chevron variation

We could have a prop to define two different alignments for the chevron

Hover/Focus state

For hover and focus state we can use the same styles we use in the naked button

Considering the case where the accordion has a gray background, this is how it would look

Usage

The component allows other components to be passed as a title for the accordion, but it is better to avoid abusing this feature. In most cases, a Heading or Subheading component will be enough.
It's worth to point out that there is a case in Contentful's webapp where we have a ... button in an accordion header. I propose that his pattern should not be supported because it harms the accessibility of the component. The reason for this can be checked in the W3 docs for accordions

• The title of each accordion header is contained in an element with role button.
• Each accordion header button is wrapped in an element with role heading that has a value set for aria-level that is appropriate for the information architecture of the page.
  • If the native host language has an element with an implicit heading and aria-level, such as an HTML heading tag, a native host language element may be used.
  • The button element is the only element inside the heading element. That is, if there are other visually persistent elements, they are not included inside the heading element.

Important requirements

• Accessibility following WAI-ARIA
• Possibility to pass other components to the Accordion Header

Breaking changes

Uhmmm I don't think there is any breaking change, but maybe we would release it as an alpha component first

Proposal

I'm proposing a change to the Notification component to allow rendering a title, body, and a CTA.

Approaches

Currently, the Notification component is called like so:

Notification.success('Text content of notification (string)', {
  duration: 6000 (int)
  canClose: true (boolean)
})

I can think of two approaches to achieve this:

1. Change the text to accept any node

Example usage:

const message = (
  <React.Fragment>
    <Heading>Notification title</Heading>
    <Paragraph>Some notification body copy</Paragraph>
    <TextLink href="#">Some CTA</TextLink>
  </React.Fragment>
);

Notification.success(message, {
  duration: 6000 (int)
  canClose: true (boolean)
})

Pros:

• Minimal changes required
• Uses exactly the same API to render content as before

Cons:

• Could end up with many different variations
• Need to refer to an example to know how to best construct message (could create NotificationTitle/NotificationBody/NotificationCta components though)

2. Add explicit props

Example usage:

const message = (
Notification.success('Body text content of notification (string)', {
  title: 'Message title' (string),
  cta: {
    label: 'CTA title (string)',
    action: '() => {blah} (function)'
  }
  duration: 6000 (int)
  canClose: true (boolean)
})

Pros:

• Complete control over how component renders
• TypeScript will show API usage hints

Cons:

• Slightly confusing API (mix of strinng for body and settings object for title and CTA)
• Slightly more involved changes needed