RH 2019 new UI: Option to show gridlines of invisible tables in edit mode

[Karin Albrecht]

Hi,

is there an option to show the gridlines of invisible tables in the RH editor? This would make things much easier. However, I could not find such a thing. Is this a missing feature or did I simply search the wrong places?

Thanks and regards
Karin

[Peter Grainge · Accepted solution]

There is no Word equivalent. The only thing I can suggest is a light grey border when working, then apply a master page when you generate where the border in the CSS linked to that is set to None.

[Amebr]

Hmm, I think it's because of behind-the-scenes coding. When you insert a table using the button it hard codes some html properties that are deprecated in HTML5, but are valid for HTML4.

Specifically:

<table border="1" cellpadding="1" cellspacing="1" style="border-collapse:collapse; width:100%">

If you delete border="1" then you should see dashed lines for tables that don't have a border style. 

https://www.w3schools.com/tags/att_table_border.asp

[Karin Albrecht]

Thanks Amebr,

I think this might have worked previous to update 11 (I think I remember seeing this). However, it does no longer work now. If border="1" is removed, no lines are visible in the edit mode at all.

Best regards

Karin

[Amebr]

The screenshot I took is with update 11, so maybe there is some other setting in your stylesheet. Check if you have the border set to white on the plain table style?

[Karin Albrecht]

Indeed, if I only remove the code you said from the default code, it works with dashed lines. However, as soon as a table style is applied, it doesn't. This is the css for my invisible table: 

table.Invisible td {
  padding-top: 3px;
  padding-right: 3px;
  padding-bottom: 3px;
  padding-left: 3px;
}

If I create a table in a topic by using the insert table function, then remove border="1" from the default code, the dashed lines are shown. Code looks as follows:

 <table cellpadding="1" cellspacing="1" style="border-collapse:collapse; width:100%">

If I create a table in a topic by using the insert table function, then select the table and assign the invisible table style, the dashed lines disappear. Code looks as follows:

 <table cellpadding="1" cellspacing="1" class="Invisible" style="border-collapse:collapse; width:100%">

If I do not remove the border="1" and assign my invisible table style, the table does not become invisible at all but keeps its frames in the edit mode and in the preview. Code looks as follows:

 <table border="1" cellpadding="1" cellspacing="1" class="Invisible" style="border-collapse:collapse; width:100%">

The problem seems to be something with the table style, but I don't understand why. However, if I use a table style, I have to remove the default code added by RH. Otherwise, the padding and spacing definitions exist twice (once in the default code and once in the css style) and this causes problems with the Word output.

Any further ideas?

Thanks and best regards

Karin

[Amebr]

Hmm I see what you mean.

I create a blank table without applying the style and deleted the border="1" code. The dashed lines appeared.

I manually typed the following style so I could select a style for the table. It has no styling so theoretically shouldn't change how the table displays.

table.Invisible {}

I selected the style and the dashed lines disappeared.

I think this might be technically correct for web display (there are no borders defined, so no borders should display), but for the editor I think Adobe might need to do some extra coding so that there are editing gridlines visible, like there are for a table without a style applied.

You can report issues here: https://tracker.adobe.com/

In the meantime, Peter's suggestion might work, although it's a bit tiresome.

[Peter Grainge]

Like Amber I cannot solve this one so it does look like a feature request is needed.

Meantime why is it tiresome? Once set up, that's it. Topics have the CSS with the grey border and outputs have the master page whose CSS has no border.

[Amebr]

For me, workarounds are always tiresome (I like investigating them, just not implementing them). Remembering why you've done something a particular way and remembering to confirm later whether it's necessary any more. I try to write good notes, but I don't always succeed. 🙂

I once got a new job where the help had been set up by a previous colleague. They'd re-implemented a workaround I'd implemented at a previous job, which hadn't been needed in probably 6 years, but had never been reversed because of time constraints. And they hadn't realised because that was just the way they'd always done it. 🙂

[Peter Grainge]

@amber I agree a proper solution is always best but when the problem is something in the program code, that can't be fixed other than by Adobe, it's down to workarounds. Tiresome, maybe, but better than figuring out where the cells are.

[Karin Albrecht]

Thank you both for your support! I will create a feature request and in the meantime implement a work around.

Best regards

Karin