fix(web-components): remove default MessageBar max-width#36389
Open
AKnassa wants to merge 1 commit into
Open
Conversation
Drop the default 520px cap on MessageBar content so it fills its container, matching Fluent React v9 (per Fabric design guidance). Add an opt-in `--message-bar-content-max-width` CSS custom property for consumers who still want to cap the content width. Fixes microsoft#36365 Claude-Session: https://claude.ai/code/session_016KRzffUGCCC7w6YaAz9nbF
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previous Behavior
<fluent-message-bar>capped its content at a hardcodedmax-width: 520px. Per current Fabric design guidance that cap is no longer desired, and it doesn't match Fluent UI React v9 (whoseMessageBarBodyhas nomax-width).New Behavior
The MessageBar content is no longer capped by default — it fills its container, matching React v9. Consumers who still want a cap can opt in with a new CSS custom property:
Why a custom property (rather than removing the cap outright)
The issue offered three options — remove entirely, a CSS custom property, or a CSS part. I went with the custom property because it delivers the requested default (no cap) while leaving a supported, on-convention escape hatch for anyone who relied on the 520px cap — no shadow-DOM piercing required. It mirrors the existing
--drawer-width/--menu-max-heightidiom and keeps the new public surface minimal (a single documented property), which felt appropriate for an issue still marked Needs: Discussion.Happy to switch to a plain removal, or additionally expose
part="content", if the team prefers — @chrisdholt.What changed
message-bar.styles.ts—max-width: 520px→max-width: var(--message-bar-content-max-width, none)message-bar.styles.css— regenerated viayarn generate:ssr(the committed SSR mirror)message-bar.ts— documented the new property with@csspropertymessage-bar.spec.ts— two tests: no cap by default, and it caps when the property is set (both run across CSR and SSR)minor— introduces a new public CSS custom property)How to verify
cd packages/web-components yarn e2e src/message-bar/message-bar.spec.ts48 pass (8 tests × chromium/firefox/webkit × CSR/SSR). Visually, in Storybook, a long single-line message no longer clamps at 520px; setting
--message-bar-content-max-widthre-introduces the cap.Notes for the reviewer
message-bar.styles.csswas missingcolor: var(--colorNeutralForeground3)on:hostthat the source (.styles.ts) already declares — so SSR text color differed from CSR. I kept the corrected output socheck:ssrstays green for this component. This is the only incidental line beyond themax-widthchange.apps/vr-tests-web-componentshas no MessageBar story, so this visual change has no VRT snapshot guard today — flagging as a possible follow-up.Related Issue(s)