If you are a web developer, you know about the `type` attribute you can use on the inputs element to specify the type of data users should enter into a form. There are several different types of values, and each value can change the type of keyboard that appears to the user. For example, using `type="tel"` will make the telephone input keyboard appear on a mobile device.

![tel-input-example.png](https://eu-central-1.graphassets.com/APV1UbHpTTp6Nv6PxQmvGz/KaFYc11jQuebaIhRK4xv)

Many and many web developers use `type="number"` when they want the user to enter a number. That’s because it brings up a keyboard that displays numbers.
The vast majority of web developers when wanting the user to enter a number. However, there’s a problem with this practice. 

The number type should only be used for *amounts*. An amount is equivalent to a price or number of items. The (mis)use of `number` for other kinds of numbers is considered a good user experience. However, this type is not well supported by assistive technology like screen readers.

## A better approach

So, what we can do to bring up a number keyboard that’s similar to the telephone keyboard, but accessible by screen readers? The answer is by using the `type="text"` attribute combined with [`pattern`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-pattern) and [`inputmode`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-inputmode) to force the correct keyboard, keeping the field accessible.

```html
<input type="text" pattern="[0-9]*" inputmode="numeric">
```
![number-input.webp](https://eu-central-1.graphassets.com/APV1UbHpTTp6Nv6PxQmvGz/pC01blOKSpiKzFEpYqlD)

We encourage developers to switch to this method to ensure the best user experience and to make sure it’s accessible to all users.


How to handle numeric fields.

The Card component is one of the most common patterns used across digital web products, no matter the size or the complexity of the project. If done correctly, this component can be handy to aggregate data and reduce the cognitive load of the user who's using the product.

Let's see how to build a custom and accessible card component with actions, images, and data inside.

## Card foundations

Our card component contains any content we want to pass inside. While there are many ways to create to align and style the content inside, we will use the components from the design system. Start by importing the empty [Card](/components/layouts/card) component from Wanda.

```tsx
import {Card} from "@wonderflow/react-components"

<Card bordered>
  Content
<Card>
```

Now we have our card element with all the predefined properties, padding included. Since we want to add an edge-to-edge image inside, we need to remove the padding from the Card component and put our image as content.

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
  </Card>
</LiveArea>

```tsx
import {Card} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
</Card>
```

<Snackbar icon="circle-question">
Learn more about [`loading`](https://web.dev/learn/design/responsive-images/#loading-hints) and [`decoding`](https://web.dev/learn/design/responsive-images/#image-decoding) attributes.
</Snackbar>

## Adding some content

It's important to add some content inside our card in order to provide meaning and describe the card itself, what it represents. Let's proceed by using some Wanda components like [Stack](/components/layouts/stack) , [Title](/components/typography/title), and [Text](/components/typography/text).

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
    <Stack>
      <Title level="5">Madonna di Campiglio</Title>
      <Text dimmed={6} size={14}>October 31, 2021</Text>
    </Stack>
  </Card>
</LiveArea>

```tsx
import {Card, Stack, Title, Text} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
  <Stack>
    <Title level="5" />
    <Text dimmed={6} size={14} />
  </Stack>  
</Card>
```

<Snackbar kind="info">
Wanda's `Title` component decouples the visual style and the semantic. In this case, `Title` uses the h5 style (set by the `level` property), but it's rendered as a span (the default value for `Title`). To render the component with a different semantic, use the `as` property
</Snackbar>

Wait. Our content is placed near the edge of the card since we removed the padding around the whole container. We need to restore the padding only for the content and not the image. To do so, we can use the `Stack` 's properties to add horizontal and vertical padding. We also need to add some space between the title and the date; the Stack component provides all the necessary to handle our needs. Let's fix this.

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
    <Stack rowGap={4} hPadding={16} vPadding={16}>
      <Title level="5">Madonna di Campiglio</Title>
      <Text dimmed={6} size={14}>October 31, 2021</Text>
    </Stack>
  </Card>
</LiveArea>

```tsx
import {Card, Stack, Title, Text} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
  <Stack rowGap={4} hPadding={16} vPadding={16}>
    <Title level="5" />
    <Text dimmed={6} size={14} />
  </Stack>  
</Card>
```

You can notice that we didn't write any `CSS` so far. Excellent, isn't it? That's because Wanda components provide all the tools needed to handle everyday situations. It tries to save you from thinking and building the same UI elements repeatedly to achieve common patterns and interactions.

## Adding some actions

Let's suppose we need to add a couple of actions to our card. We need to add another `Stack` component below the content following the previous approach.

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
    <Stack rowGap={4} hPadding={16} vPadding={16}>
      <Title level="5">Madonna di Campiglio</Title>
      <Text dimmed={6} size={14}>October 31, 2021</Text>
      <Stack>
        <Button>Primary</Button>
        <Button kind="flat">Secondary</Button>
      </Stack>
    </Stack>
  </Card>
</LiveArea>

```tsx
import {Card, Stack, Title, Text, Button} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
  <Stack rowGap={4} hPadding={16} vPadding={16}>
    <Title level="5" />
    <Text dimmed={6} size={14} />
    <Stack rowGap={4} hPadding={16} vPadding={16}>
      <Button />
      <Button kind="flat" />
    </Stack>  
  </Stack>  
</Card>
```

Because the `Stack` component puts elements one below each other, we need to change this behavior by using its `direction` property. We can also change the `fill` behavior to prevent Stack's children from filling all the available space and add a gap between buttons. 

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
    <Stack rowGap={4} hPadding={16} vPadding={16}>
      <Title level="5">Madonna di Campiglio</Title>
      <Text dimmed={6} size={14}>October 31, 2021</Text>
      <Stack direction="row" fill={false} columnGap={8}>
        <Button>Primary</Button>
        <Button kind="flat">Secondary</Button>
      </Stack>
    </Stack>
  </Card>
</LiveArea>

```tsx
import {Card, Stack, Title, Text, Button} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
  <Stack rowGap={4} hPadding={16} vPadding={16}>
    <Title level="5" />
    <Text dimmed={6} size={14} />
    <Stack direction="row" fill={false} columnGap={8}>
      <Button />
      <Button kind="flat" />
    </Stack>  
  </Stack>  
</Card>
```

## Fixing the visual hierarchy

Our card component is almost done, but we need to fix the visual hierarchy between content and actions. You can notice that right now, there is no cognitive distinction between the card content and the actions, making all of them perceived as a single and aggregated "block" of content.

This result is caused by the `rowGap={4}` property we set earlier since our buttons Stack is a direct child of the previous one. We can add space between the actions and the date text to fix this by following a couple of ways:

- Adding `vPadding` to the `Stack` containing the buttons.
- Adding another stack to wrap text content and actions, and set `rowGap`.

### With vertical padding

The quickest way to fix our issue, but it comes with drawbacks. By adding `vPadding` to the `Stack` that contains the buttons, we add space below the buttons (because that property adds a gap on the vertical axis, so on top and below the Stack) may not be the desired result.

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
    <Stack rowGap={4} hPadding={16} vPadding={16}>
      <Title level="5">Madonna di Campiglio</Title>
      <Text dimmed={6} size={14}>October 31, 2021</Text>
      <Stack direction="row" fill={false} columnGap={8} vPadding={32}>
        <Button>Primary</Button>
        <Button kind="flat">Secondary</Button>
      </Stack>
    </Stack>
  </Card>
</LiveArea>

```tsx
import {Card, Stack, Title, Text, Button} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
  <Stack rowGap={4} hPadding={16} vPadding={16}>
    <Title level="5" />
    <Text dimmed={6} size={14} />
    <Stack direction="row" fill={false} columnGap={8} vPadding={32}>
      <Button />
      <Button kind="flat" />
    </Stack>  
  </Stack>  
</Card>
```

### With an additional stack

To solve our issue best, we can add another `Stack` element inside the card to define the gap between text content and actions. We have to wrap the first `Stack` with another `Stack` element and move the `Stack` containing the buttons outside. Then we can add the `rowGap` and move both the horizontal and vertical padding on the newly created `Stack`.

<LiveArea hAlign="center" vAlign="center">
  <Card bordered padding={false}>
    <img loading="lazy" decoding="async" src="https://images.unsplash.com/photo-1635663684911-6b1a5d5affb9?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=400&q=80" />
    <Stack rowGap={32} hPadding={16} vPadding={16}>
      <Stack rowGap={4}>
        <Title level="5">Madonna di Campiglio</Title>
        <Text dimmed={6} size={14}>October 31, 2021</Text>
      </Stack>
      <Stack direction="row" fill={false} columnGap={8}>
        <Button>Primary</Button>
        <Button kind="flat">Secondary</Button>
      </Stack>
    </Stack>
  </Card>
</LiveArea>

```tsx
import {Card, Stack, Title, Text, Button} from "@wonderflow/react-components"

<Card bordered padding={false}>
  <img loading="lazy" decoding="async" />
  <Stack rowGap={32} hPadding={16} vPadding={16}>
    <Stack rowGap={4}>
      <Title level="5" />
      <Text dimmed={6} size={14} />
    </Stack>
    <Stack direction="row" fill={false} columnGap={8}>
      <Button />
      <Button kind="flat" />
    </Stack>  
  </Stack>  
</Card>
```

## Conclusion

With this pill, we saw how we could make a card component by only using the elements provided by Wanda without writing a line of `CSS`. Here's just an example of how we can save time and effort while keeping consistency across the whole UI, improving the speed and without sacrificing the overall quality.

Making a card component

Sometimes in a Layout, you want to add a little bit of contrast (anyone said marketing CTA?). 

Wanda supports light and dark themes out-of-the-box: this is especially useful to change the theme of just a specific component — and it's as easy as adding `data-theme="dark"` (or `light`). 

<LiveArea horizontalAlign="start">
  <div data-theme="dark">
    <Chip>I'm forced to dark mode</Chip>
  </div>
  <Chip>I change with the global theme</Chip>
  <div data-theme="light">
    <Chip>I'm forced to light mode</Chip>
  </div>
</LiveArea>

### How is it possible?

Wanda's `themes.css` includes both the light and the dark theme, make sure to import it in your entry point — [More info on the dedicated page](https://design.wonderflow.ai/develop/using-themes/#light-and-dark-themes)

```js
import '@wonderflow/react-components/themes.css'
```
```html
<footer data-theme="dark">
  ...
</footer>
```

<Snackbar kind='info'>Unfortunately getting the opposite scheme of the system scheme is not supported out of the box, it's something that requires some custom Javascript</Snackbar>


## A real-world example

On the Wonderflow website, we use the light theme as our theme. The footer uses the forced data-theme to dark — this way we get for free a curated dark color schema with no need to write additional custom CSS.

![forced-theme.gif](https://eu-central-1.graphassets.com/APV1UbHpTTp6Nv6PxQmvGz/jOWGGNOoSCuP1BkSAEbK)


Force a light or dark theme

Wonderflow's design team is happy to announce the opening of a new section called **Learn**. The goal of this new learning area is to provide a way to teach others about day-by-day tasks, from design to UX. We want to establish a direct channel to talk with our design system users.

## What you'll find

Here you'll find bite-sized content, just like your Social network feed has used you to. We'll talk about anything related to Wanda: from design to development.

Here are some examples:

- Short and specific how-to tutorial (eg: [Figma: Frame vs Group](/learn/frame-vs-group-in-figma/))
- Specific tutorial about Wonderflow company (eg: [How to use and where to find Wonderflow logo](/learn/using-wonderflow-logo-consistently))
- Re-post some valuable online articles

## Who are these articles for

At Wonderflow we think it's time to destroy hard boundaries between roles and definitions. For us, the term **design** means a lot more than just "drawing things on a monitor". That's why on this website you will find content for UI developers, designers, and UX researchers.

Some content under the **design** category may include details for developers too, while some more technical content made for developers may include useful information about how to handle a design.

**So don't be afraid of clicking and learning something new that may help your day-by-day work. 🤗**

Introducing the Wanda's Learn section 🎉

If `z-index: 99999;` is something you write often when you work with CSS, this story is for you. We will see how to handle the stacking context and the `z-index` property in your CSS.

## Stacking context

This term indicates a three-dimensional conceptualization of the HTML elements that are stacked across the imaginary z-axis, based on some attributes these elements can stack on top of each other or inherit properties from their parents.

A practical and common example of this is the CSS `opacity` property. When you apply this property to an element, every child element, at any level, will be rendered with the same opacity level. This property will cause the element to create a stacking context.

Let's see what CSS properties and HTML elements trig a stacking context:

* The `<html>` element
* Element with `position` set to `relative` or `absolute`
* Element with `position` set to `fixed` or `sticky`
* Element that is a child of a `flexbox` or `grid` container
* Element with `opacity` value less than **1**
* Element with `mix-blend-mode` different from `normal`
* Element with `transform`, `filter`, `perspective`, `clip-path`, `mask`, `mask-image`, `mask-border` with a value different from `none`
* Element with `isolation` set to `isolate`
* Element with `-webkit-overflow-scrolling` set to `touch`
* Element with `contain` set to `layout` or `paint`, or keywords that include them, like `contain: strict` and `contain: content`
* Element with `will-change` that specify one of the above properties

While most of the above conditions can be rare, let's take the most common one: an absolute-positioned element inside a container. When we want to set the coordinates of an absolute element and make them relative to a parent boundary we add `position: relative` on that parent element, creating in fact a stacking context (see the second point above)

You can consider the stacking context as a **virtual cardboard box** seen from the top, that stacks elements inside it, but without any solid boundaries.

## z-index and voodoo magic

The `z-index` property lets you define the position of the element across the Z-axis, inside a stacking context — from here referenced as "_box"_. If you take two real cardboard boxes, you know that you can put one on top of each other, and you can put many elements inside each of them. The elements that are inside the upper box will be positioned (or rendered speaking of CSS) above the elements that are inside the underlying box. The only difference is that in CSS, these boxes haven't "solid" boundaries, and elements can overflow outside them.

Let's take this markup structure:

```html
<div class="A">
  <div class="One"></div>
  <div class="Two"></div>
</div>
<div class="B">
  <div class="Three"></div>
</div>
```

Here is the side visual representation of these two boxes, with some `CSS` applied:

![Side view of a visual representation of the CSS stacking-context](https://eu-central-1.graphassets.com/APV1UbHpTTp6Nv6PxQmvGz/qTJrzU5ST9eiky4XVZVU)

Are you still there? Now, follow me.

In the above image, `.A` and `.B` are our two boxes (stacking-contexts) and they are siblings inside the same HTML parent. The `.B` element is projected and rendered above `.A` cause of its `z-index` property, in this case, our `<HTML>` element is the container and the main context holder as stated in the first point of the above list.

Now, you can notice that `.B` is not the only element rendered above `.A`, but also his content, more precisely the `.Three` element. You can imagine `.One` and `.Two` as books inside our cardboard boxes. `.Two` is above `.One` but they still are both inside the box `.A`, and so rendered under the box `.B`.

Here is the visual representation of the same structure, but from the top view, or in other words, from the user's point of view.

![Top view of a visual representation of the CSS stacking-context](https://eu-central-1.graphassets.com/APV1UbHpTTp6Nv6PxQmvGz/lSwa0ebSICT9MVkkgX12)

For this reason, putting an [over 9000](https://i.imgur.com/Okh8Z8i.gif) z-index on the element `.Two` doesn't make it rendered above `.Three`, because it's inside a stacking context that has a lower priority compared to sibling elements and contexts.

## Handling indexes

The stacking-context system is pretty easy once you get it, the hard part is managing your `CSS` code and keeping it organized. My approach is to define one big document scope in which define a bunch of layers, and multiple smaller scopes when required inside each component.

### Global scope

In Wanda, we defined 4 layers of elevation, which means 4 `z-index` levels to use across the whole project, like for dropdowns, fixed headers, modals, and contextual popups.

Supposing to write a correct HTML structure, every element should start from level **0** (initial) by default, tooltip, and contextual dialogs will use the level **2**, dropdowns use the level **2** and so on. With just 4 levels of `z-index`, you can probably handle 99.9% of the use cases. The key is to assign the appropriate level to UI elements based on their role and usage inside the whole UI, alongside writing the markup in the right order.

[Click here to learn more about Wanda's elevations system](/design/foundations/elevations/)

### Smaller scopes

Each UI component is placed on the level `0` but they can define as many levels as required inside them. So if needed, each component can create a "private" stacking context in which handle its elements and z-indexes, all starting from the level `0` (or another) of the document scope.


CSS stacking contexts made easy

Learn more one [evilmartians.com](https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs)

How to favicon in 2022

### TL;DR:

Use Frames whenever possible.


#### Advantages of frames

- You can place a background-color
- You can assign different constraints to different elements (or ignore them by pressing <kbd>cmd</kbd> while resizing)
- Manage overflow with `clip content`
- Assign grids

Actually, there are some specific use cases when the groups come handy, and that's when you want to scale child elements, but not effects, strokes, or type

Frame vs Group in Figma

Wanda design system provides a full-featured Wonderflow logo designed to be used consistently across the projects and assets.

## Variants

The logo itself has two variants, and each of them are made for both `light` and `dark` colors.

### Full logo

The full logo is used when the brand communication is strong and prominent. It needs a big white space area around in order to keep the information readable.

![](/design/brand/full-logo-light.svg)

### Mark

The mark logo is often used when the brand identity should not be so prominent and when the is not enought room for the full logo.

![](/design/brand/mark-logo-light.svg)

### Icon

Icons are versions of the mark logo. The stroke is thicker in order to keep readability on really small sizes. They are used for example as tab icon inside web pages.

![](/design/brand/icon-logo-light.svg)

## General usage

**As a rule of thumb: use the full logo** — exception made : 

- use the Icon version when  the space is really a constraint (eg: favicon)
- use the mark version when there are multiple instances of the Wonderflow logo in the page/presentation 

## Downloads

You can find and download the official Wonderflow logo  from the [brand page](https://design.wonderflow.ai/design/brand/#resources). You'll get both light and dark versions, in the following formats `svg` and `png`.
