Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GHS] Struggles with specific <td> attributes configuration #11003

Closed
mmichaelis opened this issue Dec 13, 2021 · 4 comments
Closed

[GHS] Struggles with specific <td> attributes configuration #11003

mmichaelis opened this issue Dec 13, 2021 · 4 comments
Labels
type:bug This issue reports a buggy (incorrect) behavior.

Comments

@mmichaelis
Copy link

mmichaelis commented Dec 13, 2021

📝 Provide detailed reproduction steps (if any)

  1. Setup ClassicEditor with Table Feature, GeneralHtmlSupport, Source Editing (for testing).

  2. Configure GeneralHtmlSupport as follows

    htmlSupport: {
      allow: [
        // <tr> just for comparison
        {
          name: /^(td|tr)$/,
          classes: true,
          attributes: true,
        },
      ],
    }
  3. Now add a table in source editing:

    <table>
        <tbody>
            <tr lang="de">
                <td lang="en">
                    Example
                </td>
            </tr>
        </tbody>
    </table>
  4. Store data (exit source editing)

  5. Switch back to source editing view, have a look at the inspector.

✔️ Expected result

  • lang attribute is persisted for <td> as well as for <tr>.
  • Inspector shows tableCell node having htmlAttributes

❌ Actual result

  • lang attribute is removed from <td> but stored for <tr>.
  • lang attribute is not exposed in editing view of <td>.
  • ✔️ Inspector shows tableCell having htmlAttributes.

Workaround: Use the generic configuration "allow all":

htmlSupport: {
  allow: [
    {
      name: /^.*$/,
      classes: true,
      attributes: true,
    },
  ],
}

📃 Other details

  • Browser: Chrome
  • OS: Windows
  • First affected CKEditor version: 31.0.0
  • Installed CKEditor plugins:
    • Alignment,
    • Autosave,
    • BlockQuote,
    • Bold,
    • CodeBlock,
    • Essentials,
    • Heading,
    • Highlight,
    • Indent,
    • Italic,
    • AutoLink,
    • Link,
    • GeneralHtmlSupport,
    • List,
    • Paragraph,
    • PasteFromOffice,
    • RemoveFormat,
    • Strikethrough,
    • SourceEditing,
    • Subscript,
    • Superscript,
    • Table,
    • TableToolbar,
    • Underline

This issue related to #9856.


If you'd like to see this fixed sooner, add a 👍 reaction to this post.

@mmichaelis mmichaelis added the type:bug This issue reports a buggy (incorrect) behavior. label Dec 13, 2021
@theezeb

This comment has been minimized.

@mmichaelis
Copy link
Author

@mmichaelis does tr tag allows style attributes on it? since they're invalid as per HTML standards,so when enabled in GHS it makes them valid.

@shahzebgit, sorry, I don't get the relevance for this question regarding this issue. In our scenario (which is reduced HTML for the data layer), neither <td> nor <tr> may have style attributes.

Regarding HTML, standard, if I read this correctly, <tr> supports the style attribute (as it supports global attributes): <tr>: The Table Row element - HTML: HyperText Markup Language | MDN.

@mmichaelis
Copy link
Author

I am pretty unsure, if this issue is really valid.

TL;DR: It works now, that we refactored our code, which now generates this configuration for <td>

{
  name: "td",
  classes: true,
  attributes: {
    abbr: true,
    rowspan: true,
    colspan: true,
    lang: true,
    dir: /^(rtl|ltr)$/,
    align: /^(left|center|right)$/,
    valign: /^(top|middle|bottom|baseline)$/,
  },
}

As we are using GHS on API level (using DataFilter.loadAllowedConfig) I just can assume, that we had an error in our implementation (although I could have sworn, I tested the configurations above without this extra bloat).

Still using CKEditor 31.0.0, just to emphasize, that we did not update meanwhile.

Thus, unless someone else has a problem here, I would recommend just closing this issue.

Sorry, for any inconvenience.

@theezeb

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

No branches or pull requests

3 participants