Redesign homepage hero section#173
Conversation
# Conflicts: # layouts/_default/baseof.html # layouts/index.html
|
Warning Review limit reached
Next review available in: 6 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
WalkthroughThe home hero is replaced with a two-panel split layout for Cryptomator and Hub, with new hero scene CSS and hover-gated motion. Shared theme tokens move into Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
assets/css/custom.css (1)
262-268: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low valuePersistent
will-changeon idle decorative nodes.
will-change: transform(andtransform, opacity) is declared statically on ~9 hero elements (here, plus the travelers, key, auth, anchor icons, hub img). Since animations are disabled until.hero-panel:hover, these elements sit idle most of the time yet keep the browser holding compositor layers, wasting memory on a high-traffic landing page. Consider moving thewill-changehints into theprefers-reduced-motion: no-preferencehover block alongside theanimation-nameactivations so the promotion is scoped to when motion is actually running.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@assets/css/custom.css` around lines 262 - 268, The `.hero-scene-logo-img` class has a static `will-change: transform` declaration that keeps the browser maintaining compositor layers even when animations are idle, wasting memory. Remove the `will-change: transform` property from the static `.hero-scene-logo-img` rule and move it into a hover-activated state within a `prefers-reduced-motion: no-preference` media query block, so the compositor layer promotion only occurs when the animation is actually running. Apply the same refactoring pattern to all approximately 9 hero elements mentioned (travelers, key, auth, anchor icons, hub img, and others) that have static `will-change` declarations.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@assets/css/custom.css`:
- Around line 96-140: The stylelint declaration-empty-line-before rule requires
a blank line between `@apply` at-rules and regular CSS declarations. In the
.hero-split-panels class, add a blank line after the `@apply` statement and before
align-items: stretch. In the .hero-panel class, add a blank line after the
`@apply` statement and before the background property. In the .hero-scene class,
add a blank line after the `@apply` lg:scale-[1.1] statement and before position:
relative. These blank lines separate the at-rule from regular property
declarations as required by the linter.
- Around line 799-811: The stylelint rule `declaration-empty-line-before` is
failing because the `text-wrap: balance;` declarations in the `.font-h1`,
`.font-h2`, and `.font-h3` classes are not preceded by an empty line after the
`@apply` declarations. Add an empty line before each `text-wrap: balance;`
statement in all three font classes to satisfy the stylelint requirement and
pass the static analysis checks.
---
Nitpick comments:
In `@assets/css/custom.css`:
- Around line 262-268: The `.hero-scene-logo-img` class has a static
`will-change: transform` declaration that keeps the browser maintaining
compositor layers even when animations are idle, wasting memory. Remove the
`will-change: transform` property from the static `.hero-scene-logo-img` rule
and move it into a hover-activated state within a `prefers-reduced-motion:
no-preference` media query block, so the compositor layer promotion only occurs
when the animation is actually running. Apply the same refactoring pattern to
all approximately 9 hero elements mentioned (travelers, key, auth, anchor icons,
hub img, and others) that have static `will-change` declarations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0fab1194-0b98-44ba-b876-8857bbedd600
⛔ Files ignored due to path filters (2)
static/img/logo-hub.pngis excluded by!**/*.pngstatic/img/logo-hub.svgis excluded by!**/*.svg
📒 Files selected for processing (7)
assets/css/custom.cssassets/css/main.cssi18n/de.yamli18n/en.yamllayouts/_default/baseof.htmllayouts/index.htmllayouts/partials/nav.html
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@layouts/pricing/single.html`:
- Line 165: The logo image in the pricing template is being forced into a square
shape by the `aspect-square` class, which distorts the native proportions of
`zero-knowledge-bot.svg`. Update the `<img>` styling in the pricing layout so
the mascot keeps its original ratio, either by removing `aspect-square` or
replacing it with sizing that matches the SVG’s native dimensions, and apply the
same fix to any repeated logo slots using this asset.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f39b3940-b411-4c2b-97c3-12f15b88d328
⛔ Files ignored due to path filters (2)
static/img/zero-knowledge-bot.pngis excluded by!**/*.pngstatic/img/zero-knowledge-bot.svgis excluded by!**/*.svg
📒 Files selected for processing (6)
assets/css/custom.csslayouts/downloads/list.htmllayouts/for-teams/single.htmllayouts/index.htmllayouts/pricing/single.htmllayouts/solutions/single.html
🚧 Files skipped from review as they are similar to previous changes (2)
- layouts/index.html
- assets/css/custom.css
| <h3> | ||
| <div class="flex items-center"> | ||
| <img src="/img/logo.svg" class="hidden md:block h-8 mr-2 aspect-1110/942" alt="Logo"/> | ||
| <img src="/img/zero-knowledge-bot.svg" class="hidden md:block h-8 mr-2 aspect-square" alt="Logo"/> |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect the SVG viewBox/width/height to confirm it's square
fd -a 'zero-knowledge-bot.svg' | xargs -I{} sh -c 'echo "== {} =="; grep -oE "viewBox=\"[^\"]*\"|width=\"[^\"]*\"|height=\"[^\"]*\"" "{}" | head -5'Repository: cryptomator/cryptomator.github.io
Length of output: 281
Keep zero-knowledge-bot.svg on its native ratio.
It’s 887×877, not square, so aspect-square will slightly distort or pad the mascot in all four logo slots. Match the SVG’s ratio or provide a true 1:1 asset.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@layouts/pricing/single.html` at line 165, The logo image in the pricing
template is being forced into a square shape by the `aspect-square` class, which
distorts the native proportions of `zero-knowledge-bot.svg`. Update the `<img>`
styling in the pricing layout so the mascot keeps its original ratio, either by
removing `aspect-square` or replacing it with sizing that matches the SVG’s
native dimensions, and apply the same fix to any repeated logo slots using this
asset.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@assets/css/main.css`:
- Line 15: The stylesheet import ordering is wrong: `@import` './theme.css' is
placed after `@plugin/`@config, which can cause the CSS pipeline to reject it and
drop design tokens. Move the `@import` rule to the top of the stylesheet before
any `@plugin` or `@config` directives, keeping the existing theme.css reference
intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 790cbf54-2c11-4ac3-a679-c3836867cf36
📒 Files selected for processing (6)
assets/css/custom.cssassets/css/hero.cssassets/css/main.cssassets/css/theme.csslayouts/_default/baseof.htmllayouts/index.html
💤 Files with no reviewable changes (1)
- assets/css/custom.css
🚧 Files skipped from review as they are similar to previous changes (1)
- layouts/index.html
| --color-current: currentColor; | ||
| --color-black: #000; | ||
| --color-white: #fff; | ||
| @import './theme.css'; |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Inspect the first ~20 lines of main.css to verify `@import` ordering
sed -n '1,20p' assets/css/main.cssRepository: cryptomator/cryptomator.github.io
Length of output: 538
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## main.css\n'
sed -n '1,120p' assets/css/main.css
printf '\n## tailwind-related files\n'
git ls-files | rg '(^|/)(tailwind|postcss|vite|css|package\.json|astro|next|nuxt|svelte|webpack|rollup|parcel|build).*' || true
printf '\n## search for theme.css and Tailwind directives\n'
rg -n "theme\.css|`@plugin`|`@config`|`@layer`|`@import`" assets . --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**'Repository: cryptomator/cryptomator.github.io
Length of output: 3598
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## package.json\n'
sed -n '1,220p' package.json
printf '\n## config files mentioning tailwind or lightning css\n'
rg -n "tailwind|lightning|postcss|`@config`|`@plugin`|`@theme`|`@import`" . --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**'Repository: cryptomator/cryptomator.github.io
Length of output: 8945
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## assets/css/theme.css\n'
sed -n '1,200p' assets/css/theme.css
printf '\n## any stylelint config\n'
git ls-files | rg '(^|/)\.stylelintrc|stylelint|package\.json$' || true
rg -n "stylelint|Invalid position for `@import`|`@import` rule" . --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**'Repository: cryptomator/cryptomator.github.io
Length of output: 4367
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## assets/css/theme.css\n'
sed -n '1,200p' assets/css/theme.css
printf '\n## stylelint-related config/search\n'
git ls-files | rg '(^|/)\.stylelintrc|stylelint|package\.json$' || true
rg -n "stylelint|Invalid position for `@import`|`@import` rule" . --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**'Repository: cryptomator/cryptomator.github.io
Length of output: 4378
🌐 Web query:
Tailwind CSS v4 @config @plugin @import order Lightning CSS later import rules will cause an error to be emitted
💡 Result:
In Tailwind CSS v4, the architecture relies on native CSS features—such as @import and cascade layers—to manage the style pipeline [1][2]. The requirement that @import rules must appear at the top of a CSS file is a fundamental CSS specification rule [3]. If other CSS rules (like @layer, @theme, or standard CSS) precede an @import statement, browsers or build tools will emit an error or a warning, effectively breaking the CSS injection [3]. Regarding the interaction with Lightning CSS and directives in v4: 1. Directive Ordering: Tailwind v4 effectively replaces the old @tailwind directives with a primary @import "tailwindcss"; directive [1][4]. This single import handles the necessary preflight reset, theme, and utility layers in the correct cascade order [1]. If you import layers individually (e.g., @import "tailwindcss/utilities" layer(utilities);), you must ensure these imports remain at the top of your file [3][1]. 2. Lightning CSS Conflicts: Tailwind v4 is designed as a superset of Lightning CSS [5]. While Tailwind uses Lightning CSS internally, issues can arise when external build tools (like Vite or Next.js) are configured to run Lightning CSS as a secondary transformer on the output [5][6]. Specifically: - When external tools perform a second pass with Lightning CSS, they may incorrectly rewrite or transform Tailwind-specific syntax (such as the light-dark() function or complex @apply rules) because they do not recognize the context of the Tailwind-generated CSS [5][6]. - Known conflicts have been observed when css.transformer is set to "lightningcss" in Vite, as it can interfere with how Tailwind processes @apply or resolves imports [5]. 3. Plugin and Configuration: Custom plugins should be imported using the @plugin directive, typically placed after the main @import "tailwindcss"; statement, but before other CSS rules that might depend on them [7]. If you encounter errors where plugins or utilities are not being applied correctly, ensure they are not being processed after the primary Tailwind engine has already finalized the CSS output [8]. To avoid these errors, adhere to these practices: - Keep all @import statements at the absolute top of your CSS files [3]. - Ensure your entry stylesheet starts with @import "tailwindcss"; [1][4]. - Avoid configuring secondary build tools (like Vite's css.transformer) to perform independent CSS transformations that conflict with the Tailwind v4 engine [5][6]. - If you need to manage custom cascade layers or plugin order, define them using explicit layer() specifications on your @import statements to maintain correct precedence [9][2].
Citations:
- 1: https://htmlgenie.net/tailwind-v4-oxide-engine-broke-my-postcss-pipeline/
- 2: Unexpected behavior when overloading classes tailwindlabs/tailwindcss#19781
- 3: CSS @import not placed on top of file resulting in warning (effectively error) tailwindlabs/tailwindcss#16663
- 4: https://tailwindcss.com/blog/tailwindcss-v4
- 5: [v4] Vite plugin breaks when setting
css.transformerto"lightningcss"tailwindlabs/tailwindcss#14205 - 6: light-dark function gets wrongly transformed by lightning css tailwindlabs/tailwindcss#18849
- 7: [v4] How to add plugins? tailwindlabs/tailwindcss#13292
- 8: [v4] Plugins registered after
@tailwindcss/postcssdo not work tailwindlabs/tailwindcss#15138 - 9: Incorrect import order with nested layers tailwindlabs/tailwindcss#19931
🌐 Web query:
site:tailwindcss.com v4 @plugin @configorder before@import tailwindcss
💡 Result:
In Tailwind CSS v4, the @import "tailwindcss" directive is the primary way to include Tailwind, replacing the v3 @tailwind directives [1]. If you are using a JavaScript configuration file, you must load it explicitly using the @config directive [1][2]. Regarding the order of directives, you should place @import "tailwindcss" before the @config directive. Following standard CSS specifications (which require @import statements to precede other rules), @import should come first [3]. While v4 handles imports and vendor prefixing automatically—removing the need for separate postcss-import or autoprefixer plugins—maintaining the order of @import before @config ensures compatibility with how CSS parsers handle directives [1][3]. Regarding @plugin: If you are using custom plugins in v4, they are generally registered within your configuration file (or as part of the Tailwind setup) rather than via a standalone @plugin directive in your CSS [4]. Summary of correct order for v4: 1. @import "tailwindcss"; 2. @config "./tailwind.config.js"; 3. Other directives (e.g., @source, @apply) [1][5]
Citations:
- 1: https://tailwindcss.com/docs/upgrade-guide
- 2: https://v3.tailwindcss.com/docs/v4-beta
- 3: https://v3.tailwindcss.com/docs/functions-and-directives
- 4: https://v3.tailwindcss.com/docs/configuration
- 5: https://tailwindcss.com/docs/detecting-classes-in-source-files
🌐 Web query:
site:tailwindcss.com/docs @plugin @config Tailwind CSS v4 order
💡 Result:
In Tailwind CSS v4, the approach to configuration has moved to a "CSS-first" model [1]. Instead of relying on a standalone tailwind.config.js file as the primary configuration method, you can now define customizations directly within your CSS file using Tailwind-specific directives and the @theme theme block [1]. Key points regarding configuration in v4 include: 1. CSS-First Configuration: You configure design tokens, content sources, plugins, and other settings directly in the CSS file where you import Tailwind [1]. 2. Directive Usage: You use directives such as @theme to define theme variables (like colors, spacing, and fonts) and @source to manage content detection [1][2]. 3. Legacy Support: While the new CSS-first approach is the standard for v4, it remains possible to use a legacy tailwind.config.js file if necessary, though it is no longer the required workflow [1]. 4. Order of Precedence: Because configuration now resides in your CSS, the order in which you define these rules within your CSS file follows standard CSS cascade rules [1]. Customizations defined later in the file or imported later will generally take precedence over earlier definitions [1]. For specific implementation details, the official Tailwind CSS documentation on "CSS configuration" provides a comprehensive guide on migrating from the old JavaScript-based configuration to the new CSS-based workflow [1].
Citations:
- 1: https://v3.tailwindcss.com/docs/v4-beta
- 2: https://tailwindcss.com/docs/detecting-classes-in-source-files
🌐 Web query:
site:tailwindcss.com/docs "@plugin" "@config" "order" "Tailwind CSS v4"
💡 Result:
In Tailwind CSS v4, the @config directive is used to explicitly load a JavaScript configuration file for backward compatibility, as these files are no longer automatically detected [1]. The @plugin directive is also available in v4 to register plugins directly within your CSS [2]. Regarding order: 1. @config Directive: While Tailwind CSS v4 focuses on a CSS-first configuration approach, if you must use a legacy JavaScript config file, the @config directive should be placed at the top of your CSS entry point file [1]. This ensures the configuration is loaded before Tailwind processes your other CSS directives. 2. @plugin Directive: The @plugin directive allows you to import and use plugins directly within your CSS, which is part of the v4 shift toward CSS-driven configuration [2]. 3. General Best Practice: When working with CSS directives like @import (if using postcss-import), @config, and @plugin, ensure that your standard CSS imports are managed correctly to avoid conflicts. Specifically, if using tools like postcss-import, remember that CSS specifications require @import statements to appear at the very beginning of the file, before other rules like @config or @plugin [3]. In summary, for Tailwind v4, use @config to bridge legacy JS configurations and @plugin to manage functionality directly in your CSS [2][1]. Always place your @import statements first if your build pipeline mandates strict CSS specification compliance [3].
Citations:
- 1: https://tailwindcss.com/docs/upgrade-guide
- 2: https://tailwindcss.com/docs/functions-and-directives
- 3: https://v3.tailwindcss.com/docs/functions-and-directives
🌐 Web query:
site:tailwindcss.com/docs "@import \"tailwindcss\"" "@plugin" "@config" css-first order
💡 Result:
In Tailwind CSS (v4 and later), the order of CSS directives follows standard CSS specification requirements [1]. Because browsers and CSS processors enforce strict rules regarding @import statements, they must appear at the top of your CSS file, before any other rules, including @config or @plugin directives [2][1]. When using these directives, adhere to the following order: 1. Standard CSS @import statements (e.g., for fonts or other CSS files) [1]. 2. The @import "tailwindcss" directive [1][3]. 3. Configuration and plugin directives such as @config and @plugin [4][2]. While Tailwind CSS v4 simplifies the integration by using a single @import "tailwindcss" statement instead of the older @tailwind base/components/utilities directives [5][6], the fundamental requirement that @import statements must precede other non-import rules remains [1]. Placing @config or @plugin before your @import "tailwindcss" statement can cause issues, as CSS processors may treat them as violations of the CSS specification [2]. Always ensure your Tailwind import is positioned to account for any external CSS imports while remaining before your configuration and plugin definitions [2][1].
Citations:
- 1: https://tailwindcss.com/docs/font-family
- 2: https://v3.tailwindcss.com/docs/functions-and-directives
- 3: https://tailwindcss.com/docs/installation/tailwind-cli
- 4: https://tailwindcss.com/docs/functions-and-directives
- 5: https://tailwindcss.com/docs/upgrade-guide
- 6: https://v3.tailwindcss.com/docs/v4-beta
🌐 Web query:
site:tailwindcss.com/docs "@config" "must be placed" "after" "import"
💡 Result:
The instruction that the @config directive must be placed after any @import statements specifically refers to Tailwind CSS [1]. In Tailwind CSS projects, if you are using the @config directive to specify a custom configuration file, it should not be placed before your @import statements [1]. Placing it before @import can cause the directive to fail, as the configuration needs to be processed in the correct order relative to the CSS imports to take effect properly [1][2]. [1][2]
Citations:
- 1: https://v3.tailwindcss.com/docs/functions-and-directives
- 2: https://v3.tailwindcss.com/docs/using-with-preprocessors
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n "main\.css|theme\.css|`@plugin`|`@config`|`@import` \"tailwindcss\"|Lightning CSS|Tailwind CSS v4|order" README.md assets layouts content . --glob '!**/node_modules/**' --glob '!**/dist/**' --glob '!**/build/**' || trueRepository: cryptomator/cryptomator.github.io
Length of output: 50390
🌐 Web query:
site:tailwindcss.com/docs "@plugin" "Tailwind CSS v4" "CSS-first"
💡 Result:
In Tailwind CSS v4, the architecture has shifted to a CSS-first approach, meaning configuration and extensibility are primarily handled directly within your CSS files rather than in a JavaScript-based configuration file [1][2]. The @plugin directive is used in Tailwind CSS v4 to load legacy JavaScript-based plugins directly within your CSS [1]. It accepts either a package name or a local file path [1]. For example: @plugin "@tailwindcss/typography"; Key aspects of this shift in Tailwind CSS v4 include: CSS-First Configuration: You can use directives like @theme, @utility, and @config alongside @plugin within your CSS to define your design tokens, utilities, and configuration [1]. Values defined directly in CSS will typically take precedence over those defined in other configuration sources [1]. Legacy Plugin Support: While Tailwind v4 encourages defining custom utilities and styles in CSS, the @plugin directive provides a bridge for existing JavaScript-based plugins [1]. Removal of JS Config: Many configuration options previously found in the JavaScript-based tailwind.config.js file (such as corePlugins, safelist, and separator) have been removed or replaced with CSS-based alternatives in v4 [1]. Upgrade Note: Tailwind CSS v4 is a significant evolution that moves away from the previous reliance on a central JavaScript configuration file, treating Tailwind itself as the preprocessor [3]. Plugins that were previously added to a plugins array in a config file are now integrated via CSS [1].
Citations:
- 1: https://tailwindcss.com/docs/functions-and-directives
- 2: https://v3.tailwindcss.com/docs/v4-beta
- 3: https://tailwindcss.com/docs/upgrade-guide
Move @import './theme.css' above @plugin/@config. Later imports can be rejected by the CSS pipeline, which would drop the design tokens.
🧰 Tools
🪛 Stylelint (17.14.0)
[error] 15-15: Invalid position for @import rule (no-invalid-position-at-import-rule)
(no-invalid-position-at-import-rule)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@assets/css/main.css` at line 15, The stylesheet import ordering is wrong:
`@import` './theme.css' is placed after `@plugin/`@config, which can cause the CSS
pipeline to reject it and drop design tokens. Move the `@import` rule to the top
of the stylesheet before any `@plugin` or `@config` directives, keeping the existing
theme.css reference intact.
2 participants
Reworks the homepage hero into a calmer, two-edition layout (Cryptomator + Hub).