@visns-studio/visns-components 6.17.2 → 6.20.0

package/src/components/styles/Form.module.scss

@@ -51,7 +51,7 @@
         left: 0;
         padding: 19px 13px;
         border-radius: var(--radius);
-        border: 1px solid rgba(var(--paragraph-rgb), 0.15);
+        border: 1px solid rgba(var(--paragraph-rgb, 43, 43, 43), 0.15);
         box-shadow: none;
     }
 
@@ -173,7 +173,41 @@ select {
     box-sizing: border-box;
 
     > span {
-        color: rgba(255, 77, 77, 1.4);
+        color: rgba(255, 77, 77, 1);
+    }
+}
+
+/*
+ * Native date/time inputs. WebKit lays the value out in an internal
+ * ::-webkit-datetime-edit box pinned to the input's TOP, so any height the
+ * input gains beyond its own line box — padding rules sized against the text
+ * inputs beside it — becomes empty space UNDER the value: the dd/mm/yyyy
+ * text and the calendar glyph ride high while every neighbouring field
+ * centres. Flexing the input and centring the inner box fixes Chrome and
+ * iOS Safari both; Firefox centres already and ignores the vendor parts.
+ */
+input[type='date'],
+input[type='time'],
+input[type='month'],
+input[type='week'],
+input[type='datetime-local'] {
+    display: inline-flex;
+    align-items: center;
+
+    &::-webkit-datetime-edit {
+        display: flex;
+        align-items: center;
+        padding: 0;
+    }
+
+    &::-webkit-date-and-time-value {
+        /* iOS Safari gives the value a top margin inside the flexed input. */
+        margin: 0;
+        text-align: left;
+    }
+
+    &::-webkit-calendar-picker-indicator {
+        margin-block: 0;
     }
 }
 
@@ -312,7 +346,7 @@ input[type='file'] {
 
     .btn {
         background: var(--primary-color);
-        border: 1px solid rgb(var(--primary-rgb), 1.05);
+        border: 1px solid rgb(var(--primary-rgb, 27, 57, 51), 1);
         width: 100%;
         padding: 0.75rem;
         border-radius: var(--br);
@@ -473,3 +507,89 @@ input[type='file'] {
         min-width: 200px;
     }
 }
+
+/* ============================================================================
+ * 2026 pass — the form's action bar
+ * ----------------------------------------------------------------------------
+ * It was a centred row whose primary button rendered full-bleed across the
+ * form, sitting inside the scroll area with no Cancel next to it. Three things
+ * wrong with that, in order of how much they cost:
+ *
+ *   1. It scrolls away. On a form longer than the panel, the only way to save
+ *      is to scroll to the bottom first — and the taller the form, the more
+ *      likely the user has already lost track of whether it saved.
+ *   2. A full-width primary is a phone pattern. On a 560px sheet it reads as a
+ *      banner, and it gives "Save" the same visual weight as the whole form.
+ *   3. There was no Cancel. The only way out was the X in the corner or the
+ *      Escape key, neither of which is where anyone looks for it.
+ *
+ * Right-aligned with the primary last, which is the desktop convention and
+ * puts the confirming action nearest the thumb on the scrollbar side.
+ * ==========================================================================*/
+
+.buttonContainer {
+    position: sticky;
+    bottom: 0;
+    z-index: 2;
+
+    display: flex;
+    /* Primary last, on the right. */
+    justify-content: flex-end;
+    gap: 0.5rem;
+
+    /* Full bleed to the panel edges, so the bar reads as chrome rather than as
+       another form row floating inside the content. */
+    margin: 1.25rem -1rem -1rem;
+    padding: 0.75rem 1rem;
+    border-top: 1px solid var(--border-color, rgba(43, 43, 43, 0.12));
+    background: var(--background-color, #fff);
+
+    /* `.buttonContainer .btn` rather than `.buttonContainer button`, because
+       `.modal__content .btn` (0,2,0) sets `width: 100%` and beats a
+       class-plus-element selector (0,1,1). That `width: 100%` is why the
+       primary rendered 496px wide — exactly the content box of this bar —
+       while Cancel sat at its natural 76px beside it. */
+    .btn,
+    .btnSecondary {
+        /* Was `min-width: 200px`, which is what made a two-button row overflow
+           a narrow sheet and a one-button row look like a banner. */
+        flex: 0 0 auto;
+        min-width: auto;
+        width: auto;
+        padding: 0 1.1rem;
+    }
+}
+
+/* The quiet half of the pair. Present but not competing: a Cancel that looks
+   like a second primary makes the user read both before acting. */
+.btnSecondary {
+    display: inline-flex;
+    align-items: center;
+    justify-content: center;
+    min-height: var(--control-height, 2.5rem);
+    padding: 0 1.1rem;
+    border: 1px solid var(--border-color, rgba(43, 43, 43, 0.16));
+    border-radius: var(--btn-br, var(--radius-sm, 6px));
+    background: transparent;
+    color: var(--paragraph-color, #2b2b2b);
+    font-family: inherit;
+    font-size: var(--font-size-sm, 0.8125rem);
+    font-weight: var(--font-weight-semibold, 600);
+    line-height: 1;
+    white-space: nowrap;
+    cursor: pointer;
+    transition:
+        background-color var(--speed, 160ms) var(--ease, ease),
+        border-color var(--speed, 160ms) var(--ease, ease);
+
+    &:hover {
+        background: var(--hover-color, rgba(27, 57, 51, 0.06));
+        border-color: var(--border-color-dark, rgba(43, 43, 43, 0.3));
+    }
+
+    &:focus-visible {
+        outline: none;
+        box-shadow: 0 0 0 3px
+            color-mix(in srgb, var(--highlight-color, #3cbf7d) 30%, transparent);
+    }
+}