Hard to interpret the dashes because of line breaks

[s-englert]

WHAT Needs to be Documented?

Improve the visibility of dashes in the keys of MDM configuration paramaters.

WHERE Does This Need To Be Documented (Link)?

https://doc.owncloud.com/ios-app/next/appendices/mdm.html

WHY Should This Change Be Made?

When looking at the key, it's hard to tell if the dash (-) is part of the key, or is because a word is too long to display and spans multiple lines. For example:

item-policy.local-copy-expiration

reads on the webpage as:

item-
poli-
cy.local-
copy-
expira
tion

So it's hard to tell which dashes are part of the keyword and which are because of line breaks.

What Type Of Content Change Is This?

• Existing Content Simplification
• Bug Fix to Existing Content

Manual related to

• iOS MDM

[michaelstingl]

@mmattel we'd need a fix in the https://doc.owncloud.com/assets/css/site.css

Current CSS rule breaks everything:

.doc .content, .doc .tableblock, .doc p {
    -webkit-hyphens: no;
    -ms-hyphens: auto;
    hyphens:auto
}

[mmattel]

Current CSS rule breaks everything

This is not the correct approach, we need to to set the col widths in the table definition correctly in the adoc file. ATM, the col widths set are crap, the build process renders based on that. Fixing this is necessary. Will do a proposal for this.

[mmattel]

Just for the record regarding tables in Antora:
[cols="1,1,1,1"]

The table in the above example will contain four columns. When the specifier is a number, such as 1 or 50, the integer represents the width of the column in proportion to the other columns in the table.

From: https://docs.asciidoctor.org/asciidoc/latest/tables/add-columns/

We have defined them like: [cols="1,2,3,4a,5",options=header] ... no wonder that the result is challenging

[enbrnz]

Why don't we set word-break: break-all; for everything formatted as code globally. That should fix the issue everywhere?

Mozilla developer documentation about the word-break CSS property

[mmattel]

I have checked this with the PR referenced. No wonder, nothing changed as the column with was set as described above. Therefore the css rule cant overwrite this. The column with needs realignment - most likely using ~ which says "auto"...