ckeditor
Table and cell default border styles
The following issue aims to describe and provide information about a couple of issues related to tables and cells styles, and, hopefully, provide resolutions.
No possibility to set border=none. (#6841)
The problem we have is that via UI it’s not possible to set border to none (cell and table level). This is because we set via the default stylesheets styling to have a border style double, but we don’t set it via the config.
https://github.com/ckeditor/ckeditor5/blob/4dcec0134841f465b9102c50b55a903076151d24/packages/ckeditor5-table/theme/table.css#L6-L43
There’s a workaround that makes it work (tested by us), and we should apply it.
We started doing that, but there was a little pushback, pointing to the similar issue we have in alignment. I strongly believe this led us astray. The case of table and cell styles is simpler, we are not speaking here of an equivalent of “unaligned” option (“unstyled”?). We are specifically setting styles in the spreadsheets, and we fail to do exactly what we explain in the docs to integrators.
There was a discussion on border=none issue about the potential confusion when the border is, in fact, reset to none (table and cells). Part of the content may not be visible at all.
Is there anything in there?
Yes, a table.
I’m torn here. By adding some default style to no borders, we break the WYSIWYG principle, on the other hand, invisible content is never good. But, I think the intention of setting a border to none is, in fact, having no border. We should accept that someone may want to set it.
This issue also became more visible with our export to word, border=none is possible in Word, our integrators would need to apply the tweak we have in the comment to make it work.
Border double as the default table style
By default, we set our tables to have a border double. We are unsure why this was chosen. We noticed that during the improvements for export to Word.
That border: 1px double , because of the small width, will look like a solid border on most devices (although it may be displayed as double if user's device has high DPI or if user uses zoom in the browser). This results in issue with Export to Word converter. When exported to Word, the table will have double borders visible, because this is what converter receives as border styles. This may be confusing for customers since most of them may expect to have single border.
This is true, maybe this relates to the CSS resolve border conflicts in the collapsing border model. (ignore for a moment that not all borders are colored)
Let's improve it. When someone sets the border of the cell, they expect it should override the table border. By having the default border of the table the same as the cell, we allow the cell to overwrite the table border and get a more intuitive result. The problem of top cell border not being changed is discussed in the next section.
Possibilities:
- make the border of the table 2px, to make the
doublestyle more visible. - change the table border to
solid. - export to word changes to 1px solid when double 1px. (converter).
- change table border to none.
1px issues we have in changing cell borders (#12713)
Let's go to the issue, of “why some borders of my cell are not styled”. The issue is more visible with the double border, which we explained above. But even with aligned border styles between the table and cells, we notice an issue. The top border of the cell is not colored.
The problem is, that the cell above also has a border style: same width (1px), same style (solid), different color.
If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. When two elements of the same type conflict, then the one further to the left (if the table’s direction is ltr; right, if it is rtl) and further to the top wins. https://drafts.csswg.org/css2/#border-conflict-resolution
Here we most likely face the rule:
When two elements of the same type conflict, then the one further to the left (if the table’s direction is ltr; right, if it is rtl) and further to the top wins.
The top left cell is earlier in the table (more on the left), and its bottom border overwrites the cell. When we style the first cell, such issues are not observed as it has the biggest priority:
This problem is not solvable in a bug fix manner (the browsers’ behavior is a leading force here). The only real solution is to have a possibility of styling each border via UI (https://github.com/ckeditor/ckeditor5/issues/10915, related a bit: https://github.com/ckeditor/ckeditor5/issues/15381).
When styling each border is possible, you would disable the bottom border of the first cell via the UI (border-bottom: none;)
But it works elsewhere
- MS Word (desktop) is not using HTML.
- Word Online, and GDoc are based on canvas.
- Tiny (it works)
- they don’t set the default styles via CSS, but there’s a
border=1 - when they output the data, the cell gets the inline border style and color
style="border-color: #e03e2d; border-style: solid;”this most likely has a higher precedence than theborder=1, which results in a better representation. - I think this is not a solution for us, the attribute is deprecated; it would result in a larger breaking change for our integrators: we would need to set this attribute, and output in the data always the border type along the color.
- they don’t set the default styles via CSS, but there’s a
- CKEditor 4: it didn't collapse the borders by default
Issues no. 1 and no. 2 should be fixed as soon as possible. Thankfully, the PR (#16002) is almost ready, the only thing we could change there is the border solid on the table as a new default.
Conclusions:
- issue no.1: add configuration but to a different place than a PR used. https://github.com/ckeditor/ckeditor5/blob/2b9341bb7932aaf3c1e55132abe940130d569cf9/packages/ckeditor5-table/src/utils/table-properties.ts#L100-L108
- issue no.2: check if exports could apply a heuristic that if
border 1px doublechange it tosolid - issue no.3: close the issue, point to the applying styles to specific borders, update docs, update the issue for borders.
Round 2 of discussions to happen.
There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.
