# TDX Styling Capabilities Reference # TDX Portal Styling: What's Possible and What Isn't *Reference doc for the Support Portal UI/UX Redesign projectPrepared by Matthew Sparks — IET* ## 1. Two Different Surfaces, Two Different Rule Sets TDX's Client Portal has two distinct content surfaces that behave very differently for design purposes. Any redesign work needs to be scoped against the right one. | Surface | What it is | Styling flexibility | | --- | --- | --- | | **Portal homepages / landing pages / catalog pages** | Built via TDX's **Page** system: drag-and-drop **modules** arranged in columns, governed by the Client Portal's theme/branding settings | Moderate-to-high — real layout control, admin-configurable branding | | **Knowledge Base article content** | Free-form HTML entered in the CKEditor WYSIWYG (or its Source view) | Low — every article passes through a fixed HTML/CSS sanitizer with no per-user or per-admin override | This document focuses mostly on the second surface, since it's the one where the proposal's language ("modern grid layouts," "responsive," "WCAG 2.1 AA") is most likely to overpromise. ## 2. The Core Constraint: The HTML Content Allowlist Every piece of formatted content in TDX (KB articles, service descriptions, HTML modules with sanitization enabled) is filtered against a global **HTML Content Allowlist** before it's displayed. This allowlist controls which HTML tags, attributes, and CSS properties are permitted. Critically: - `<style>`** and **`<link>`** tags are permanently disallowed** — this applies system-wide and cannot be enabled by any admin, at any permission level. There is no toggle for it. - **Inline **`style="..."`** attributes on individual elements are allowed**, but only for CSS properties that are on the allowlist. - **Global/enterprise admins can expand the allowed CSS property and HTML attribute list** in TDAdmin — but this widens what's allowed inline on individual elements, not what's *possible* (grid/flex layout properties and media queries aren't things that can be added to the allowlist, because they don't function meaningfully as inline styles). ## 3. What's Achievable Today (No Admin Changes Needed) Inline `style="..."` on any element already supports: - **Spacing & sizing:** `width`, `height`, `max-width`, `min-width`, `margin`, `padding`, `display` (basic values), `overflow` - **Borders & backgrounds:** `border`, `border-radius`, `box-shadow`, `background-color`, `background-image` - **Typography:** `font-family`, `font-size`, `font-weight`, `color`, `text-align`, `line-height`, `letter-spacing`, `text-decoration` - **Tables:** `border-collapse`, `table-layout`, per-cell padding/borders - **Fluid (not breakpoint-based) responsiveness:** `max-width: 90%`-style percentage scaling, so images/blocks shrink proportionally on narrower screens This is enough for: consistent image framing (borders, shadows, spacing), callout/note boxes, styled tables, custom fonts (see §5), and clean typography. ## 4. What's Not Achievable — At Any Permission Level These are excluded from the allowlist by design and cannot be enabled by any admin: - `<style>`** blocks and external stylesheets** — no way to define reusable CSS rules once and apply them broadly within an article - `@media`** queries** — meaning no true responsive breakpoints (different layouts at different screen widths). Only fluid/proportional scaling is possible. - **CSS Grid / Flexbox layout properties** — `grid-template-columns`, `gap`, `justify-content`, `align-items`, `flex-direction`, etc. are not on the allowlist. `display: grid` or `display: flex` can technically be set, but without these supporting properties they don't produce a functional grid/flex layout. - **Positioning & transforms** — `position`, `top/left/right/bottom`, `z-index`, `transform`, `transition`, `filter` are all permanently disallowed. No overlapping elements, no animations, no stacking control. **Bottom line:** "modern grid layouts" and "responsive... article display formats," as commonly understood in current web design, are not achievable within TDX article content — full stop, not a permissions issue. ## 5. Fonts Custom web fonts (via `@font-face` or `<link>` to a font service) cannot be loaded from within an article. Font choice is limited to: - Fonts already loaded by the Client Portal theme (checkable via browser DevTools → Network tab, filtered by "Font") - Standard web-safe fonts: Georgia, Times New Roman, Arial, Verdana, Tahoma, Trebuchet MS, Segoe UI, Courier New, Consolas ## 6. WCAG 2.1 AA — Partial Feasibility | AA criterion area | Feasible in TDX articles? | | --- | --- | | Semantic heading structure (1.3.1) | Yes — `<h1>`–`<h6>` fully supported | | Text alternatives / alt text (1.1.1) | Yes — `alt` attribute fully supported | | Color contrast (1.4.3) | Yes — `color`/`background-color` are allowlisted, so contrast ratios can be controlled | | Focus visibility (2.4.7) | Partially — `outline` is allowlisted for links/interactive elements within article content | | **Reflow at 400% zoom / 320px width (1.4.10)** | **No** — depends on media queries / responsive breakpoints, which are unavailable | | **Resize text without loss of functionality (1.4.4)** | Partially — fluid scaling helps, but no breakpoint-based layout adjustment | Most **text-content-level** AA criteria are achievable. Criteria that depend on responsive breakpoint behavior are not, given current platform constraints. ## 7. Where Real Flexibility Actually Exists If the goal is genuinely modern, responsive, grid-based design, the right target is the **Page/module system** (homepages, landing pages, catalog pages) and the **Client Portal's theme/branding settings** in TDAdmin — not individual KB articles. These aren't run through the same per-content-field sanitizer, and offer real layout control through TDX's built-in page-building tools. ## 8. Admin-Only Levers (For Scoping Discussion) Two things exist that *do* expand article capabilities, but both require **enterprise/global admin access** in TDAdmin — not something available to a standard KB article editor: 1. **Widening the CSS property/attribute allowlist** — expands what inline styles are permitted, doesn't add layout capabilities. 2. **Client Portal global Styles/branding settings** — defines portal-wide colors/fonts/styles; not per-article, but genuinely reusable across the whole site. Any redesign work that depends on either of these needs to route through an admin (currently: Matthew Sparks) rather than being something student KB authors can implement directly in the article editor. ## 9. Recommended Scoping for the Redesign Project - **Design freely** for homepages/landing pages — real flexibility exists there. - **Design against this document** for article display formats — treat the constraints above as fixed requirements, not obstacles to design around later. - **Flag any admin-dependent asks** (new global classes, wider allowlist) as a request queue through IT, rather than assuming direct implementation access.