inbn Component Gallery

The Rating component serves two distinct purposes depending on your requirements:

1. Non-interactive Display: Used to show a single user's rating or an aggregate score (e.g., for a product or service) without allowing user input.
2. Interactive Input: Used to allow users to set their own star rating.

You can implement one or both functions within a single use case.

Do not use <a> tags or non-focusable elements like <div> or <span> to mimic buttons.

• Links (<a>): Users expect links to navigate to a new URL or anchor. Using them for actions breaks expectations like 'middle-click to open in new tab'.
• Non-focusable elements (<div>, <span>): These are inaccessible to keyboard users because they do not appear in the tab order.

If you must use a non-native element, you must manually implement tabindex="0", ARIA semantics, and keyboard/touch event listeners to match native <button> behavior.

Before implementing a carousel, evaluate these more accessible and efficient alternatives:

• Grids: Use a grid layout (like a Gallery) to show all items at once. This is highly accessible and allows users to make informed choices immediately.
• Accordions: If the goal is to save vertical space, use an Accordion. Accordions use the native HTML <details> and <summary> elements, which are accessible with minimal CSS and zero JavaScript, and provide headings that summarize content.
• Single Slide: If certain content is high priority, consider showing only that content rather than hiding it behind a carousel.

A rich text editor is a complex interface component used to edit 'rich text'—content that includes formatting information such as bold, italic, strikethrough, headings, and lists, as opposed to plain text.

Most modern web-based WYSIWYG (What You See Is What You Get) editors leverage the HTML contenteditable attribute. When this attribute is set to true on an element, the browser allows the user to directly edit the content of that element.

Follow these guidelines when designing popovers:

• Content Density: Popovers should only contain non-critical information. If information is vital, display it directly in the interface.
• Size Constraints: Keep content short to avoid layout issues on small screens or the need for internal scrollbars.
• Trigger Integrity: The trigger should only perform the popover action. Do not attach popover functionality to elements that are already interactive (like links), as this causes conflicting actions on touch devices (where focus, hover, and active states occur simultaneously).

Breadcrumbs typically appear before the main content of a page, progressing from the least specific (root/homepage) to the most specific (current page).

Common visual separation patterns for breadcrumb items include:

• Icons: Using SVG arrows or greater-than symbols (>).
• Symbols: Using a forward slash (/).

Common use cases include representing site structural hierarchy (e.g., Home > Section > Page) or category/taxonomy hierarchies (e.g., Ingredients / Vegetables / Leafy Greens).

When designing button groups, follow these usability patterns:

• Consistent Ordering: Maintain consistent rules for button order across your application.
• Action Placement: A common pattern is to place primary actions (e.g., submitting a form) on the right and secondary actions (e.g., cancel, go back) on the left.

When choosing or implementing a rich text editor, be aware of these common issues:

• Loss of design control: Editors often ship with generous default configurations that may bypass your design system or fail to enforce semantic HTML (like correct heading levels or alt attributes on images).
• Visual discrepancies: Unless the editor uses the exact same CSS/JS as your final output, the 'WYSIWYG' view is often just an approximation.
• Pasting from external sources: Copying text from applications like Microsoft Word into a web editor often results in bloated, messy markup filled with   characters and unnecessary HTML elements.
• Accessibility: Building accessible JavaScript-driven editors is difficult and requires intentional development from the start.

When implementing tabs, consider these best practices:

• Information Density: Use tabs to display large amounts of information in limited space.
• Discoverability: Be aware that tabs hide content, which can make it less discoverable for sighted users and users of assistive technology.
• Responsive Design: For horizontal layouts, plan for narrow screen widths. If tabs become difficult to use on mobile, consider swapping the component for an Accordion.

The interactive Rating component functions as a series of radio inputs with values 0 through 5. The default keyboard interaction pattern is:

• Tab: Focus on the rating component or move focus to the next interactive element.
• → or ↓: Increase the rating by one star.
• ← or ↑: Decrease the rating by one star.

Note: Some design systems (like Adobe Spectrum) invert the up/down arrow behavior (↑ = +1, ↓ = -1), but the default implementation follows the logical direction of the arrow keys.

When implementing accordions, consider these UX principles:

• Screen Space: Accordions are excellent for small screens as they reduce vertical scrolling.
• Information Hierarchy: Do not use accordions for essential information, as the content is hidden from the user by default.
• Single vs. Multiple Expansion: Some accordions only allow one item to be open at a time. Use this pattern with caution, as users may need to compare content from two different sections simultaneously.

Because rich text editors accept user input, they are vulnerable to several security exploits. When implementing an editor, you must address the following:

Cross-Site Scripting (XSS)

If you display user-generated content (e.g., comments) without protection, attackers can inject malicious JavaScript into your webpage.

Mitigation: You must sanitize user input before storing or displaying it. Sanitization involves stripping out everything except an explicitly allowed set of characters, HTML tags, and attributes.

Other Vulnerabilities

Accepting user input also opens risks for:

• Cross-site request forgery (CSRF)
• SQL injection
• Local/Remote File inclusion