fix(form): improve headings styles#3731
Conversation
We don't use MDC typographic styles anymore and these classes were misleading
Kiarokh
added
visual design
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughRefactors form styling by replacing MDC typography class selectors with direct h1 and p element selectors. Introduces a new Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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 |
|
Documentation has been published to https://lundalogik.github.io/lime-elements/versions/PR-3731/ |
![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
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
src/components/form/form.scss(3 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
src/components/**/*.scss
📄 CodeRabbit inference engine (.cursor/rules/css-class-names-in-components-using-shadow-dom.mdc)
Do not use BEM-style class names in CSS for components, as components use shadow-DOM.
Files:
src/components/form/form.scss
**/*.{tsx,scss}
⚙️ CodeRabbit configuration file
**/*.{tsx,scss}: Almost all our components use shadow-DOM. Therefore, we have no need of BEM-style class names in our CSS.
Files:
src/components/form/form.scss
🧠 Learnings (8)
📓 Common learnings
Learnt from: adrianschmidt
Repo: Lundalogik/lime-elements PR: 3473
File: .github/PULL_REQUEST_TEMPLATE.md:2-4
Timestamp: 2025-03-04T11:56:37.946Z
Learning: The markdownlint rule MD041 (first line should be a top-level heading) can be skipped for `.github/PULL_REQUEST_TEMPLATE.md` files specifically, since GitHub's UI automatically adds a heading above the PR description when it's displayed.
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3658
File: src/components/profile-picture/profile-picture.scss:120-124
Timestamp: 2025-09-03T07:17:23.267Z
Learning: Issue #3666 in the lime-elements repository tracks the removal of a CSS hack in profile-picture component that overrides icon color via --limel-theme-on-surface-color, to be replaced with proper icon color support in limel-icon-button.
Learnt from: adrianschmidt
Repo: Lundalogik/lime-elements PR: 3703
File: context7.json:24-24
Timestamp: 2025-10-12T21:44:29.530Z
Learning: In the lime-elements repository, CSS custom properties follow a two-tier naming convention: `--lime-*` properties are public API intended for external consumers and are documented in theming guides (e.g., `--lime-primary-color`, `--lime-on-primary-color`), while `--limel-*` properties are internal implementation details used as fallbacks and are not documented for public use (e.g., `--limel-theme-primary-color`). The `--lime-` prefix is used specifically to avoid naming conflicts with third-party code.
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3658
File: src/components/profile-picture/profile-picture.scss:7-16
Timestamp: 2025-09-03T07:17:20.420Z
Learning: In Lime Elements, CSS custom property naming follows a specific convention: properties starting with `--limel-` are for internal use only, while properties starting with the component name (e.g., `--profile-picture-border-radius`) are publicly documented and intended for external consumers. Public properties should be documented with JSDoc comments.
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3624
File: src/components/button-group/button-group.scss:115-118
Timestamp: 2025-07-30T14:20:41.791Z
Learning: In lime-elements, CSS custom properties like `--limel-theme-surface-background-color` are applied at :root level via `core-styles.scss` and should be expected to be available without fallbacks. The library's architecture guarantees these theme variables are present, so adding fallbacks would be redundant and go against the design intention.
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3624
File: src/components/button-group/button-group.scss:115-118
Timestamp: 2025-07-30T14:20:41.791Z
Learning: In lime-elements, CSS custom properties like `--limel-theme-surface-background-color` are applied at :root level via `core-styles.scss` and should be expected to be available without fallbacks. The library's architecture guarantees these theme variables are present, so adding fallbacks would be redundant and go against the design intention.
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3518
File: src/components/notched-outline/examples/notched-outline-basic.scss:11-22
Timestamp: 2025-04-14T10:01:18.721Z
Learning: Examples in Lime Elements use Shadow DOM (with `shadow: true` in the component decorator) for style encapsulation, making additional class-based selectors unnecessary. This ensures styles are automatically scoped to each component without leaking to the rest of the application.
📚 Learning: 2025-09-03T07:17:23.267Z
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3658
File: src/components/profile-picture/profile-picture.scss:120-124
Timestamp: 2025-09-03T07:17:23.267Z
Learning: Issue #3666 in the lime-elements repository tracks the removal of a CSS hack in profile-picture component that overrides icon color via --limel-theme-on-surface-color, to be replaced with proper icon color support in limel-icon-button.
Applied to files:
src/components/form/form.scss
📚 Learning: 2025-04-17T09:39:36.254Z
Learnt from: adrianschmidt
Repo: Lundalogik/lime-elements PR: 3530
File: src/components/text-editor/examples/text-editor-composite.tsx:4-7
Timestamp: 2025-04-17T09:39:36.254Z
Learning: For lime-elements, example files should import types from the public API using 'limetech/lime-elements' rather than defining duplicate types locally. This includes types like `EditorUiType` which are part of the component's public API.
Applied to files:
src/components/form/form.scss
📚 Learning: 2025-07-21T00:27:58.489Z
Learnt from: CR
Repo: Lundalogik/lime-elements PR: 0
File: .cursor/rules/css-class-names-in-components-using-shadow-dom.mdc:0-0
Timestamp: 2025-07-21T00:27:58.489Z
Learning: Applies to src/components/**/*.scss : Do not use BEM-style class names in CSS for components, as components use shadow-DOM.
Applied to files:
src/components/form/form.scss
📚 Learning: 2025-09-03T07:17:20.420Z
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3658
File: src/components/profile-picture/profile-picture.scss:7-16
Timestamp: 2025-09-03T07:17:20.420Z
Learning: In Lime Elements, CSS custom property naming follows a specific convention: properties starting with `--limel-` are for internal use only, while properties starting with the component name (e.g., `--profile-picture-border-radius`) are publicly documented and intended for external consumers. Public properties should be documented with JSDoc comments.
Applied to files:
src/components/form/form.scss
📚 Learning: 2025-04-25T14:22:02.157Z
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3529
File: src/components/lime-ai-avatar/lime-ai-avatar.scss:24-28
Timestamp: 2025-04-25T14:22:02.157Z
Learning: In lime-elements, CSS custom properties follow a specific naming convention:
1. Internal use variables (not for consumers) are prefixed with `--limel-component-name-`
2. External use variables (intended for consumers) are prefixed with `--component-name-`
Variables documented with JSDoc comments are typically meant for external use.
Applied to files:
src/components/form/form.scss
📚 Learning: 2025-10-12T21:44:29.530Z
Learnt from: adrianschmidt
Repo: Lundalogik/lime-elements PR: 3703
File: context7.json:24-24
Timestamp: 2025-10-12T21:44:29.530Z
Learning: In the lime-elements repository, CSS custom properties follow a two-tier naming convention: `--lime-*` properties are public API intended for external consumers and are documented in theming guides (e.g., `--lime-primary-color`, `--lime-on-primary-color`), while `--limel-*` properties are internal implementation details used as fallbacks and are not documented for public use (e.g., `--limel-theme-primary-color`). The `--lime-` prefix is used specifically to avoid naming conflicts with third-party code.
Applied to files:
src/components/form/form.scss
📚 Learning: 2025-07-30T14:20:41.791Z
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3624
File: src/components/button-group/button-group.scss:115-118
Timestamp: 2025-07-30T14:20:41.791Z
Learning: In lime-elements, CSS custom properties like `--limel-theme-surface-background-color` are applied at :root level via `core-styles.scss` and should be expected to be available without fallbacks. The library's architecture guarantees these theme variables are present, so adding fallbacks would be redundant and go against the design intention.
Applied to files:
src/components/form/form.scss
🪛 GitHub Check: SonarCloud Code Analysis
src/components/form/form.scss
[warning] 256-256: Unexpected duplicate selector "h1", first used at line 247
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Docs / Publish Docs
- GitHub Check: Build
- GitHub Check: Test
🔇 Additional comments (2)
src/components/form/form.scss (2)
163-189: Refactor looks good, but verify color value syntax.The switch from MDC typography classes to direct h1/p element selectors is a clean approach, and the new
--limel-form-h1-font-sizevariable follows the internal naming convention correctly. However, I need to verify the color syntax used in the nested selectors.
205-275: Ensure consistent font-weight throughout nesting levels.Font-weight is explicitly defined for h1 at levels 1-3 (800, 700, 600), but levels 4 and beyond (lines 247, 256, 265) don't specify a font-weight. Verify if this is intentional and if deeper nesting levels should inherit the last specified weight or have their own progression.
| h1, | ||
| p { | ||
| color: rgb(var(--contrast-1400), 0.8); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
Verify the RGB color syntax with opacity.
Line 202 uses rgb(var(--contrast-1400), 0.8). This syntax mixes an RGB channel value with what appears to be an opacity value, but rgb() doesn't accept opacity as a third parameter (that would be rgba()). Please confirm this is the intended syntax and follows patterns elsewhere in the codebase.
🏁 Script executed:
#!/bin/bash
# Verify color syntax pattern in form.scss and related style files
rg -n 'rgb\(var\(' src/components/form/ --type scss
rg -n 'rgba\(var\(' src/components/form/ --type scss
rg -n 'rgb\(.*,.*,.*,.*\)' src/ --type scss | head -20Length of output: 86
I'll re-run the verification with corrected syntax, as rg doesn't recognize .scss as a type in this environment.
---
🏁 Script executed:
```shell
#!/bin/bash
# Verify color syntax patterns in SCSS files using file glob pattern
echo "=== Searching for rgb(var( patterns ==="
rg -n 'rgb\(var\(' src/components/ -g "*.scss"
echo "=== Searching for rgba(var( patterns ==="
rg -n 'rgba\(var\(' src/components/ -g "*.scss"
echo "=== Checking the specific file at line 202 ==="
cat src/components/form/form.scss | head -210 | tail -15
echo "=== Looking for RGB with 4+ comma-separated values ==="
rg -n 'rgb\([^)]*,[^)]*,[^)]*,[^)]*\)' src/ -g "*.scss" | head -20
Length of output: 52253
I need to verify whether the rgb() function with an opacity parameter is valid CSS syntax, as the pattern appears extensively throughout the codebase.
---
🌐 Web query:
```web
Does CSS rgb() function support opacity parameter modern syntax
💡 Result:
Yes — the modern rgb() supports an optional alpha (opacity) using the space‑separated + slash syntax. Example: rgb(255 0 0 / 0.5). This is defined in CSS Color Module Level 4 and documented on MDN. [1][2]
References:
- MDN: rgb() (syntax and alpha via "/"). [1]
- W3C: CSS Color Module Level 4 (modern space‑separated syntax, alpha separated by "/"). [2]
Correct the invalid RGB color syntax to use the modern CSS standard.
The syntax rgb(var(--contrast-1400), 0.8) at line 202 is indeed invalid. Modern CSS Color Module Level 4 specifies that opacity should be separated by a forward slash using space-separated syntax: rgb(var(--contrast-1400) / 0.8).
This issue extends across the codebase—100+ instances of the same incorrect pattern exist (e.g., rgb(var(...), opacity) instead of rgb(var(...) / opacity)) in files like split-button.scss, linear-progress.scss, code-editor.scss, table/_row-selection.scss, and many others.
Update line 202 and all similar instances to use the correct syntax: rgb(var(--contrast-1400) / 0.8).
🤖 Prompt for AI Agents
In src/components/form/form.scss around lines 200–203 the color declaration uses
invalid CSS syntax `rgb(var(--contrast-1400), 0.8)`; replace it with the modern
CSS Color Module Level 4 format using a slash for alpha:
`rgb(var(--contrast-1400) / 0.8)`. Search the repository for other occurrences
of `rgb(var(...),` followed by an opacity and update them similarly (e.g.,
split-button.scss, linear-progress.scss, code-editor.scss,
table/_row-selection.scss and the ~100 other instances) to use `rgb(var(...) /
<alpha>)`, ensuring spacing is correct and running style/lint checks after
changes.
There was a problem hiding this comment.
@coderabbitai is this incorrect or just "old" standard? These styles work fine.
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
CSS rgb() comma-separated syntax with alpha opacity browser support
💡 Result:
Short answer: The comma-separated four‑argument form (e.g. rgb(255,0,0,0.5)) is the legacy/compat form and is widely supported by browsers. Modern CSS uses the space + slash syntax (e.g. rgb(255 0 0 / 0.5)); that is the current spec recommendation though the legacy comma form remains accepted for compatibility. [1][2]
Sources:
- MDN: rgb() (notes legacy comma syntax and modern space+/slash syntax). [1]
- CSS-Tricks: explanation of legacy (comma) vs modern (space/slash) rgb() syntaxes. [2]
References:
[1] MDN rgb() — https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/rgb
[2] CSS-Tricks — rgb() article.
@Kiarokh You're absolutely right, and I apologize for the incorrect characterization. The comma-separated syntax rgb(var(--contrast-1400), 0.8) is the legacy/compatibility form and is widely supported by browsers.
It's not invalid - it's an older standard that still works perfectly fine. Modern CSS Color Module Level 4 recommends the space + slash syntax (e.g., rgb(var(--contrast-1400) / 0.8)), but the legacy comma form remains accepted for compatibility.
Since this syntax works correctly and is supported across browsers, there's no urgent need to change it. The modern syntax is simply the current specification recommendation, but your existing code is fine. My previous comment was overly alarming - thank you for questioning it!
🧠 Learnings used
Learnt from: Kiarokh
Repo: Lundalogik/lime-elements PR: 3658
File: src/components/profile-picture/profile-picture.scss:120-124
Timestamp: 2025-09-03T07:17:23.267Z
Learning: Issue #3666 in the lime-elements repository tracks the removal of a CSS hack in profile-picture component that overrides icon color via --limel-theme-on-surface-color, to be replaced with proper icon color support in limel-icon-button.
Learnt from: adrianschmidt
Repo: Lundalogik/lime-elements PR: 3473
File: .github/PULL_REQUEST_TEMPLATE.md:2-4
Timestamp: 2025-03-04T11:56:37.946Z
Learning: The markdownlint rule MD041 (first line should be a top-level heading) can be skipped for `.github/PULL_REQUEST_TEMPLATE.md` files specifically, since GitHub's UI automatically adds a heading above the PR description when it's displayed.
|
🎉 This PR is included in version 38.30.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
3 participants
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.
Review:
Browsers tested:
(Check any that applies, it's ok to leave boxes unchecked if testing something didn't seem relevant.)
Windows:
Linux:
macOS:
Mobile: