origam 2.18.21 → 2.20.0

package/dist/src/consts/Kbd/kbd.const.d.ts

@@ -0,0 +1,102 @@
+import type { IKbdProps } from '../../interfaces/Kbd/kbd.interface';
+import type { TVariantPresets } from '../../types/Commons/variant-preset.type';
+import type { TKbdVariant } from '../../types/Kbd/kbd.type';
+/*********************************************************
+ * KBD_VARIANT_PRESETS
+ *
+ * @description
+ * ADR-005 D1 — le premier composant converti. Un variant de Kbd n'est plus
+ * un bloc SCSS : c'est ce sac de props, resolu au rang le plus faible de la
+ * chaine (prop du site d'appel > defaut de theme > PRESET > `withDefaults`).
+ *
+ * @description
+ * ⛔ CHAQUE VALEUR PORTE LA CHAINE `var()` QUE LA REGLE PORTAIT, jamais sa
+ * traduction en echelon semantique. Ecrire `elevation: 'xs'` au lieu de la
+ * chaine litterale reviendrait a emettre `var(--origam-shadow---xs)` et a
+ * JETER le canal `--origam-kbd--{variant}---*` par lequel une marque
+ * rehabille ses touches. Aucun des 8 themes ne touche un token
+ * `origam-kbd` aujourd'hui — c'est meme la raison pour laquelle Kbd est le
+ * pilote, le zero-changement y etant prouvable en isolation — mais le
+ * canal doit survivre a la conversion, sinon la regle ne tiendra pas sur
+ * `OrigamBtn`, dont les 8 marques redeclarent bel et bien
+ * `box-shadow-elevated`, `border-width-outlined` et `background-color-tonal`.
+ *
+ * @description
+ * ⛔ ET C'EST AUSSI CE QUI REGLE LA CASCADE. `key-surface` peint depuis une
+ * regle scopee a (0,2,0), qu'une classe utilitaire a (0,1,0) ne peut pas
+ * battre. Une valeur TOKENISEE (`bgColor: 'primary'`) partirait sur le
+ * canal classe et perdrait donc en silence. Une chaine `var(…)` est routee
+ * par `isCssColor` vers le canal « valeur custom », c'est-a-dire la
+ * declaration INLINE, qui passe devant la regle scopee. La contrainte de
+ * fidelite et la contrainte de cascade demandent la meme chose.
+ *
+ * @description
+ * Les replis de chaque chaine sont conserves tels quels. Ils sont
+ * aujourd'hui INATTEIGNABLES — `light.css` et `dark.css` declarent les six
+ * tokens de variant, et une propriete custom declaree sur `:root` herite
+ * partout, donc le second argument d'un `var()` n'est jamais atteint. Ils
+ * restent parce qu'ils sont la valeur de secours si une feuille cessait de
+ * declarer le token, et parce que le garde `ts-token-refs` exige un repli
+ * des qu'un nom ne peut pas etre borne statiquement.
+ *
+ * @description
+ * ⛔ CE QUE LA TABLE NE POSE PAS EST AUSSI IMPORTANT QUE CE QU'ELLE POSE.
+ * `outlined` ne pose aucune couleur de bordure, et `filled` non plus, alors
+ * que leurs regles en posaient une. Les deux valeurs etaient IDENTIQUES au
+ * defaut de `key-surface` — la regle de `filled` reposait
+ * `var(--origam-color__border---subtle)`, que le token
+ * `--origam-kbd---border-color` porte deja. Les inscrire ici ne serait pas
+ * neutre : un preset emet une declaration INLINE, qui passe devant le
+ * token, donc une marque redeclarant `--origam-kbd---border-color`
+ * cesserait d'atteindre ces deux variants. La table confisquerait le canal
+ * qu'elle est censee servir.
+ *
+ * @description
+ * ⛔ AUCUNE LARGEUR DE BORDURE N'EST POSEE ICI, ET LA RAISON PORTANTE EST
+ * QUE LES TROIS TOKENS DE VARIANT NE PORTAIENT AUCUNE VALEUR PROPRE :
+ * `--origam-kbd--outlined---border-width` et `__filled---border-width`
+ * valent tous deux `var(--origam-border__width---thin)`, c'est-a-dire
+ * exactement le defaut de `key-surface`, et `__tonal---border-width` vaut
+ * `var(--origam-border__width---0)`, c'est-a-dire exactement ce que le
+ * mot-cle `border: 'none'` emet via `BORDER_KEYWORD_WIDTH`. Une indirection
+ * sans valeur distincte : les trois sont donc supprimes des feuilles, ce que
+ * `token-var-channels` prescrit lui-meme pour un token que plus rien ne lit.
+ *
+ * @description
+ * ⚠️ CE PARAGRAPHE A ETE CORRIGE, et l'ecart vaut d'etre connu. Il affirmait
+ * qu'« aucune largeur ne passe par une chaine `var()` » parce que le groupe
+ * `width` de `BORDER_REGEX` n'acceptait que chiffres + unite tandis que son
+ * groupe `color` acceptait `var(--…)` — un `border="var(--…)"` matchait donc
+ * comme COULEUR. Cette moitie est CORRIGEE sur `develop` depuis `cb3c68955`
+ * (lot 5) : le groupe `width` accepte desormais un `var()`, a condition
+ * qu'un mot-cle de style le suive.
+ *
+ * @description
+ * Ce qui RESTE vrai, et qui suffit a la decision : `IBorderProps` n'expose
+ * toujours pas de `borderWidth` autonome, et une largeur `var()` CONTENANT
+ * UNE ESPACE — ce qu'est n'importe quelle chaine a repli, `var(--x, 0px)` —
+ * ne voyage QUE par une prop par cote ou d'axe. La prop globale `border`
+ * fait un `split(' ')` pour distribuer ses 1/2/4 valeurs et coupe donc la
+ * chaine en fragments invalides ; voir l'en-tete de `BORDER_REGEX` et les
+ * trois tests « path » de `border.util.spec.ts`. Un preset qui reintroduirait
+ * une largeur tokenisee devrait viser `borderLeft` / `borderBlock` / …,
+ * jamais `border`.
+ *
+ * @description
+ * Ajouter `borderWidth` a `IBorderProps` a par ailleurs ete tente et REJETE
+ * sur la mesure, independamment de la regex : 24 composants declarent
+ * `IBorderProps` sans consommer ses props autonomes, et le garde
+ * `unconsumed-props` — qui ne peut que retrecir — passait de 0 a 24
+ * nouvelles violations.
+ *
+ * @description
+ * ⚠️ `tonal` portait `box-shadow: none`, le MOT-CLE. `elevation: 'none'`
+ * emet `var(--origam-shadow---none)`, que `primitive.css` declare
+ * `0px 0px 0px 0px rgba(0,0,0,0)`. Le style calcule change donc de `none` a
+ * cette quadruple valeur — une ombre d'etendue nulle et d'alpha nul, qui ne
+ * peut peindre aucun pixel. C'est le SEUL ecart de valeur calculee du lot
+ * sur le chemin « variant nu », et il est mesure et rapporte comme tel
+ * plutot que dissimule : le canal `elevation` n'a aucun moyen d'emettre le
+ * mot-cle, `isOrigamRung` interceptant `'none'` avant tout le reste.
+ ********************************************************/
+export declare const KBD_VARIANT_PRESETS: TVariantPresets<TKbdVariant, IKbdProps>;

package/dist/src/consts/Kbd/kbd.const.js

@@ -0,0 +1,16 @@
+export const KBD_VARIANT_PRESETS = {
+  outlined: {
+    bgColor: "var(--origam-kbd--outlined---background-color, var(--origam-color__surface---raised, #fff))",
+    elevation: "0 1px 0 0 color-mix(in srgb, currentColor 12%, transparent), inset 0 1px 0 0 color-mix(in srgb, white 50%, transparent)"
+  },
+  filled: {
+    bgColor: "var(--origam-kbd__filled---background-color, var(--origam-color__surface---overlay, #f5f5f5))",
+    elevation: "0 1px 2px 0 color-mix(in srgb, currentColor 18%, transparent), inset 0 1px 0 0 color-mix(in srgb, white 60%, transparent)"
+  },
+  tonal: {
+    bgColor: "var(--origam-kbd__tonal---background-color, color-mix(in srgb, currentColor 8%, transparent))",
+    border: "none",
+    borderColor: "transparent",
+    elevation: "none"
+  }
+};

package/dist/src/consts/index.cjs

@@ -520,6 +520,17 @@ Object.keys(_itemGroup).forEach(function (key) {
     }
   });
 });
+var _kbd = require("./Kbd/kbd.const.cjs");
+Object.keys(_kbd).forEach(function (key) {
+  if (key === "default" || key === "__esModule") return;
+  if (key in exports && exports[key] === _kbd[key]) return;
+  Object.defineProperty(exports, key, {
+    enumerable: true,
+    get: function () {
+      return _kbd[key];
+    }
+  });
+});
 var _list = require("./List/list.const.cjs");
 Object.keys(_list).forEach(function (key) {
   if (key === "default" || key === "__esModule") return;

package/dist/src/consts/index.d.ts

@@ -45,6 +45,7 @@ export * from './Menu/menu.const';
 export * from './Commons/mdi.const';
 export * from './Btn/btn-toggle.const';
 export * from './ItemGroup/item-group.const';
+export * from './Kbd/kbd.const';
 export * from './List/list.const';
 export * from './Progress/progress.const';
 export * from './Parallax/parallax.const';

package/dist/src/consts/index.js

@@ -45,6 +45,7 @@ export * from "./Menu/menu.const.js";
 export * from "./Commons/mdi.const.js";
 export * from "./Btn/btn-toggle.const.js";
 export * from "./ItemGroup/item-group.const.js";
+export * from "./Kbd/kbd.const.js";
 export * from "./List/list.const.js";
 export * from "./Progress/progress.const.js";
 export * from "./Parallax/parallax.const.js";

package/dist/src/interfaces/Bracket/bracket-match-component.interface.d.ts

@@ -1,6 +1,6 @@
 import type { IActiveEmits, IActiveProps } from '../Commons/active.interface';
 import type { IBgColorProps, IColorProps } from '../Commons/color.interface';
-import type { IBorderProps } from '../Commons/border.interface';
+import type { TBracketBorderProps } from '../../types/Bracket/bracket.type';
 import type { ICommonsComponentProps, ITagProps } from '../Commons/commons.interface';
 import type { IDensityProps } from '../Commons/density.interface';
 import type { IDimensionProps } from '../Commons/dimension.interface';
@@ -20,7 +20,7 @@ import type { IBracketMatch } from './bracket-match.interface';
  * border, density, dimension, padding, margin) so a standalone card
  * behaves like any other origam component.
  */
-export interface IBracketMatchProps extends ICommonsComponentProps, ITagProps, IColorProps, IBgColorProps, IHoverProps, IActiveProps, IRoundedProps, IElevationProps, IBorderProps, IDensityProps, IDimensionProps, IPaddingProps, IMarginProps {
+export interface IBracketMatchProps extends ICommonsComponentProps, ITagProps, IColorProps, IBgColorProps, IHoverProps, IActiveProps, IRoundedProps, IElevationProps, TBracketBorderProps, IDensityProps, IDimensionProps, IPaddingProps, IMarginProps {
     /** The match payload to render. */
     match: IBracketMatch;
     /**

package/dist/src/interfaces/Bracket/bracket-surface.interface.d.ts

@@ -53,4 +53,43 @@ export interface IBracketSurfaceInput {
     borderRightColor?: TBracketColor;
     borderBottomColor?: TBracketColor;
     borderLeftColor?: TBracketColor;
+    /*********************************************************
+     * LES DEUX ARETES LOGIQUES DE BLOC — ET POURQUOI PAS LES INLINE
+     *
+     * @description
+     * `borderBlockStart` / `borderBlockEnd` (+ `*Color`), issue #1013. Ce
+     * sont les SEULES des quatre aretes logiques que cette couche peut
+     * honorer, et l'asymetrie est mesuree, pas arbitraire.
+     *
+     * @description
+     * Cette couche peint via des custom properties
+     * `--origam-bracket-match---*` que la SCSS d'`OrigamBracketMatch` lit
+     * dans des declarations PHYSIQUES. Mapper une arete logique sur une
+     * arete physique a l'ecriture de la feuille demande donc de connaitre
+     * le mode d'ecriture.
+     * @description
+     * • AXE DE BLOC — `block-start` vaut `top` et `block-end` vaut `bottom`
+     *   en `horizontal-tb`, invariablement. Bracket ne declare jamais
+     *   `writing-mode` (verifie : 0 occurrence) et sa feuille fait DEJA
+     *   cette hypothese pour `borderBlock`, dont la var alimente
+     *   `border-top-width` et `border-bottom-width`. Ces deux aretes
+     *   n'ajoutent donc aucune hypothese nouvelle.
+     * @description
+     * • AXE INLINE — `inline-start` vaut `left` en LTR mais `right` en RTL.
+     *   Aucune chaine de repli ne peut exprimer ca : la substitution
+     *   `var()` est aveugle au mode d'ecriture alors que le mapping de la
+     *   propriete ne l'est pas. Les 4 props inline sont donc RETIREES de la
+     *   surface de Bracket par `Omit<>` (`bracket.interface.ts`) plutot que
+     *   declarees et ignorees — une prop typee et inerte est pire qu'une
+     *   prop absente.
+     *
+     * @description
+     * La completude de Bracket sur l'axe inline part dans son propre
+     * ticket ; elle demande de convertir la cascade en longhands logiques,
+     * ce qui change le comportement RTL des props physiques existantes.
+     ********************************************************/
+    borderBlockStart?: TBracketBorder;
+    borderBlockEnd?: TBracketBorder;
+    borderBlockStartColor?: TBracketColor;
+    borderBlockEndColor?: TBracketColor;
 }

package/dist/src/interfaces/Bracket/bracket.interface.d.ts

@@ -1,14 +1,12 @@
 import type { IBgColorProps, IColorProps } from '../Commons/color.interface';
-import type { IBorderProps } from '../Commons/border.interface';
 import type { ICommonsComponentProps, ITagProps } from '../Commons/commons.interface';
 import type { IDensityProps } from '../Commons/density.interface';
 import type { IDimensionProps } from '../Commons/dimension.interface';
 import type { IElevationProps } from '../Commons/elevation.interface';
 import type { IMarginProps } from '../Commons/margin.interface';
 import type { IPaddingProps } from '../Commons/padding.interface';
-import type { IRoundedProps } from '../Commons/rounded.interface';
 import type { ITypographyProps } from '../Commons/typography.interface';
-import type { TBracketConnectorPath, TBracketVariant } from '../../types/Bracket/bracket.type';
+import type { TBracketBorderProps, TBracketRoundedProps, TBracketConnectorPath, TBracketVariant } from '../../types/Bracket/bracket.type';
 import type { IBracketCompetitor } from './bracket-competitor.interface';
 import type { IBracketMatchCompetitorSlot } from './bracket-match-component.interface';
 import type { IBracketMatch } from './bracket-match.interface';
@@ -24,7 +22,30 @@ import type { IBracketRound } from './bracket-round.interface';
  * data and re-render. No internal state is held about scores or
  * winners — the data passed in is the source of truth.
  */
-export interface IBracketProps extends ICommonsComponentProps, ITagProps, IDensityProps, IRoundedProps, IColorProps, IBgColorProps, IBorderProps, IDimensionProps, IElevationProps, IMarginProps, IPaddingProps, Pick<ITypographyProps, 'fontSize' | 'fontWeight' | 'letterSpacing'> {
+/*********************************************************
+ * Pourquoi les surfaces `border` ET `rounded` sont RESTREINTES ici — #1013
+ *
+ * @description
+ * `OrigamBracket` n'appelle ni `useBorder` ni `useRounded` : il passe
+ * `props` en bloc a `utils/Bracket/bracket-surface.util.ts`, qui emet des
+ * custom properties relues par un SCSS PHYSIQUE. Les props logiques par
+ * cote y sont donc structurellement incablables, et une prop typee,
+ * editable dans Histoire, mais inerte est pire qu'une prop absente.
+ *
+ * @description
+ * Les deux restrictions vivent dans `types/Bracket/bracket.type.ts`, un
+ * type nomme chacune, et portent la mesure qui les justifie :
+ * {@link TBracketBorderProps} retire les 4 aretes INLINE et garde les 2
+ * aretes de bloc (invariantes en `horizontal-tb`, donc cablees) ;
+ * {@link TBracketRoundedProps} retire les 4 coins logiques, car tout nom de
+ * coin est `{bloc}-{inline}` et porte donc une composante inline — le
+ * sursis de l'axe bloc n'existe pas pour un coin.
+ *
+ * @description
+ * Un seul idiome pour les deux moities du lot, volontairement : la
+ * directive du ticket est « si un format existe, il existe partout ».
+ ********************************************************/
+export interface IBracketProps extends ICommonsComponentProps, ITagProps, IDensityProps, TBracketRoundedProps, IColorProps, IBgColorProps, TBracketBorderProps, IDimensionProps, IElevationProps, IMarginProps, IPaddingProps, Pick<ITypographyProps, 'fontSize' | 'fontWeight' | 'letterSpacing'> {
     /**
      * Required. Pre-ordered list of rounds. For single-elimination,
      * the rounds are laid out from earliest (e.g. round-of-16) to

package/dist/src/interfaces/Commons/border.interface.d.ts

@@ -24,6 +24,72 @@ export interface IBorderProps {
      * mapped onto `border-inline-{width,style,color}`.
      */
     borderInline?: boolean | number | string;
+    /*********************************************************
+     * borderInlineStart
+     *
+     * @description
+     * Largeur/style/couleur LOGIQUE PAR COTE pour l'arete inline-start —
+     * gauche en LTR, droite en RTL (#1013). Le jumeau relatif au mode
+     * d'ecriture de `borderLeft`, resolu vers les longhands natifs
+     * `border-inline-start-{width,style,color}`, que le navigateur mappe
+     * lui-meme sur la bonne arete physique.
+     *
+     * @description
+     * A preferer a `borderLeft` des que l'intention de design est « l'arete
+     * ou le texte commence » (filet d'accent d'une citation, indicateur de
+     * nav, guide d'arborescence) : `borderLeft` epingle la peinture a la
+     * gauche physique et inverse silencieusement le design en RTL.
+     *
+     * @description
+     * Meme grammaire de valeur que toute autre prop directionnelle de
+     * bordure — opt-in booleen (token `thin`), largeur numerique nue, ou
+     * chaine libre `"width style color"`.
+     *
+     * @description
+     * Precedence : bat `borderInline` et le `border` global pour cette
+     * seule arete, mais un `borderLeft` PHYSIQUE l'emporte encore en LTR
+     * (les deux orthographes visent la meme arete a specificite egale,
+     * donc le dernier push gagne — voir la table de precedence de
+     * `useBorder`).
+     *
+     * @description
+     * ⚠️ Herite des limites partagees de `BORDER_REGEX` : un `calc()` ou
+     * une largeur fractionnaire (`"0.5rem solid red"`) ne parse pas et
+     * n'emet RIEN — mesure dans `BORDER_LOGICAL_SIDE_MAP`.
+     ********************************************************/
+    borderInlineStart?: boolean | number | string;
+    /*********************************************************
+     * borderInlineEnd
+     *
+     * @description
+     * Jumeau logique par cote de `borderInlineStart` pour l'arete
+     * inline-end — droite en LTR, gauche en RTL. Mappe sur
+     * `border-inline-end-{width,style,color}`. Meme grammaire, memes
+     * regles de precedence (un `borderRight` physique l'emporte en LTR).
+     ********************************************************/
+    borderInlineEnd?: boolean | number | string;
+    /*********************************************************
+     * borderBlockStart
+     *
+     * @description
+     * Jumeau logique par cote de `borderInlineStart` pour l'arete
+     * block-start — le haut dans le mode d'ecriture `horizontal-tb` par
+     * defaut. Mappe sur `border-block-start-{width,style,color}`. Meme
+     * grammaire, memes regles de precedence (un `borderTop` physique
+     * l'emporte).
+     ********************************************************/
+    borderBlockStart?: boolean | number | string;
+    /*********************************************************
+     * borderBlockEnd
+     *
+     * @description
+     * Jumeau logique par cote de `borderInlineStart` pour l'arete
+     * block-end — le bas dans le mode d'ecriture `horizontal-tb` par
+     * defaut. Mappe sur `border-block-end-{width,style,color}`. Meme
+     * grammaire, memes regles de precedence (un `borderBottom` physique
+     * l'emporte).
+     ********************************************************/
+    borderBlockEnd?: boolean | number | string;
     borderColor?: string;
     borderStyle?: string;
     /**
@@ -45,4 +111,61 @@ export interface IBorderProps {
     borderRightColor?: TColor;
     borderBottomColor?: TColor;
     borderLeftColor?: TColor;
+    /*********************************************************
+     * borderInlineStartColor
+     *
+     * @description
+     * Surcharge de couleur PAR ARETE pour l'arete inline-start (#1013) —
+     * le jumeau logique de `borderLeftColor`, emis en
+     * `border-inline-start-color`.
+     *
+     * @description
+     * Memes semantiques que la famille `*Color` physique : additive, bat
+     * toute couleur impliquee par `borderInlineStart` lui-meme (ex.
+     * `borderInlineStart="2px dashed red"`), la couleur d'axe de
+     * `borderInline`, et le `borderColor` / `border` global — pour cette
+     * arete seulement. Un `borderLeftColor` PHYSIQUE l'emporte encore en
+     * LTR, meme sens que pour les props de largeur.
+     *
+     * @description
+     * Accepte un {@link TColor} (intent semantique, couleur CSS brute, ou
+     * valeur fausse pour se desengager). Une bordure est un TRAIT, donc un
+     * intent se resout via la famille de tokens de PREMIER PLAN (comme la
+     * prop `color`), jamais un token de fond.
+     *
+     * @description
+     * Les degrades ne sont PAS supportes — `border-color` en CSS n'a pas de
+     * forme degradee — et sont ignores silencieusement.
+     ********************************************************/
+    borderInlineStartColor?: TColor;
+    /*********************************************************
+     * borderInlineEndColor
+     *
+     * @description
+     * Surcharge de couleur par arete pour l'arete inline-end — jumeau
+     * logique de `borderRightColor`, emis en `border-inline-end-color`.
+     * Meme grammaire {@link TColor} et meme precedence que
+     * `borderInlineStartColor`.
+     ********************************************************/
+    borderInlineEndColor?: TColor;
+    /*********************************************************
+     * borderBlockStartColor
+     *
+     * @description
+     * Surcharge de couleur par arete pour l'arete block-start — jumeau
+     * logique de `borderTopColor`, emis en `border-block-start-color`.
+     * Meme grammaire {@link TColor} et meme precedence que
+     * `borderInlineStartColor`.
+     ********************************************************/
+    borderBlockStartColor?: TColor;
+    /*********************************************************
+     * borderBlockEndColor
+     *
+     * @description
+     * Surcharge de couleur par arete pour l'arete block-end — jumeau
+     * logique de `borderBottomColor`, emis en `border-block-end-color`.
+     * Meme grammaire {@link TColor} et meme precedence que
+     * `borderInlineStartColor`.
+     ********************************************************/
+    borderBlockEndColor?: TColor;
 }

package/dist/src/interfaces/Commons/margin.interface.d.ts

@@ -6,7 +6,10 @@
  *
  *   1. `margin`                       — global shorthand
  *   2. `marginBlock` / `marginInline` — logical axis
- *   3. `marginTop` / `marginRight` / `marginBottom` / `marginLeft`
+ *   3. `marginInlineStart` / `marginInlineEnd` /
+ *      `marginBlockStart` / `marginBlockEnd`  — logical side
+ *   4. `marginTop` / `marginRight` / `marginBottom` / `marginLeft`
+ *      — physical side
  *
  * Each rung only overrides the edge(s) it targets. See
  * `resolveSpacingValue` for the accepted value forms (the directionals
@@ -16,6 +19,9 @@
  * ⚠️ The 4-value `margin` shorthand distributes as
  * **Haut/Gauche/Bas/Droite**, NOT the CSS clockwise order (issue #216).
  * The per-side props exist so you never have to know that.
+ *
+ * ⚠️ Rungs 3 and 4 are EQUALLY specific — see the same note on
+ * `IPaddingProps`. The physical spelling wins for a given edge.
  */
 export interface IMarginProps {
     /**
@@ -36,4 +42,32 @@ export interface IMarginProps {
     marginBlock?: boolean | number | string;
     /** Left + right. Overrides `margin`; beaten by `marginLeft` / `marginRight`. */
     marginInline?: boolean | number | string;
+    /*********************************************************
+     * Logical per-side margin — rung 3 (issue #1013)
+     *
+     * @description
+     * One WRITING-MODE-RELATIVE edge each, emitted as the native logical
+     * longhands (`margin-inline-start`, …) so the browser flips them under
+     * RTL and in vertical writing modes.
+     *
+     * @description
+     * `marginInlineStart` — left in LTR, **right in RTL**.
+     * `marginInlineEnd` — right in LTR, **left in RTL**.
+     * `marginBlockStart` — top in horizontal-tb.
+     * `marginBlockEnd` — bottom in horizontal-tb.
+     *
+     * @description
+     * Same vocabulary as `margin`, the `auto` keyword included — and that
+     * is their best argument: `marginInlineStart="auto"` pushes an element
+     * to the far end of its line in BOTH reading directions, where
+     * `marginLeft="auto"` pushes it the wrong way under RTL.
+     *
+     * @description
+     * Each overrides `margin` and its axis prop for the one edge it
+     * targets, and is beaten by the matching PHYSICAL prop.
+     ********************************************************/
+    marginInlineStart?: boolean | number | string;
+    marginInlineEnd?: boolean | number | string;
+    marginBlockStart?: boolean | number | string;
+    marginBlockEnd?: boolean | number | string;
 }

package/dist/src/interfaces/Commons/padding.interface.d.ts

@@ -6,7 +6,10 @@
  *
  *   1. `padding`                        — global shorthand
  *   2. `paddingBlock` / `paddingInline` — logical axis
- *   3. `paddingTop` / `paddingRight` / `paddingBottom` / `paddingLeft`
+ *   3. `paddingInlineStart` / `paddingInlineEnd` /
+ *      `paddingBlockStart` / `paddingBlockEnd`  — logical side
+ *   4. `paddingTop` / `paddingRight` / `paddingBottom` / `paddingLeft`
+ *      — physical side
  *
  * Each rung only overrides the edge(s) it targets. See
  * `resolveSpacingValue` for the accepted value forms, and
@@ -15,6 +18,14 @@
  * ⚠️ The 4-value `padding` shorthand distributes as
  * **Haut/Gauche/Bas/Droite**, NOT the CSS clockwise order (issue #216).
  * The per-side props exist so you never have to know that.
+ *
+ * ⚠️ Rungs 3 and 4 are EQUALLY specific — `paddingInlineStart` and
+ * `paddingLeft` are two spellings of the same edge in LTR horizontal-tb, so
+ * neither is "more specific" than the other and the tiebreak is a choice,
+ * not a derivation. The physical one wins, which keeps the direction the
+ * repo's only other physical-vs-logical tiebreak already takes (see
+ * `ROUNDED_CORNER_MAP` in `consts/Commons/spacing.const.ts`). Setting both
+ * for one edge is a consumer mistake either way; pick one grid.
  */
 export interface IPaddingProps {
     /**
@@ -35,4 +46,33 @@ export interface IPaddingProps {
     paddingBlock?: boolean | number | string;
     /** Left + right. Overrides `padding`; beaten by `paddingLeft` / `paddingRight`. */
     paddingInline?: boolean | number | string;
+    /*********************************************************
+     * Logical per-side padding — rung 3 (issue #1013)
+     *
+     * @description
+     * One WRITING-MODE-RELATIVE edge each. They emit the native logical
+     * longhands (`padding-inline-start`, …), so the browser flips them
+     * under RTL and in vertical writing modes for you.
+     *
+     * @description
+     * `paddingInlineStart` — left in LTR, **right in RTL**.
+     * `paddingInlineEnd` — right in LTR, **left in RTL**.
+     * `paddingBlockStart` — top in horizontal-tb.
+     * `paddingBlockEnd` — bottom in horizontal-tb.
+     *
+     * @description
+     * Same vocabulary as `padding` (`16`, `"4"`, `"8px"`, `"var(…)"`,
+     * `"calc(…)"`). Each overrides `padding` and its axis prop for the one
+     * edge it targets, and is in turn beaten by the matching PHYSICAL prop
+     * (`paddingLeft` & co) — see the precedence note above.
+     *
+     * @description
+     * Prefer these over the physical four whenever the value is a
+     * reading-order offset — an indent, a gutter beside an accent rule —
+     * rather than a genuinely physical one.
+     ********************************************************/
+    paddingInlineStart?: boolean | number | string;
+    paddingInlineEnd?: boolean | number | string;
+    paddingBlockStart?: boolean | number | string;
+    paddingBlockEnd?: boolean | number | string;
 }

package/dist/src/interfaces/Commons/rounded.interface.d.ts

@@ -3,17 +3,26 @@ import type { TRounded } from '../../types/Commons/rounded.type';
  * Corner-radius surface.
  *
  * Precedence — SPECIFIC beats GLOBAL, same grammar as `IPaddingProps` /
- * `IMarginProps` / `IBorderProps`, with two rungs instead of three (there
- * is no logical-axis form for corners):
+ * `IMarginProps` / `IBorderProps`, with three rungs instead of four (there
+ * is no logical-AXIS form for corners — a corner belongs to both axes at
+ * once):
  *
  *   1. `rounded`                   — global shorthand
- *   2. `roundedTopLeft` / `roundedTopRight` /
- *      `roundedBottomLeft` / `roundedBottomRight`
+ *   2. `roundedStartStart` / `roundedStartEnd` /
+ *      `roundedEndStart` / `roundedEndEnd`      — logical corner
+ *   3. `roundedTopLeft` / `roundedTopRight` /
+ *      `roundedBottomLeft` / `roundedBottomRight`  — physical corner
  *
  * A corner prop only overrides the corner it targets — `rounded="lg"` plus
  * `roundedTopLeft="0px"` flattens one corner and leaves the other three at
  * `lg`. See `resolveRoundedCornerValue` for the accepted value forms and
  * `packages/docs/guide/spacing-and-corners.md` for the full reference.
+ *
+ * ⚠️ Rungs 2 and 3 are EQUALLY specific — `roundedStartStart` and
+ * `roundedTopLeft` are the same corner in LTR horizontal-tb, so the
+ * tiebreak is a choice, not a derivation. The physical one wins, the same
+ * direction `ROUNDED_CORNER_MAP` already documents against the shorthand's
+ * logical output. Pick one grid per component.
  */
 export interface IRoundedProps {
     /**
@@ -40,4 +49,38 @@ export interface IRoundedProps {
     roundedBottomLeft?: boolean | number | string;
     /** Bottom-right corner only. Same vocabulary as `roundedTopRight`. */
     roundedBottomRight?: boolean | number | string;
+    /*********************************************************
+     * Logical per-corner radius — rung 2 (issue #1013)
+     *
+     * @description
+     * One WRITING-MODE-RELATIVE corner each, emitted as the native logical
+     * longhands (`border-start-start-radius`, …) — the same family the
+     * 4-value `rounded` shorthand already emits, so these four address one
+     * of its corners instead of all four.
+     *
+     * @description
+     * ⚠️ THE NAME READS `{block}-{inline}`, per CSS. The first half is the
+     * block end, the second the inline end — it is NOT a clockwise walk,
+     * and the two halves are not interchangeable:
+     *
+     * @description
+     * `roundedStartStart` — block-start inline-start = top-LEFT in LTR.
+     * `roundedStartEnd` — block-start inline-end = top-RIGHT in LTR.
+     * `roundedEndStart` — block-end inline-start = bottom-LEFT in LTR.
+     * `roundedEndEnd` — block-end inline-end = bottom-RIGHT in LTR.
+     *
+     * @description
+     * Swapping the halves silently rounds the opposite corner — nothing
+     * warns, and the result looks deliberate.
+     *
+     * @description
+     * Same vocabulary as `roundedTopRight` (`8`, `'8px'`, `'md'`,
+     * `'large'`, `'var(…)'`), minus `shaped` / `shaped-invert`. Each
+     * overrides `rounded` for its corner and is beaten by the matching
+     * PHYSICAL corner prop.
+     ********************************************************/
+    roundedStartStart?: boolean | number | string;
+    roundedStartEnd?: boolean | number | string;
+    roundedEndStart?: boolean | number | string;
+    roundedEndEnd?: boolean | number | string;
 }

package/dist/src/interfaces/Kbd/kbd.interface.d.ts

@@ -1,11 +1,12 @@
 import type { IBorderProps } from '../Commons/border.interface';
 import type { IBgColorProps, IColorProps } from '../Commons/color.interface';
 import type { ICommonsComponentProps } from '../Commons/commons.interface';
+import type { IElevationProps } from '../Commons/elevation.interface';
 import type { IRoundedProps } from '../Commons/rounded.interface';
 import type { ISizeProps } from '../Commons/size.interface';
 import type { ITypographyProps } from '../Commons/typography.interface';
 import type { TKbdVariant } from '../../types/Kbd/kbd.type';
-export interface IKbdProps extends ICommonsComponentProps, IColorProps, IBgColorProps, ISizeProps, IBorderProps, IRoundedProps, Pick<ITypographyProps, 'fontFamily' | 'fontSize' | 'fontWeight'> {
+export interface IKbdProps extends ICommonsComponentProps, IColorProps, IBgColorProps, ISizeProps, IBorderProps, IElevationProps, IRoundedProps, Pick<ITypographyProps, 'fontFamily' | 'fontSize' | 'fontWeight'> {
     /** Single key label (e.g. "⌘", "Ctrl", "A"). Overridden by the default slot. */
     text?: string;
     /** Composed shortcut rendered as individual nested `<kbd>` elements (e.g. ['Ctrl', 'Shift', 'Z']). */