You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Locally editable templates and client-selectable presentation modes are not part
of this request. The proposal retains one centrally maintained built-in template
for every client.
Quick checks
I searched existing issues and the public roadmap first.
What problem would this solve?
Problem
The current backend-managed default share block has two related presentation
problems.
It occupies considerably more vertical space than its content requires and
can visually dominate short business messages.
In particular:
short field labels wrap because the label column is fixed at 13ch;
every metadata row uses 6px vertical padding;
introductory paragraphs use 14px bottom margins;
the content and footer have generous independent padding;
the fixed 640 px width prevents the card from sizing naturally to its
contents.
The template fixes the font family and font size independently of the surrounding message. This causes visibly inconsistent typography when the compose window uses different formatting.
Proposed default layout
The proposed template preserves the current blue branding header and the same
functional information, but:
sizes columns according to their content;
keeps short labels on one line;
reduces vertical padding and paragraph spacing;
places related metadata more efficiently;
uses a descriptive link caption rather than displaying the raw URL;
inherits the surrounding message typography where practical.
Because this is the backend-managed default template, the proposed layout is
intended to be shared by the Thunderbird and Outlook connectors. Both clients
should be verified before the change is released.
## Before-and-after measurements
Current rendered height: ~229 px
Proposed rendered height: ~149 px
Reduction: 35 %
Both screenshots use the same content and rendering environment.
Mobile rendering
The fixed 640px width of the current template version also affects mobile readability.
The following side-by-side comparison uses the same message content, device,
mail client, and display settings:
Left: proposed content-sized template
Right: current fixed-width template
In the current version, the mail client scales the entire message down so that
the fixed-width share block fits the viewport. This also reduces the size of the
ordinary message text above the block.
The proposed template uses intrinsic width with max-width: 100%, allowing it
to fit the available mobile viewport without forcing the complete message into
a significantly reduced rendering scale.
What should happen?
Proposed HTML
The visible raw {URL} is replaced by the compact descriptive anchor text Access attachments. This prevents long tokenized URLs from controlling the
intrinsic width of the card. A future mode-aware link-text placeholder could
replace this fixed caption without requiring another layout change.
Compatibility with mode-aware wording
The proposed HTML also provides neutral fallback wording for the related
link-target and wording work tracked in:
It replaces download with access and Download link with the neutral
label Link. This is intended as a release-compatible fallback until the
rendered wording can describe the selected link target dynamically.
<!-- Compact built-in NC Connector share block — drop-in variant. Compatibility goal: - Uses only the currently supported placeholders: {NOTE}, {URL}, {EXPIRATIONDATE}, {PASSWORD}, and {RIGHTS}. - Does not require a new client-side template contract. - Keeps the existing centrally managed presentation model. Layout goal: - Removes the redundant nested branding table. - Uses intrinsic width instead of a fixed 640 px card. - Keeps the metadata row compact and prevents the raw token URL from determining the card width. - Lets the surrounding email provide the font family and base font size.--><divstyle="margin: 12px 0;"><!-- Outer attachment card. width:auto makes the card content-sized; max-width:100% limits it to the available message width where supported. --><tablerole="presentation" border="0" cellspacing="0" cellpadding="0" style="
border-collapse: separate; border-spacing: 0; width: auto; max-width: 100%; margin: 0; background-color: transparent; border: 1px solid #d7d7db; border-radius: 8px; overflow: hidden;"><tbody><!-- Branding header integrated directly into the outer card. --><tr><tdstyle="
padding: 0; background-color: #0082c9; text-align: center; vertical-align: middle; line-height: 0; font-size: 0; border-radius: 7px 7px 0 0;"><ahref="https://nc-connector.de" target="_blank" rel="noopener noreferrer" style="
display: inline-block; text-decoration: none; line-height: 0; font-size: 0; vertical-align: middle;"><!-- The URL fragment prevents the current branding normalizer from restoring the image to 32 px. --><imgsrc="/apps/ncc_backend_4mc/img/runtime/default_share_html_block_template_15c65fda32f2.png?v=2952d086309f"
data-nccb-original-src="https://raw.githubusercontent.com/nc-connector/.github/refs/heads/main/profile/header-solid-blue.png#height-28"
height="28" alt="NC Connector" style="
display: block; height: 28px; width: auto; border: 0; margin: 0 auto;"></a></td></tr><tr><tdstyle="padding: 10px 12px 9px 12px;"><!-- NOTE has its own removable block. When NOTE is empty, the connector can remove this paragraph without affecting unrelated content. --><pstyle="margin: 0 0 6px 0; line-height: 1.3; overflow-wrap: anywhere;">
{NOTE}
</p><!-- Hardcoded wording keeps this variant drop-in compatible. The explicit line break produces a predictable two-part message. This prose can still influence the card's intrinsic width. --><pstyle="margin: 0 0 7px 0; line-height: 1.3; overflow-wrap: anywhere;">
The files have been provided securely and in a privacy-compliant manner via Nextcloud.<br>
You can access them using the link below.
</p><!-- Compact metadata grid. Short labels stay on one line. Unbounded optional values can wrap. --><tablerole="presentation" border="0" cellspacing="0" cellpadding="0" style="
border-collapse: collapse; width: auto; max-width: 100%; margin: 0;"><tbody><tr><!-- Neutral fixed label: valid for either a share-page link or a direct-download link without requiring a dynamic placeholder. --><thscope="row" style="
padding: 3px 10px 3px 0; text-align: left; vertical-align: top; white-space: nowrap; font-weight: bold;">
Link
</th><!-- Descriptive anchor text prevents the long tokenized URL from unnecessarily widening or visually breaking the table. --><tdstyle="
padding: 3px 20px 3px 0; vertical-align: top; white-space: nowrap;"><ahref="{URL}" style="color: #0082c9; text-decoration: none;">Access attachments</a></td><tdcolspan="2" style="
padding: 3px 0; vertical-align: top; white-space: nowrap;"><!-- EXPIRATIONDATE is isolated in a removable DIV. If no expiry exists, pruning this DIV does not remove the essential link. --><div><strong>Expiration date:</strong> {EXPIRATIONDATE}
</div></td></tr><!-- PASSWORD occupies its own row so the complete row can be pruned when no password is present. --><tr><thscope="row" style="
padding: 3px 10px 3px 0; text-align: left; vertical-align: top; white-space: nowrap; font-weight: bold;">
Password
</th><tdcolspan="3" style="
padding: 3px 0; vertical-align: top; overflow-wrap: anywhere; word-break: break-word;"><spanstyle="
display: inline-block; max-width: 100%; padding: 1px 5px; border: 1px solid #c7c7c7; border-radius: 3px; font-family: Consolas, 'Courier New', monospace; white-space: normal; overflow-wrap: anywhere; word-break: break-all;">{PASSWORD}</span></td></tr><!-- RIGHTS occupies its own row so it can be removed independently when attachment mode suppresses permission details. --><tr><thscope="row" style="
padding: 3px 10px 3px 0; text-align: left; vertical-align: top; white-space: nowrap; font-weight: bold;">
Rights
</th><tdcolspan="3" style="
padding: 3px 0; vertical-align: top; overflow-wrap: anywhere; word-break: break-word;">
{RIGHTS}
</td></tr></tbody></table><!-- Compact product attribution retained from the existing template. --><divstyle="
margin: 6px 0 0 0; font-size: 9pt; font-style: italic; line-height: 1.25;">
Shared via
<ahref="https://nextcloud.com/" style="color: #0082c9; text-decoration: none;">Nextcloud</a>.
</div></td></tr></tbody></table></div>
Compatibility note
The HTML above is intentionally a drop-in replacement for the template contract
exposed by the current released backend editor. It therefore uses only the
placeholders available in that release and retains literal introductory and
label text.
Backend main has since introduced {LINK_INTRO} and {LINK_LABEL} while
implementing nc-connector/NC_Connector_for_Thunderbird#26 and #6. When applying
this layout to the current development version, those placeholders can be
retained in the corresponding introduction and label positions without changing
the proposed structure or sizing.
Acceptance criteria
There remains one backend-managed default share template.
No local template editor or per-client template customization is introduced.
Feature support
Tip
Help move this idea forward
Context
This is a narrowly scoped follow-up to
nc-connector/NC_Connector_for_Thunderbird#28.
Locally editable templates and client-selectable presentation modes are not part
of this request. The proposal retains one centrally maintained built-in template
for every client.
Quick checks
What problem would this solve?
Problem
The current backend-managed default share block has two related presentation
problems.
It occupies considerably more vertical space than its content requires and
can visually dominate short business messages.
In particular:
13ch;6pxvertical padding;14pxbottom margins;contents.
Proposed default layout
The proposed template preserves the current blue branding header and the same
functional information, but:
Because this is the backend-managed default template, the proposed layout is intended to be shared by the Thunderbird and Outlook connectors. Both clients should be verified before the change is released. ## Before-and-after measurements
Both screenshots use the same content and rendering environment.
Mobile rendering
The fixed
640pxwidth of the current template version also affects mobile readability.The following side-by-side comparison uses the same message content, device,
mail client, and display settings:
In the current version, the mail client scales the entire message down so that the fixed-width share block fits the viewport. This also reduces the size of the ordinary message text above the block.
The proposed template uses intrinsic width with
max-width: 100%, allowing itto fit the available mobile viewport without forcing the complete message into
a significantly reduced rendering scale.
What should happen?
Proposed HTML
The visible raw
{URL}is replaced by the compact descriptive anchor textAccess attachments. This prevents long tokenized URLs from controlling theintrinsic width of the card. A future mode-aware link-text placeholder could
replace this fixed caption without requiring another layout change.
Compatibility with mode-aware wording
The proposed HTML also provides neutral fallback wording for the related
link-target and wording work tracked in:
It replaces
downloadwithaccessandDownload linkwith the neutrallabel
Link. This is intended as a release-compatible fallback until therendered wording can describe the selected link target dynamically.
Compatibility note
The HTML above is intentionally a drop-in replacement for the template contract
exposed by the current released backend editor. It therefore uses only the
placeholders available in that release and retains literal introductory and
label text.
Backend
mainhas since introduced{LINK_INTRO}and{LINK_LABEL}whileimplementing nc-connector/NC_Connector_for_Thunderbird#26 and #6. When applying
this layout to the current development version, those placeholders can be
retained in the corresponding introduction and label positions without changing
the proposed structure or sizing.
Acceptance criteria
runtime asset URL.
Affected area
Sharing policies / templates
Client impact
Additional context
No response
Implementation issues