Fixing table styling when transitioning to the new article editor – Second Brand

Suite

Team, Growth, Professional, Enterprise, or Enterprise Plus

Support with

Guide Professional or Enterprise

Zendesk introduced a new article editor in accounts in Q2 2025. The transition from the legacy article editor to the new article editor will occur in four phases, ending in Q1 2026. The new editor introduces improvements and changes, including how tables are styled at the HTML and CSS levels.

Because the new editor is not 100% compatible with the legacy editor, some common issues related to tables may arise during or after you upgrade to the new editor. This article guides theme developers and admins through these issues, along with workarounds and solutions to ensure your tables fit your brand's styling as intended.

Note: If you encounter additional issues or solutions, add them in the comments section at the bottom of this article.

This article includes the following topics:

Changes to table styling in the new editor
Examples of table conversions during upgrade
Common issues and how to fix them
Best practices for theme developers and admins

Changes to table styling in the new editor

The biggest change for tables in the new article editor is the use of inline CSS styles applied directly to table elements (for example, <table>, <tr>, and <td>) rather than relying on HTML attributes or external CSS classes to style tables. New tables are also now wrapped into a <figure> tag.

In the previous editor, table styles were applied using a combination of HTML attributes (for example, cellpadding, border), and some inline CSS.
In the new editor, table customization (such as border width, border color, background color, cell height/width, text color, and padding) are applied strictly as inline CSS styles.

Inline styles always have the highest CSS specificity, which means:

Your custom theme CSS styling targeting tables may not override these inline styles unless your selectors use equal/higher specificity or use !important.
Older themes and CSS styling that targeted HTML attributes or element selectors without careful specificity may find that their table styles are broken or inconsistently applied after the upgrade to the new editor.

Examples of table conversions during upgrade

The following examples illustrate issues that can occur when converting tables to the new article editor.

Cell padding converted from attribute to inline style

The legacy article editor uses the [cellpadding] attribute to specify padding, while the new article editor uses inline styling. Previous styles targeting [cellpadding] attributes or elements expecting that property will no longer work until adjusted.

Legacy article editor HTML

<table cellpadding="20">

New article editor HTML

<td style="padding: 20px;">

Border handling changes

The following examples illustrate how table borders are handled with the legacy editor, the new editor, and legacy articles converted to the new editor.

HTML generated by inserting a table in the legacy editor

<table style="border-collapse: collapse; width: 100%" border="1">
  <tbody>
    <tr>
      <td style="width: 50%">A</td>
      <td style="width: 50%">B</td>
    </tr>
    <tr>
      <td style="width: 50%">C</td>
      <td style="width: 50%">D</td>
    </tr>
  </tbody>
</table>

HTML generated by inserting a table in the new editor

<figure style="width: 100%" class="wysiwyg-table">
  <table style="border-style: solid; border-width: 1px">
    <tbody>
      <tr>
        <td style="border-style: solid; border-width: 1px">A</td>
        <td style="border-style: solid; border-width: 1px">B</td>
      </tr>
      <tr>
        <td style="border-style: solid; border-width: 1px">C</td>
        <td style="border-style: solid; border-width: 1px">D</td>
      </tr>
    </tbody>
  </table>
</figure>

HTML generated by converting a table from the legacy editor to the new editor

<figure style="width: 100%" class="wysiwyg-table wysiwyg-table-align-left">
  <table
    style="border-collapse: collapse; border-style: solid; border-width: 1px"
  >
    <tbody>
      <tr>
        <td style="border-style: solid; border-width: 1px; width: 50%">A</td>
        <td style="border-style: solid; border-width: 1px; width: 50%">B</td>
      </tr>
      <tr>
        <td style="border-style: solid; border-width: 1px; width: 50%">C</td>
        <td style="border-style: solid; border-width: 1px; width: 50%">D</td>
      </tr>
    </tbody>
  </table>
</figure>

Common issues and how to fix them

This section describes several common issues resulting from transitioning tables from the legacy editor to the new editor, and how you can fix them.

Theme CSS not overriding table styles (padding, borders, and colors)

Issue: Your custom theme CSS that previously controlled table borders, cell padding, or background colors is not applying because the editor now uses inline styles.

Possible solutions:

Increase CSS specificity: Use more specific selectors to target table elements inside the article. Adding !important ensures your styles override inline styles.
```
.article-body table,
.article-body table td {
  border: 1px solid #ccc !important;
  padding: 10px !important;
  background-color: #f9f9f9 !important;
}
```
Target the figure wrapper: The editor now wraps tables inside <figure> elements with classes .wysiwyg-table. Customize the wrapper as needed:
```
figure.wysiwyg-table {
  margin: 1em auto;
  max-width: 90%;
}
```
Update styles that rely on HTML attributes: If your theme styles tables use attribute selectors (like [cellpadding] or [border]), update them to target the new structure using classes or inline styles instead.

Tables look different after upgrade

Issue: Tables lose width or alignment configurations, or you see unexpected borders and spacing.

Possible solutions:

The new editor places the table inside a <figure> with inline width. You may need to adjust or override.

figure.wysiwyg-table {
  width: 100% !important;
  text-align: center;
}
figure.wysiwyg-table table {
  width: 100% !important;
  border-collapse: collapse;
}

Check your theme’s table default styles and adapt for the new structure.

Custom or complex table HTML breaks or needs manual adjustment

Issue: If you had customized tables with unusual attributes or custom inline styles, the upgrade from the legacy editor to the new editor may not handle these perfectly.

Note: When tables in the legacy editor have been modified through the source code or contain HTML that the new editor doesn't support, the new editor wraps the tables inside of an HTML block. When this occurs, you won't be able to use the new article editor table component to edit the tables. Instead, you'll have to use the source code editor to update the HTML block.

Possible solutions:

Review the migrated article HTML source for tables.
Adjust or rewrite custom table HTML to follow the new model:
- Wrap the <table> inside a <figure class="wysiwyg-table">.
- Use inline styles for borders on both <table> and <td>.
Consider recreating complex tables in the new editor to ensure compatibility.

Best practices for theme developers and admins

Use the following best practices to minimize issues when migrating tables to the new article editor:

Use specific CSS selectors targeting .wysiwyg-table, tables inside .article-body, or figure elements wrapping tables.
Use !important carefully to override inline styles.
Test tables during and after upgrade on multiple browsers and device sizes.
Educate content writers about the possibility of inline styles and the need to keep table customizations minimal for easier maintenance.
Back up your help center theme and article content before performing batch upgrades or heavy customizations.