スタイル、レイアウト、ビジュアルシステム

原則

コンポーネントの役割と見た目を分離します。コンポーネントの種類は小さく保ち、組み合わせ可能なstyle/modifierで表現することを優先します。

{
  "id": "run",
  "type": "Button",
  "props": { "text": "Run" },
  "style": {
    "padding": 16,
    "font": "headline",
    "glass": true,
    "glassInteractive": true
  }
}

実装済みv1 style surface

• padding
• frame (width/height/min/max/alignment)
• font
• fontWeight
• buttonStyle (plain, bordered; デフォルトはHostのprominent/native action style)
• foregroundStyle
• background
• cornerRadius
• opacity
• blur
• shadow
• offset
• scale
• rotation
• overlay
• clipShape
• disabled
• hidden
• animation
• transition
• glass
• glassInteractive

spacing、grid column、ScrollView axisのようにcomponent behaviorを定義するcontainer固有の値は、装飾ではなく動作に関わるためpropsに置けます。

ネイティブ優先の見た目

style値はSwiftUIのsemanticsへ対応付けます。Apsuleは中間のvisual modelとしてCSSを導入しません。これにより出力をiOSと一貫させ、ネイティブLiquid Glass、typography、control、animation、accessibility behaviorをそのまま活用できます。

Theme token

繰り返し使うvisual choiceにはsemantic/theme referenceを優先します。Hostは現在theme.jsonを読み込み、対応style値に使われる$path.to.token形式の文字列を解決します。

{
  "style": {
    "padding": "$spacing.md",
    "cornerRadius": "$radius.card",
    "typography": "$typography.title"
  }
}

将来のWindows Builderでは、直接値の指定とtheme token選択の両方を提供します。components/*.json内の再利用定義もHostによって展開され、呼び出し時のpropsは子孫からprops scopeで参照できます。

Builderへの影響

schemaは次をサポートする必要があります。

• 安定したnode IDによるvisual selection。
• drag/dropによるreparenting。
• 関係のないnodeを書き換えないproperty編集。
• component extraction。
• tokenベースのglobal restyling。
• preview専用device frameとmock state。
• Builder metadataを失わず、AIによるJSON編集をround-tripできること。