docs(fluid): remove "fixed" term

[aagonzales]

Update to replace the term "fixed" with "default."

Effected pages

• Button
• Date picker
• Dropdown
• Number input
• Search
• Select
• Text input
• Read-only
• Login

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
carbondesignsystem	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 17, 2023 at 7:50PM (UTC)

[laurenmrice]

Button (Usage tab)

These sections still reference fixed in the heading and places in the body copy.

Date picker, Dropdown, Number input, Search, Select, Text input (Style tab)
There are references to Fixed still throughout these tabs.

Login pattern
These sections still reference fixed in the body copy.

[jeanservaas]

Sorry, It's too complicated to use the Jan method here... Addressing Lauren's comments above for button... this is what I would change:

Button changes

Note: these are not all consecutive paragraphs, I just addressed the spots where "fixed" was used

Question: In general, would it make more sense to use the term "fluid-width default buttons" vs. "hybrid fluid buttons?"

Fluid vs. default buttons
Button alignment is also closely related to whether the button is treated as a default or a fluid element within a layout. When we say “fluid”, we mean that the button becomes a part of a larger, compound component by bleeding to two or more edges of its container. Rather than defining the a fluid button’s width in columns or mini units, its width is defined as a percentage (often 50%) of the container’s width. Also, as a general rule, fluid primary buttons are never left-aligned in a layout or a container—they’re always either right-aligned, or span the full width of the container.

Fluid components like button never exist in isolation. As you can see in the examples above, they are always part of another component, like modal or form. Other fluid components include tiles and most recently, text inputs.

Fluid-width default buttons
The default button’s width is set to the size of the text label with 64px fixed padding on the right side and 16px fixed padding on the left. However, there is a hybrid scenario where a floating default-style button can span a designated number of columns on the responsive column grid, giving it a fluid width. These are called "fluid-width default buttons."

Fluid-width default buttons are always preferable to fixed-width default buttons in a layout. When possible set the default button container’s relative position to the responsive layout grid and match button width to the width of other elements on the page. Ideally, when using groups of related buttons (not including ghost buttons), they should all be the same width. See button groups below for more detailed information.

Stacked button groups
Typical landing pages for product have buttons side by side. However vertical button groups are also common in products, to save real estate in narrow columns and occasionally side panels. In these instances, the primary button is always on top and the secondary or tertiary button is below.

Generally, when designers stack buttons, they tend to use the hybrid fluid buttons. However, stacked fluid buttons are also an option in desktop side panels with especially long calls to action. Note: experimenting with stacked fluid buttons would require an override to the existing code.

Login changes

Separate authentication methods

If distinguishing between the authentication methods in the background is not technically feasible, provide users buttons to the various paths upfront. Consult your product team’s guidance to determine which alternative logins your platform or product offers.

Default text inputs and buttons should be used for this design so that the primary button can maintain its position next to the input field. See the Fluid vs. default inputs section below for more specific usage guidance. Also, please refer to brand guidelines when using logos for alternative logins. Examples of brand guidelines for a few commonly used alternative logins include:

(Under client-side verification)

Whether you are using default or fluid text inputs in your login flow, inline error messages should be displayed below any required field that is empty once the field loses focus or an action button (“Continue” or “Log in”) is clicked. See the fluid text input specs for more information on error states. Once the field is filled, the error message should disappear.

Fluid vs. default components

Although the fluid inputs have not been added as a variant to Carbon core components yet, they have complete design specs and are currently under development. Since many product teams have expressed interest in using the fluid inputs for Login and Sign up flows, the Carbon team wanted to consolidate exploration and present a clear path forward. What we have presented above is the ideal future state of the login pattern.

However, since a coded variant does not exist for fluid inputs, many teams may choose to proceed with the default inputs. Below are several alternate examples illustrating the login flow with default inputs.

Fluid buttons and inputs require floating containers, whereas default buttons and inputs can either sit on the page, without a container, or sit in a side-aligned full bleed container (much like a panel).

Example of a log in flow using default text input components

Designing for multiple alternate logins

As mentioned above, we prefer that the system distinguishes the path a user needs to take in the background rather than making them choose in the UI. However, with certain products, that’s not an option. In order to present multiple alternate logins to the user up front, designers must use default text inputs and default buttons so that the primary button can remain close to the input field.

Be mindful of the hierarchy and avoid layouts that emphasize alternate logins over the preferred login path.

Position

Carbon provides best practice advice on the login pattern but will leave more specific design guidance to the product teams. For instance, decisions like where to position the login flow on a page (i.e. left, right, or center), or whether to use fluid or default inputs, can be made at the product team level as long as the fields remain on the grid. Designers can also choose whether to incorporate brand-approved background textures, illustrations and/or marketing content. Visit the IBM Brand Center for specific guidance and approved assets relating to your brand and/or sub-brand.

Fluid login form

The fluid login form has consistent margins regardless of its width on the grid or whether it uses fluid or default inputs. When the password input appears in place of the username input, all of the spatial relationships remain the same, even though certain options (for example, “Remember ID” and alternate logins) disappear. This prevents an awkward resizing or jumping during the animation.

Specs for margins and vertical spacing in a centered login form with default input

Default login form

The default login form may or may not appear within a container and margins will vary according to its location on the grid. Adhere to the vertical spacing in the specs below regardless of the container.

If teams choose not to use “Remember ID” (which is optional), they can simply remove the 24px margin top along with it, to adjust the spacing.

Specs for margins and vertical spacing in a split-screen login form with default input

[aagonzales]

@laurenmrice Ok updates are made! I did not update image file names so "fixed" may still appear in a search do to that OR on the style tab because of the image component's name.

[laurenmrice]

Looks great! ⭐️