New website design - #1740
Conversation
Piece 1 of 6 of the camel-website redesign. Covers the font migration to self-hosted Archivo and JetBrains Mono, the palette swap at :root in vars.css, and the container widths. Records three decisions the design handoff left open: splitting --heading-font-weight and --code-font-color where a single token was asked to carry two values, diverging the marketing container (1200px) from the docs article area (1366px), and deferring the dark syntax highlighting theme to its own piece. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Piece numbers become identities rather than sequence; landing order is 1, 6, 2, 3, 4, 5 so the branch is never reviewable with broken code blocks. SCOPE.md section 2a now specifies the dark hljs theme and the chroma mapping, so piece 6 is a spec rather than an open decision. Records that piece 1 cannot merge on its own as a result. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hugo's chroma highlighter puts the .highlight class on the wrapping
div, not the pre, so .doc pre:not(.highlight) matches the pre itself
while base.css's code,kbd,pre rule still paints the nested <code>
with --code-font-color (now ink) directly on the element, beating the
inherited --pre-font-color. Add a minimal .doc pre code { color:
inherit; } rule, specific enough to beat base.css's group rule but not
the higher-specificity .doc pre.highlight code branch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rebuilt from committed source only. The projects.css import was temporarily removed for this build so the tracked bundle matches tracked source; that work is still in progress and untracked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`--color-orange-deep` (#c95f12) measured 3.83:1 on --color-paper and 3.55:1 on --color-paper-2, below the 4.5:1 threshold for normal text. Links land on both surfaces, so both were held to it. Hover was worse: --color-camel-orange at 2.74:1, and lighter than rest, so hovering weakened the link rather than strengthening it. Rest becomes #a84e0d (5.22 / 4.84) and hover a new --color-orange-deeper at #853c09 (7.42 / 6.87). Both keep hue 25deg and ~92% saturation, so they are lightness steps down the existing brand ramp, not a new color. --color-camel-orange is untouched and stays the primary brand orange. Both values deviate from SCOPE.md section 2 and were approved by the design owner. The reasoning is commented at each declaration site. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Piece 1 set --pre-background to --color-ink but left highlight.css on the GitHub light theme, so highlighted code rendered dark-on-dark. This closes that window, per SCOPE.md section 2a. Colors live in vars.css as --syntax-*, one token per row of section 2a, bound by both highlighters so they cannot drift apart. Every value clears 4.5:1 on #211c17. highlight.css keeps its selector groups and swaps hardcoded hex for tokens. chroma.css is new: Hugo emits chroma classes for blog code fences and the repo had no chroma stylesheet at all, so those blocks were never highlighted. Two bindings section 2a implies that were not in place: - --pre-font-color moves off --color-on-dark (#faf7f1) to --syntax-text (#f0e9df). Section 2a reserves #faf7f1 for .hljs-title, so sharing one value made titles indistinguishable from body text. - --syntax-font-weight-strong is 600. --monospace-font-weight-bold is 500 and has other consumers, so it could not be reused. Three class collisions needed language scoping, since one class carries two meanings in the same highlighter: - .hljs-meta is the shell prompt in shell/console/shellsession and Java annotations elsewhere. - chroma .nt is a YAML or JSON key but an XML tag. - chroma .l is an unquoted YAML scalar, which highlight.js calls a string. Section 2a has no row for bare .hljs-attr, which is YAML and JSON keys across roughly 5600 blocks. It takes the attr color so those keys read consistently with XML attributes. Verified by rendering real code blocks from the built tree in headless Chrome, with the real bundle, across java, xml, yaml, json, shell, console, properties and sql on both highlighters. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Header, footer and buttons across both template systems. The finding that shapes the piece: layouts/partials/footer.html and antora-ui-camel/src/partials/footer-content.hbs are supposed to be the same markup and have already drifted in five ways. Rather than rewrite both by hand, the footer content moves into data/chrome.yaml, read natively by Hugo and by a new withChromeData.js helper that mirrors the existing withMenuData.js. Neither js-yaml nor toml is a new dependency. Records five rulings from the design owner where SCOPE.md section 3 is silent or self-contradictory: search stays in the header, Trust moves to the footer, the header keeps GitHub only, the CTA reads Get Started on the home page and /projects/, and the footer takes five columns because "4 columns" and "same link set as today" cannot both hold. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Seven tasks: chrome data file and Antora helper, footer markup, footer CSS, header menu and markup, header CSS, buttons, then bundle regen and final verification. Three findings from reading the code shape the plan and are recorded as global constraints: - algoliasearch.bundle.js assigns container.className wholesale at four points, so #search's parent must carry exactly "navbar-search results-hidden" and no other class, or it is erased on first use. - yarn build:antora cannot run here, so every Antora assertion renders the handlebars partials directly with the handlebars already in node_modules. Proven against the current footer-content.hbs. - yarn is not on PATH; the plan uses the vendored .yarn/releases binary. The load-bearing check is Task 2: extract the footer link set from a built Hugo page and from a directly rendered Antora partial, sort, and diff. It fails today on all five divergences. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
options.fn(this, { data: {...} }) was replacing the block's data frame
wholesale, dropping inherited private variables such as @root. Merge
onto options.data instead so {{@root.uiRootPath}} keeps working inside
the block (needed by the footer logo and social icon asset paths).
Reconciles the pre-existing footer.css cascade with the new footer-brand/footer-column markup instead of appending beside it: retargets the dt/dd rules onto .footer-column so they actually win, scopes footer .footer p to p.remark so .footer-blurb is not overridden, and gives p.remark/.resources/.footer-icons an explicit grid-column so they still span the row now that flex-basis is inert under the new grid. Drops the dead figure.logo and dl:first-child rules the markup no longer produces. Also collapses the grid to a single column in the existing mobile media query, since the grid Step 2 introduces has no responsive variant of its own and the old flex-basis: 100% no longer stacks the accordion columns. --footer-height is bumped from 23rem to 40rem to match the measured height of the five-column layout.
Deletes min-height: var(--footer-height) from the footer rule in footer.css. At desktop the five-column content already renders taller than any reasonable token, so the floor never bound there; at narrow widths, where the accordion collapses columns to their dt labels, it was forcing extra empty ink regardless of actual content height. --footer-height now serves only body.css's sitewide min-height calc, and is set to 39rem: measuring the footer's real rendered height in pixels at 1400px (716px, root font-size 18px), 1000px (933px), and 390px (964px, root font-size 17px below the 1025px breakpoint) shows the desktop figure is the binding constraint once the differing root font-size is factored in, not the mobile one, despite the mobile footer being visually the shorter layout post-collapse. Rounded down from the desktop bound so the token stays a safe underestimate at every width.
Reduce menu.main from seven items to five, reorder them, and drop the per-item pre icons. Rebuild layouts/partials/header.html and antora-ui-camel/src/partials/header-content.hbs onto a shared div.navbar-inner container with a single GitHub icon and a Download/Get Started CTA. Drop the now-unused pre field from withMenuData.js so both template systems stay in sync with config.toml.
The artboards arrived after the spec was written, in Apache Camel website reference.zip. The spec asserted they were unavailable and derived everything from SCOPE.md prose, so that claim is corrected and the measured deltas are recorded for the header and the footer. The artboards confirm the five-column footer resolution: the design really does show four columns with no Documentation column, so the conflict with today's link set was real.
|
3 should likely be 3 DSL |
Every other feature badge says what it counts (350+, AI, EIP, CI, OSS); a bare "3" only makes sense after reading the body underneath it. Reported by davsclaus in review of apache#1740. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
@davsclaus good catch, thanks. Changed to Every other badge in that row (350+, AI, EIP, CI, OSS) names what it counts, so the bare numeral was the odd one out. It will show up on the preview after the next build. |
|
🚀 Preview is available at https://pr-1740--camel.netlify.app |
Reorder the three-path section to CLI, Spring Boot, Quarkus. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Camel CLI card jumped straight to `camel init`, assuming Camel was already installed. Prepend the one-line installer so the fastest path actually shows how to get there. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
🚀 Preview is available at https://pr-1740--camel.netlify.app |
|
the new website looks really nice!! great work @ammachado How where can I open some issues? graphical one mainly |
|
The camel version in https://pr-1740--camel.netlify.app/manual/getting-started.html is not aligned ... Would it be possible to use a placeholder or something similar with the latest released LTS? 4.22.0 at the moment |
|
The menu disappears in https://pr-1740--camel.netlify.app/community/books/ |
|
I don't know if it's just a display issue on my end, but the CONTENTS list on the right could be moved further right, so there's more space for the actual content. This happens in every page with |
|
@davsclaus what about reordering the User Manual menu? for example, the third entry under |
|
Good calls @Croway - however the user guide / docs etc is something we will tackle later. First stop is a modern website for the current. I think we need to let a big AI go over all the docs and help reorganize it and build up a new TOC for it all. |
The content+TOC grid was capped at 1180px, leaving only ~904px for the main content after the 220px TOC and 56px gap. Increase to 1340px so the content column gains ~160px on wide screens. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@Croway thanks for the thorough feedback! Addressing each point: 1) Version misalignment in getting-started page 2) Menu disappears on 3) CONTENTS sidebar too close to content 🤖 Generated with Claude Code |
|
🚀 Preview is available at https://pr-1740--camel.netlify.app |
Group all 39 CSS files into seven @layer tiers (fonts, base, chrome, content, primitives, pages, print) so specificity conflicts between files are resolved by explicit layer order rather than import sequence. Primitives sits before pages so page-specific rules can override shared card/chip/grid defaults without needing higher-specificity selectors. Requires postcss-import >= 15 (lockfile pins 16.2.0). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Introduce a split-complementary teal (#1f6858, 167deg) as a cool counterpoint to the all-orange palette. Applied to three locations: - Homepage stat numbers (evidence, not action) - Blog card dates (temporal metadata) - Community card icon tags (community, not feature) Three tokens added: --color-teal-deep, --color-teal-light, --color-teal-tint. All clear WCAG AA on both paper surfaces (6.18:1 on paper, 5.72:1 on paper-2). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Adds a teal accent (#1f6858) to stat numbers, blog dates, and community tags, breaking the all-orange warmth with a complementary cool tone that still feels natural on the warm palette. Before/after: |
|
🚀 Preview is available at https://pr-1740--camel.netlify.app |
better compared to before, but there's still some space
still no left menu
|
|
In When I first saw the 'Three clear paths' section, I read it as though you have a fast option (CLI), the most popular option (CSB) and then an alternative with no distinguishing headline feature (Quarkus). |
Yeah do you have a suggestion? (maybe Performance or Most performant) or something related to that. |
|
Unsure if it's the preview, but clicking to "component reference" link in https://pr-1740--camel.netlify.app/docs/ opens non styled page with "This file exists solely to defeat the limitations of the link checker, that is unaware of the .htaccess redirect from this page to the latest released version." The property names column are too small (main component). 
It may be related when I changed the word-wrap style. |
Yeah I am struggling for ideas 😅. Maybe 'Cloud native'? |
|
okay lets go with cloud native |
|
The tables are not rendered equally across some components, the opentelemetry shows a background to the property name. https://pr-1740--camel.netlify.app/components/4.22.x/others/opentelemetry.html 
https://pr-1740--camel.netlify.app/components/4.22.x/activemq6-component.html 
It may be related to the way each component .adoc and component-configure-options.adoc partials are rendered. |
Give Quarkus the same badge treatment as Camel CLI (fastest) and Spring Boot (Most popular). Wrap the curl install command with a backslash continuation so it fits within the card at narrow viewports. Widen the frontpage max-width from 1200px to 1400px so the three get-started cards have more breathing room. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
🚀 Preview is available at https://pr-1740--camel.netlify.app |
|
Yes I agree on a standard monitor if you make the browser take up most width on your screen the table is crammed too much, there is alot empty space to the right we can use, to make the table columns wider. 
|
Redesign of camel.apache.org: new design tokens and typography (Archivo, Open Sans, JetBrains Mono), a shared header and footer for the Hugo pages and the Antora docs UI, and redesigned home, docs, projects, tooling, community, download, security, releases and blog pages.
Hugo and Antora templates plus the
antora-ui-camelbundle change; content is mostly untouched apart from copy moved intodata/*.yaml. Design notes and per-piece specs live underdocs/superpowers/.Checks run locally:
hugowith 0 errors,html-validateclean on all Hugo pages after minify,tests/redirect.sh71/71, stylelint clean on the bundle.yarn check:linksstill reports three upstream apache/camel link failures unrelated to this branch.Draft while the design owner reviews the open items recorded in the specs (header fixed vs. sticky, footer column underline, phone-width header search).
🤖 Generated with Claude Code