Card

On its own a card is a padded box: the surface color, the corner and the shadow of the current theme around whatever ChildContent puts in it. It is only as wide as its content, which is what lets a card sit inside a sentence of layout without stretching; FullWidth and the width parameters further down change that.

Title and Subtitle render the two lines of the header, and IconName puts a glyph in front of them. The moment any of them is set the card stops being one padded box and becomes a stack of parts, so the body below the header is inset by the same padding rather than sharing it. HeadingLevel makes the title a real heading (1-6), which is what lets a screen reader user jump from card to card instead of reading through them - leave it unset for a title that is only a label. IconTemplate puts markup of your own in the leading slot - an avatar, a logo, a thumbnail - while the title and the subtitle stay where they are, and HeaderTemplate replaces all three with a header of your own, which also takes away the line a linked card is named after.

ImageUrl puts a picture at the head of the card, outside the padding and clipped to the corner the card draws. ImageHeight fixes how tall it is and the picture is cropped to fill that box rather than stretched, so a row of cards keeps one picture height whatever the aspect ratios are. The picture is decorative next to the title beside it, so it renders an empty alt unless ImageAlt says otherwise, and ImageLoading hands the browser the picture of a card that is still below the fold to fetch later. Cover takes a template instead, for a head that is not a single picture - a chart, a carousel, a video. CoverRatio draws the cover at a ratio of your own instead - 16 / 9, 1 / 1, 4 / 3 - which is what a responsive grid wants: a fixed height keeps a row of cards level only until the column narrows, while a ratio keeps it level at every width. ImagePosition says which part of the picture survives that crop - top for a portrait whose face sits high in the frame, bottom for a landscape whose horizon sits low - instead of the middle the browser keeps by default. Reversed moves the cover under the content instead of over it, which is the shape a caption card wants. CoverOverlay moves the cover behind the content rather than above it, which is the hero card: give the card a Height of its own, since a cover behind the content no longer makes the card as tall as the picture, and a foreground the words can be read against - the picture carries no scrim.

Actions is the slot at the trailing edge of the header, for whatever acts on the card as a whole - an overflow menu, a dismiss button, a status tag. Footer is the row under the body, for the actions a reader is meant to take. Both sit outside the title block and both are raised above the block link of a card that has an Href, so the controls in them keep working on a card that is itself a link. Divider draws a hairline between the header and the body and between the body and the footer, for a card that reads better as three parts than as one column; a header with nothing under it, or a footer with nothing over it, draws no rule at all, and a header stacked straight onto a footer draws one rule between them rather than two. FloatingActions is the third slot: it floats over the corner of the card itself rather than sitting in the column of parts, which is where a picture card has to keep its favourite toggle or its selection box - on such a card the header is under the cover rather than over it. It floats over a plain padded card just as well, and it is raised above the block link too. All three keep their clicks and their key presses to themselves on a card that has an OnClick of its own, so pressing the menu of such a card is not also pressing the card under it.

Horizontal lays the cover beside the content instead of above it, which is the shape a list of cards wants when each row is a thumbnail and a summary. The cover takes a third of the width by default and CoverWidth sets it to anything else; the picture fills that box in both directions, so a row of cards keeps one thumbnail size whatever the aspect ratios are. Reversed swaps the two around, so the thumbnail sits on the trailing edge of the row and the words lead it - and it mirrors with the card, so a right-to-left row reverses the other way.

OnClick turns the card into a control: it takes focus, it answers Enter and Space, it reports itself as a button to assistive technologies and it lifts under the pointer. It also gives up the heading a HeadingLevel would make of its title, since what a button holds is read as its name rather than as structure. A card that is a button is best left without controls of its own for the same reason - use the Href below with Actions or Footer for a card that leads somewhere and still carries buttons - though a control in any of the three action slots keeps its click and its key press to itself either way, rather than firing the card as well. IsEnabled="false" takes it out of the tab order, off the pointer and marks it disabled, and StopPropagation keeps the click from reaching whatever the card sits in - a card inside another clickable card, or inside a row that has a handler of its own.

Href makes the whole card lead somewhere. The card is not wrapped in an anchor - an anchor around a card is invalid the moment the card holds a link or a button, and a screen reader reads the whole card out as the name of that one link. Instead an anchor is stretched over the surface, which is the block-link pattern the design systems settled on, and it is named after the AriaLabel, an aria-labelledby of your own, the Title or the Subtitle - in that order - so a page of linked cards reads as a list of destinations rather than a list of identical links, and the name is handed to the anchor rather than left on the card as a second copy. Target and Rel reach that anchor; a card opening in a new tab gets rel="noopener" on its own, and Download turns the whole card into the thing that saves the file it points at. Everything in Actions, Footer and FloatingActions stays above the anchor and keeps working - and keeps its click to itself, so a linked card that also has an OnClick is not fired by the buttons inside it. A linked card takes no tab stop of its own: the anchor is the one control over the surface, and a TabIndex goes to it rather than to the wrapper around it. What the anchor does cover is the text of the body, which a reader can no longer select with the pointer - the price the block-link pattern pays wherever it is used.

Binding Selected turns the card into a toggle the same way a click handler turns it into a button: clicking or pressing Enter flips the value and the card reports its state through aria-pressed. A picked card is marked with a ring rather than a new fill, so the state survives whatever Color the card is already wearing: the ring is drawn in the primary color, or in the fill's own foreground on a card that is already painted in a role. It is painted over the edge of the card rather than added to it, so picking through a grid of cards moves nothing. A card that is a button through OnClick reports the state as well while it carries it, even where the app sets Selected itself rather than binding it - a control whose state only the sighted reader can see is not a state at all. A card splatted with a role that carries a selection of its own - option, row, gridcell, tab, treeitem - reports it through aria-selected instead, which is the state those roles answer to; that is what a grid or a listbox built out of cards needs.

Hoverable lifts the card while the pointer is over it, for a card that reacts to the pointer without being a control itself. A clickable card and a linked one already lift on their own, so this is only needed for the rest. The lift is a shadow change - a few steps up the same Elevation ramp the card was resting on - and it only ever happens on an input device that hovers at all, so a touch screen is left alone.

Loading stands the body of the card in with a placeholder while its content is being fetched, and marks the card busy so a screen reader knows it is not finished. The header keeps rendering - the title of a card is known before its content is - so a list of loading cards still says what each one is about. LoadingTemplate puts a placeholder of your own in place of the default bars.

Elevation picks a level of the 25-step shadow ramp of the theme (--bit-shd-0 to --bit-shd-24). 0 is a flat card with no shadow at all, which is the same thing NoShadow asks for; leaving it unset keeps the shadow the theme gives every card surface. A card that lifts under the pointer lifts from whatever level it was resting at rather than to one fixed shadow, so an elevated card still rises on hover and still presses down on click instead of dropping the moment the pointer reaches it.

NoShadow drops the shadow and leaves the card a flat painted surface, which is what a card sitting inside another surface usually wants - a shadow inside a dialog or a panel reads as a mistake rather than as depth.

Background picks which of the neutral surface colors of the theme the card is painted in - the primary, secondary (the default) or tertiary background, or nothing at all. It is the paint of a plain card; a card given a Color further down is painted in that role instead.

Border draws a rule around the card in one of the neutral border colors of the theme. It is independent of the shadow, so a card can carry both, and it wins over the rule Outlined asks for - the two can be combined to get an outlined card in a border color other than the primary one.

Outlined is the shorthand for the card that carries a rule instead of a shadow, which is the third of the three card types every design system draws: elevated, filled and outlined. An explicit Border still decides the color of that rule.

Square drops the corner radius altogether, whatever the theme says. It is what a card wants when it is flush against the edge of a page or stacked with others into one continuous surface.

NoPadding takes the inset off the card so its content runs to the edges, which is what a card holding a list, a table or a picture of its own needs. It applies to every part of a sectioned card too, so the header, the body and the footer all lose their inset together.

Width and Height size the card explicitly, and MinWidth, MaxWidth, MinHeight and MaxHeight bound it instead - which is usually the better answer for a card in a responsive grid, where a maximum width keeps the line length readable without pinning the card to one size. Content taller than the height it was given runs out of the card, so a card whose height is fixed and whose content is not wants ScrollableBody: the body between the header and the footer takes the scrollbar and those two stay where they are.

A card is only as wide as its content by default. FullWidth, FullHeight and FullSize stretch it to its container instead, which is what a card in a grid cell needs so that a row of them ends up the same height whatever each one holds.

A card is a box, and a box with a name is a group - which is what an AriaLabel turns the card into, since a label on an element with no role of its own is not guaranteed to be announced at all. HeadingLevel makes the Title a real heading, so a page of cards can be walked heading by heading. A card with an OnClick reports itself as a button, takes focus and answers Enter and Space - and gives up the heading, since the contents of a button are named rather than read as structure; a bound Selected reports the state through aria-pressed, or through aria-selected on a card splatted with a role that carries one; Loading reports the card as busy; and IsEnabled="false" takes it out of the tab order and marks it disabled - whether the card was made focusable by the card or by a TabIndex of your own, and either way what focus it does take is drawn with a ring. A run of cards is a list, so wrap them in one - a ul of lis, or a container with role="list" - and give that list a name of its own. A linked card hands its name to the anchor stretched over it rather than keeping a second copy on the wrapper - and since a HeaderTemplate takes the title and the subtitle off the card, a linked card with a header of its own has nothing left to be named by and wants an AriaLabel.

Color paints the card in one of the roles of the theme instead of in the neutral surface colors, and Variant decides what it does with that role: Fill paints the whole card and takes the text with it, Outline keeps only the rule and the words in the role, and Text drops the rule and the shadow and tints the surface. A disabled card of any of the three wears the disabled slot of the same role rather than a flat grey.

Disabled:

Use icons from external libraries like FontAwesome and Bootstrap Icons for the header glyph with the Icon parameter and BitIconInfo. A glyph from any of them is normalized back to the size of the title beside it, so it sits on the same line as the words whatever type scale the library it came from brings.

FontAwesome:

Bootstrap:

Three sizes set the inset of the card, the gap between its parts and the type of its header together, so a card stays in proportion at every one of them. Medium is the default and reproduces the padding the card has always had.

Empower customization by overriding default styles and classes, allowing tailored design modifications to suit specific UI requirements. Style and Class land on the root of the card, while Styles and Classes reach every part of it separately - the block link, the floating slot, the cover and its image, the main column, the header with its icon, title and subtitle, the actions, the body, the footer and the selected state.

Component's Style & Class:

Styles & Classes:

Use Dir="BitDir.Rtl" to change the direction of the card. The whole layout mirrors with it: the header glyph moves to the right of the title, the actions move to the left of the header, and a horizontal card puts its cover on the right.