Tables and Cards

Tables and Cards Page Elements organize information into structured visual layouts.

Use Tables when information is best compared in rows and columns. Use Cards when information is best presented as grouped blocks, summaries, profiles, product tiles, dashboard panels, or repeated visual items.

This page covers visual presentation patterns in the Page Editor. Project Database table configuration is managed separately under Backend.

For data-backed table interfaces, see Data Table Widget. For repeated custom layouts populated with Project data, see Data Design.

Available Table and Card Elements

The Page Editor includes these common table and card-oriented elements:

Element	Purpose
Table	Defines a basic visual table.
Table Row	Defines a row within a Table.
Table Heading Cell	Defines a heading cell within a Table row.
Table Column Cell	Defines a content cell within a Table row.
Card Group	Provides a layout for multiple cards.
Card	Defines a contained visual panel.
Card Header	Adds a header area inside a Card.
Card Body	Adds the main content area inside a Card.
Card Footer	Adds a footer area inside a Card.

The Element Library also provides ready-made table layouts, such as 3-column and 4-column tables, and ready-made card styles.

For common layouts, start with a suitable ready-made structure and customize it rather than assembling every nested element individually.

Understanding Table Structure

A basic Table is a visual structure for presenting fixed or manually arranged information in rows and columns.

Use a basic Table for:

• Feature comparison tables.
• Pricing comparison content.
• Simple schedules.
• Static reference information.
• Small manually maintained lists.
• Custom table-like layouts that do not need built-in data tools.

A typical Table has the following structure:

Table
  Table Head Section
    Table Row
      Table Heading Cell
      Table Heading Cell
  Table Body Section
    Table Row
      Table Column Cell
      Table Column Cell
    Table Row
      Table Column Cell
      Table Column Cell

The Table defines the overall presentation. The Head and Body Sections organize the header and content rows. Table Rows contain individual cells, and the cells hold the visible content.

Table Head Section and Table Body Section

These sections serve different structural purposes:

Section	Purpose
Table Head Section	Groups the rows used to identify the table's columns or other headings.
Table Body Section	Groups the rows containing the table's main information.

For example, a comparison table might use the Head Section for the labels Feature, Basic, and Pro, and the Body Section for rows comparing individual features.

The sections organize the table; the Table, Row, and Cell elements provide the settings discussed below. Keep the heading and body structure intact when changing a ready-made table layout.

Creating a Basic Table

A typical workflow is:

1. Open the Page, Form, or Page Slice in the Page Editor.
2. Select the layout area where the table should appear.
3. Open the Element Library and choose a suitable Table layout, such as a 3-column or 4-column table.
4. Add the table to the selected location.
5. Edit the Table Heading Cells to identify the columns.
6. Edit the Table Column Cells to provide the corresponding content.
7. Add, remove, or rearrange rows as needed, while preserving the table's nested structure.
8. Configure the Table's Borders, Compact Spacing, and Striped Rows settings.
9. Apply row or cell styling where appropriate.
10. Save and preview the Page, Form, or Page Slice, including at smaller screen widths.

For example, a three-column feature comparison could be arranged as:

Table
  Table Head Section
    Table Row
      Table Heading Cell (Feature)
      Table Heading Cell (Basic)
      Table Heading Cell (Pro)
  Table Body Section
    Table Row
      Table Column Cell (Projects)
      Table Column Cell (5)
      Table Column Cell (20)
    Table Row
      Table Column Cell (Support)
      Table Column Cell (Standard)
      Table Column Cell (Priority)

The values above are illustrative; they are not ioLoop plan limits.

When modifying a table, select the element corresponding to the change you want to make. Table-wide appearance belongs to the Table; row styling belongs to a Table Row; and individual cell content or spans belong to the appropriate Cell.

For more information about selecting and arranging nested elements, see Selected Element Toolbar and Editing Page Content.

Table

The Table element controls the overall table presentation.

Table Settings

In Element Settings, a Table can control:

Setting	Purpose
Borders	Controls whether table borders are default, disabled, or enabled.
Compact Spacing	Reduces table spacing for denser information.
Striped Rows	Alternates row shading to improve scanning.

Borders

Borders help separate cells and make dense tables easier to read.

Use borders when:

• Cells contain similar-looking values.
• The table has several columns.
• Users need to compare values precisely.

Use fewer borders when:

• The table is short.
• The layout should feel lighter.
• Row grouping or whitespace already makes the structure clear.

Compact Spacing

Compact Spacing reduces the vertical and horizontal spacing inside the table.

Use Compact Spacing for dense information, such as admin lists or comparison tables. Avoid compact spacing when cells contain longer text, images, buttons, or input controls that need additional room.

Striped Rows

Striped Rows alternates row background treatment to make horizontal scanning easier.

Use Striped Rows for tables with several rows. For very short tables, stripes may be unnecessary. If you also apply row-specific Looks, preview the result to confirm that the row styling remains clear.

Table Row

A Table Row defines one horizontal row inside a Table Head Section or Table Body Section.

Use Table Rows for:

• Header rows.
• Data rows.
• Summary rows.
• Section rows inside a table.

Table Row Settings

In Element Settings, a Table Row can control:

Setting	Purpose
Hover	Adds a hover treatment, optionally indicating that the row is clickable.
Look	Applies a visual style such as blue, green, gray, red, yellow, teal, light, or dark.

Hover

Hover controls how the row responds visually when users move over it.

Available choices include disabled, enabled, and clickable.

• Disabled avoids a row-specific hover treatment.
• Enabled provides a visual hover response that can help users follow a row across columns.
• Clickable presents the row as an interactive entry when the table design calls for row selection or another action.

A clickable appearance does not, by itself, define what should happen when the row is selected. Configure the supported interaction separately, where required, and test the resulting behavior in Preview.

If selecting a row must open details, validate application state, or perform an operation, use the appropriate supported control and Page Flow behavior rather than relying on hover styling alone.

Look

Look gives the row a visual meaning.

Common uses include:

Look	Typical Use
Blue	Informational row.
Green	Success or positive status.
Gray	Secondary or neutral row.
Red	Error, danger, or destructive status.
Yellow	Warning or review-needed status.
Teal	Supporting information.
Light	Low-emphasis row.
Dark	High-contrast row.

Use row styles consistently. Do not use the same color to mean different things in different tables, and do not rely on color alone to communicate important status information.

Table Cells

Tables use two main cell types:

Cell Type	Purpose
Table Heading Cell	Identifies a column or row.
Table Column Cell	Contains ordinary table content.

Both cell types can hold supported child content, such as Text, Inline Text, Badges, Buttons, Links, or other suitable elements.

Table Heading Cell

A Table Heading Cell identifies what a column or row represents.

Use heading cells for:

• Column labels.
• Row labels.
• Group headings.
• Comparison categories.

In Element Settings, a Table Heading Cell can control:

Setting	Purpose
Hover	Adds a hover treatment when appropriate.
Look	Applies a visual style.
Column Span	Allows the cell to span multiple columns.
Row Span	Allows the cell to span multiple rows.
Scope	Identifies whether the heading applies to a row or column.

Scope

Scope helps identify the relationship between a heading and the content it describes.

Scope	Use
Column	For a heading that labels a column, such as Product, Price, or Status.
Row	For a heading that labels a row, such as a feature name or comparison category.

For a typical comparison table, use Column for the heading cells across the top. If the first cell in each body row identifies the subject of that row, a Table Heading Cell with Row scope can be more appropriate than an ordinary content cell.

Table Column Cell

A Table Column Cell holds ordinary table content.

Use column cells for:

• Text values.
• Status badges.
• Links.
• Buttons.
• Small media.
• Summary values.

In Element Settings, a Table Column Cell can control:

Setting	Purpose
Hover	Adds a hover treatment when appropriate.
Look	Applies a visual style.
Column Span	Allows the cell to span multiple columns.
Row Span	Allows the cell to span multiple rows.

Column Span and Row Span

Column Span and Row Span allow a heading or content cell to occupy more than one column or row.

Setting	Example Use
Column Span	A summary cell spanning all three columns of a comparison table.
Row Span	A category heading covering two adjacent rows in a grouped table.

For example, a table with three columns might end with a summary row containing one cell whose Column Span is set to 3. That cell occupies the width of the three ordinary columns.

Similarly, a heading identifying a category shared by two rows could use Row Span set to 2.

When using spans, make sure the remaining cells still form a coherent table. Avoid adding extra cells in positions already occupied by a spanning cell. Use merged cells only where they make the information easier to understand.

Adding Content and Actions to Cells

Table cells can contain more than plain text.

For example, a small status table may have:

Column	Example Content
Item	Text identifying a record or task.
Status	A Badge showing a readable status label.
Action	A Link or Button for opening details or starting an operation.

Keep controls compact and easy to identify. If a Button or Link requires application logic, configure its supported behavior or use Page Flow.

A basic Table provides the presentation structure. Adding Buttons, Links, or dynamic content does not automatically give it the built-in record management features of a Data Table Widget.

Cards

A Card is a contained visual panel used to group related information.

Use Cards for:

• Dashboard summaries.
• Product tiles.
• Contact or customer summaries.
• Feature panels.
• Report snapshots.
• Search results.
• Workflow steps.
• Action panels.

Cards commonly combine several Page Elements. For example:

Card
  Image
  Card Body
    Heading
    Text
    Badge
    Button

Or a Card can use distinct Header, Body, and Footer areas:

Card
  Card Header
    Heading
  Card Body
    Text
    Table
  Card Footer
    Button

These are example arrangements. The Card provides the visual grouping, while its child elements carry the actual information and actions.

Creating a Card

A typical workflow is:

1. Open the Page, Form, or Page Slice in the Page Editor.
2. Select the layout area where the Card should appear.
3. Open the Element Library and choose a suitable ready-made Card style or supported Card structure.
4. Add the Card to the selected location.
5. Configure its Header, Body, and Footer content as needed.
6. Add supported child elements such as Headings, Text, Images, Badges, Links, or Buttons.
7. Configure any navigation or action behavior on the relevant interactive child elements.
8. Adjust the surrounding layout to establish the Card's width and placement.
9. Save and preview the result.

For example, a customer summary Card could contain:

Card
  Card Header
    Heading (Customer Name)
    Badge (Active)
  Card Body
    Text (Contact Information)
    Text (Account Summary)
  Card Footer
    Link (View Details)

Keep the structure predictable. A summary Card should let users recognize its subject, understand the key information, and find any available action without searching through unrelated content.

Card Parts

Cards can contain specialized parts:

Part	Purpose
Card Header	Holds a title, category, status, or header controls.
Card Body	Holds the primary content.
Card Footer	Holds supporting information or actions.

Card Header

Use Card Header for short, high-level information:

• A card title.
• A record type.
• A status area.
• A compact action area.

Keep Card Headers concise. Longer descriptions usually belong in the Card Body.

Card Body

Card Body holds the main content of the card.

Use Card Body for:

• Headings and descriptions.
• Images and media.
• Badges and status values.
• Small tables or lists.
• Buttons and links.
• Input controls when the card is part of an input workflow.

Organize the Body around the information users need most. For example, a product Card might show a product image, name, short description, availability, and price before the action to view more details.

Card Footer

Card Footer holds supporting information or actions at the bottom of the card.

Use Card Footer for:

• Secondary metadata.
• Updated dates.
• Small status text.
• Action buttons.
• Links to details.

Keep footer actions predictable. If every Card in a group has actions, place them consistently so users can compare and operate on Cards without relearning each layout.

Card Groups

A Card Group provides a layout starting point for multiple Cards.

Use Card Groups when several Cards should appear as a repeated set, such as:

• Dashboard metrics.
• Product cards.
• Team member profiles.
• Plan options.
• Search result tiles.

A typical grouping can be represented as:

Card Group
  Card
    Card Header
    Card Body
    Card Footer
  Card
    Card Header
    Card Body
    Card Footer
  Card
    Card Header
    Card Body
    Card Footer

The example represents three Cards with a consistent internal structure. Individual Cards can contain different values and content while following the same general pattern.

Working with Card Groups

When building a group of Cards:

1. Start with an appropriate Card Group or ready-made card arrangement from the Element Library.
2. Configure one Card's content structure to suit the information being presented.
3. Add or arrange the additional Cards needed for the group.
4. Keep related content, headings, status labels, and actions in consistent positions.
5. Use surrounding Layout Rows and Columns as appropriate to organize the group within the Page.
6. Preview the arrangement at desktop, tablet, and mobile widths.

For example, a dashboard could display several Cards for key metrics. Each Card might contain a metric label in the Header, a value in the Body, and a supporting note in the Footer.

Card Groups are useful for organizing repeated visual panels. They do not, by themselves, imply that Cards are automatically generated from Project Database records. For data-driven repetition, use Data Design.

Card Groups and Layout Elements

The Card Group organizes related Cards, while surrounding Layout Elements help determine how the group fits into the Page.

Use Containers, Rows, and Columns to arrange Card content alongside other page sections. For example, a Card Group may appear below a page heading or beside a filter area.

The responsive arrangement depends on the chosen layout structure and its configuration. Do not assume that every Card Group automatically uses a particular number of columns or stacking behavior. Confirm the actual layout in Preview.

For more information, see Layout Elements.

Basic Tables vs. Data Table Widget

A basic Table is a Page Element structure. It is best for content that is manually arranged or only lightly dynamic.

A Data Table Widget is a configured Widget for displaying records in a table-style interface.

Use a Data Table Widget when you need:

• Data-backed record lists.
• Configurable columns.
• Table actions.
• Refreshable data.
• Record-oriented interactions.
• Built-in table behavior.

Use a basic Table when you need:

• A fixed comparison table.
• Manually edited content.
• A small reference table.
• A custom structure that does not need Widget behavior.

For example, a pricing comparison with three manually defined plans may be appropriate for a basic Table. A list of customer records that needs configurable columns and record-oriented actions is better suited to a Data Table Widget.

For more information, see Data Table Widget.

Cards and Data Design

Cards are often useful as the visual structure for repeated data.

Use Data Design when you want one Card design to be populated repeatedly from Project data.

For example, a product card design might include:

• An Image for the product photo.
• A Heading for the product name.
• Text for the description.
• A Badge for availability.
• A Button for viewing details.

Page Flow can retrieve records and use Data Design to render the same Card structure for each record.

Use Data Design when:

• The same layout repeats for many records.
• The content should come from Project data.
• You need more visual control than a standard table.
• Cards, tiles, custom rows, or search results should be generated from data.

Manual Cards vs. Data-Driven Cards

Consider a team page displaying four profiles. If the profiles are fixed and rarely change, four manually configured Cards may be sufficient.

If the same layout should display many records from Project data, maintaining separate copies of the Card becomes harder. Data Design lets you define the repeated presentation and populate it from the data returned by the application.

The Card controls visual presentation. Data retrieval, record selection, and application operations belong to the appropriate Page Flow and Backend configuration.

For more information, see Data Design and Rendering Data Design.

Tables, Cards, and Page Flow

Tables and Cards define how information is presented. Page Flow provides browser-side application logic when content or actions need more than a fixed visual layout.

Common examples include:

• Retrieving data to populate a repeated Card design.
• Responding to a Button or Link inside a Table cell.
• Opening a record detail Page or Form from a Card action.
• Refreshing displayed information after an operation.
• Showing a message when an action succeeds or fails.

Use direct Links for ordinary navigation. Use Page Flow when an action requires additional application logic.

Page Flow does not replace Backend authorization. If an action reads or changes protected information, enforce the necessary access rules through the appropriate Backend configuration, including Cloud Flow where required.

For more information, see Page Flow.

Responsive Tables and Cards

Tables and Cards should remain readable and usable at desktop, tablet, and mobile screen sizes.

A table that fits comfortably on a desktop may be difficult to read on a narrow screen. A row of Cards may also need a different arrangement when less horizontal space is available.

Responsive Tables

When designing Tables for smaller screens:

• Keep column headings short and descriptive.
• Avoid unnecessary columns, especially when they contain long text.
• Use Compact Spacing only if the content and controls remain readable.
• Avoid large merged-cell structures that complicate narrow layouts.
• Check whether the surrounding layout provides an appropriate way to handle overflow.
• If a table is too wide, consider a different presentation, such as separate Cards, where the information allows it.

Do not assume that a basic Table automatically becomes a stacked mobile layout or enables horizontal scrolling. The result depends on the selected structure and surrounding layout configuration.

Responsive Cards

Cards can provide a useful alternative when information needs a more flexible visual presentation.

For groups of Cards:

• Keep individual Cards readable at narrower widths.
• Use Layout Rows and Columns to establish an appropriate arrangement.
• Check that images, descriptions, and controls fit within each Card.
• Keep important actions visible and practical to tap.
• Preserve a consistent reading order as the layout changes.
• Avoid placing so many Cards side by side that their content becomes cramped.

For example, a group of product Cards might fit in multiple columns on desktop but need a narrower arrangement on mobile. Use the supported layout controls and verify the actual result rather than assuming that a particular layout transformation occurs automatically.

Previewing Different Screen Sizes

Before publishing:

1. Preview the Page at desktop width.
2. Review it at tablet and mobile widths.
3. Check table headings, cell content, spans, and overflow.
4. Check Card dimensions, content wrapping, and action placement.
5. Test interactive Buttons, Links, and other supported controls.

Also check pages containing Tables or Card Groups inside Forms or Page Slices, since the available space may differ from a full-width Page layout.

Choosing the Right Display

Need	Use
Fixed comparison or reference content	Basic Table
Data-backed records in a standard table interface	Data Table Widget
Repeated custom Cards or tiles from Project data	Data Design
Dashboard summary panels	Cards
Product, profile, or result tiles	Cards or Data Design
Dense row and column comparison	Table
Visual grouping of related content	Card
Several related visual panels	Card Group
Content that requires a tailored layout for each item	Card or Data Design, depending on the data source

Choose based on the information and interactions users need, not just the visual appearance. A manually built Table and a Data Table Widget may look similar but provide different configuration and data behavior.

Good Practices

• Use Tables for comparison. Present information in rows and columns when users need to compare values directly.
• Use Cards for grouped summaries. Put related information and actions into recognizable visual panels.
• Start with ready-made structures. Customize suitable Table and Card layouts instead of unnecessarily rebuilding their nested elements.
• Preserve table structure. Keep Head Sections, Body Sections, Rows, and Cells organized correctly.
• Keep headings clear. Use short, descriptive table labels and the appropriate heading Scope.
• Use spacing and borders deliberately. Compact Spacing, Borders, and Striped Rows should improve readability.
• Use row styles consistently. Combine meaningful color treatments with readable labels when communicating status.
• Avoid unnecessary merged cells. Use Column Span and Row Span only where they clarify the information.
• Keep Cards consistent. Use comparable content organization across related Cards.
• Place Card actions predictably. Keep actions in consistent positions, such as the Card Footer when appropriate.
• Choose the right data presentation. Use Data Table Widget for record-oriented tables and Data Design for repeated custom layouts populated from Project data.
• Test responsive behavior. Preview Tables and Card Groups at desktop, tablet, and mobile widths.
• Verify actions. Test Links, Buttons, and any Page Flow behavior used by a Table or Card.

Common Mistakes

Avoid these patterns:

• Using a basic Table for complex record lists. Large data-backed lists that need Widget behavior are usually better served by a Data Table Widget.
• Building many repeated Cards manually. When records drive the content, Data Design is generally easier to maintain.
• Changing the wrong nested element. Table-wide settings, Row settings, and Cell settings serve different purposes.
• Breaking the table hierarchy. Removing structural sections or placing cells incorrectly can lead to confusing layouts.
• Using clickable styling without an action. A row that looks interactive should have a clear and tested interaction.
• Using row colors without a consistent meaning. Appearance alone should not be the only way users understand a status.
• Merging too many cells. Extensive Column Span and Row Span use can make tables difficult to edit and read.
• Placing too much content in a Card Header. Put longer descriptions and detailed content in the Card Body.
• Mixing unrelated Card structures. Repeated Cards are easier to scan when their information and actions follow a consistent pattern.
• Assuming automatic responsive behavior. Verify Table overflow and Card arrangements rather than assuming they adapt in a specific way.
• Relying on visual controls for security. A hidden or unavailable action in the Page does not replace Backend authorization.
• Skipping Preview tests. Check content, layout, and interactions at the sizes where the application will be used.

Tables and Cards are most useful when their visual structure matches the information: rows and columns for comparison, Cards for grouped summaries, and Widgets or Data Design when Project data should drive the display.

Related Topics

• Page Elements
• Element Library
• Element Settings
• Selected Element Toolbar
• Editing Page Content
• Layout Elements
• Buttons and Actions
• Data Table Widget
• Data Design
• Page Flow