テーマ改善前後のHTML・CSS構造を比較する
テーマ改善では、色やクラス名に加えて、CSSの優先順位を分けるレイヤーと、レイアウトを受け持つ箱が変わります。 一方、項目外側のField構造や通常項目の幅など、残る部分もあります。
このページは通常版1.5.8.1と、UiThemesPreflightの動作確認モジュール1.5.8.9を比較します。通常版の構造は画面のHTML・CSSとレイアウト、確認環境の準備とPleasanterUiLintはテーマ改善への備えを参照してください。動作確認モジュールで確認した内容を、未公開の正式版の仕様へ広げないでください。
比較資料と確認範囲
公式配布案内は resources/official/Implem.Pleasanter.UiThemesPreflight にsubmoduleで保持しています。このリポジトリには本体のソースやCSSはなく、CSSは公式リリース1.5.8.9の配布ZIPに含まれます。
| 資料 | このページで確認したこと |
|---|---|
通常版の公式ソース 8d29c7bd | CSSの読み込み、フォーム・項目の生成、従来の配置 |
配布案内 1231e72d | ベース版・モジュール版、UI世代と配色の分離、独自コードへの影響 |
| 配布ZIPのCSS | @layer、色変数、MainFormとeditor-content、項目幅・コンポーネントの宣言 |
| 調査ドキュメントの実画面比較 | 項目内・カンバン・カレンダーなどのDOM、UIタイプ1と2のHTMLの関係 |
配布CSSを今回直接解析し、DOMの比較には既存の実画面調査を使っています。新しいDOMの親子関係を、CSSセレクタの名前だけから推測していません。本体のC#・SCSSソースが公開されていないため、新版の内部生成処理まで同じ方法で追えるわけではありません（公式配布案内、実画面比較の結果）。
配布物を照合するときの情報
- 配布ファイルは
Pleasanter_1.5.8.9.zip。 - SHA-256は
3c2c63ce159d94a518a5f6c43491ee877d5d8228318c3c6d6be4ec12c7f2e58a。 - ZIP内のCSSの基点は
pleasanter/Implem.Pleasanter/wwwroot/assets/。 - 本文の新版CSSの宣言は主に
css/style-type2.min.cssを解析したもの。第一世代・レスポンシブのCSSへ一律に当てはめない。 - 配色の照合には
themes/*.css、共通jQuery UIにはplugins/jquery-ui/jquery-ui.min.cssを使う。
submoduleのコミットと配布ZIPのバージョン・ハッシュは別の情報です。submoduleを更新してもZIPの中身が取り込まれるわけではありません。
1. テーマがレイアウトを選ぶ構成から、UIタイプと配色を分ける構成へ
通常版はテーマ名でCSS用の世代を決めます。第二世代の style.scss は legacy.scss を読み込み、その上へ新しい定義を重ねます。テーマ別のjQuery UIと custom.css も組み合わせます（世代の判定、CSSの読み込み、legacyの取り込み）。
図を読み込み中…
図の矢印は選択・参照関係で、すべてのCSSの読み込み順を表すものではありません。新版の本体CSSには style-type1.min.css・style-type2.min.css と、それぞれのresponsive版があります。テーマCSSは themes/cerulean.css のような1ファイルになり、jQuery UIはテーマ別フォルダから共通のpluginsフォルダへ移っています。
UIタイプ1を選んでも、通常版のHTMLへ戻るわけではありません。 既存の実画面調査では、同じ動作確認モジュールのUIタイプ1・2はbodyのクラス以外が同じHTMLでした。旧セレクタが壊れたときに、UIタイプの変更だけを修正の代わりにしないでください（UIタイプと実画面の比較）。
2. 本体CSSの中に9つのカスケードレイヤーがある
配布された style-type2.min.css は、次の名前順で @layer を定義しています。
reset → vendors → overwrite → appearance → utilities
→ components → layouts → modules → sections| レイヤー | 配布CSSで確認できる内容の例 |
|---|---|
| reset | 要素の初期化 |
| vendors | 外部ライブラリ関連 |
| overwrite | ライブラリ側の定義の調整 |
| appearance | 基本色、派生色、フォント、アプリケーション用の変数 |
| utilities | 共通の補助クラス |
| components | field-normal、ラジオ、チェック、選択、添付などの要素 |
| layouts | editor-contentなど、画面の大きな配置 |
| modules | BreadcrumbListなどのスタイル |
| sections | 一覧・カレンダーなど画面領域のスタイル |
名前だけで役割を決めず、実際の宣言がどの @layer に入るかをStylesで確認します。また、FullCalendar用変数などレイヤー外の宣言もあるため、本体CSSの全宣言が9層だけに入るわけではありません。
セレクタが強くても、レイヤーで負ける場合がある
同じオリジン・通常宣言では、後のレイヤーが先のレイヤーより優先し、レイヤー外の宣言はレイヤー内より優先します。詳細度を比較する前に、レイヤーの順位が関係します。!important はレイヤーの優先順が逆になるため、通常宣言の図をそのまま使えません（CSSのカスケードレイヤー仕様）。
図を読み込み中…
例えば、次はCSSの優先順位を理解するための独立した例です。プリザンターの配布CSSの転載ではありません。
@layer example-base, example-page;
@layer example-base {
#ExamplePanel .example-note { color: red; }
}
@layer example-page {
.example-note { color: blue; }
}通常宣言ではexample-pageが後なので、後者のセレクタの詳細度が低くてもblueが選ばれます。移行時は !important を足す前に、対象要素、通常・importantの区分、レイヤー、詳細度を調べます。
3. 配色は「全変数の値をテーマに持つ」方式から派生色へ
通常版のceruleanは custom.css に多数の色変数を定義します。新版のプリセットceruleanは、カラーモードと --primaryColor・--secondaryColor・--backgroundFixed を定義します。派生色の計算は本体CSS側です。
図を読み込み中…
style-type2.min.css には、相対色の oklch(from …)、色を混ぜる color-mix()、ライト・ダークで値を選ぶ light-dark() があります。例えば --app-text はライト・ダークの2色、--controller-bg は白と、アプリ背景から作る色を使い分けます。テーマCSSの変更だけでなく、参照先の変数とカラーモードを合わせて確認します。
今回の配布CSS解析でも、通常版ceruleanの213変数のうち、新版のtype2と全テーマCSSに残るものは117、定義がないものは96でした。新版側全体の変数名は423種類です。この件数は定義の有無の比較で、変数の意味や色が同じことを保証しません。
| 通常版で参照しているもの | 新版で調べること |
|---|---|
--base-text | 旧定義はない。アプリ文字色の --app-text など、対象の新しい用途別変数を確認 |
--control-bg・--control-border | 旧定義はない。入力部品の --controller-bg・--controller-border とその参照箇所を確認 |
--editor-bg | 旧定義はない。editor-contentが使うsub-bg・frame-bgなどを確認 |
--primaryColor・--grid-cell-bg | 名前は残る。派生式やlight-darkによる値の違いを確認 |
この表は調査先の案内で、一括置換表ではありません。同じ用途の色であるかを、Styles・Computedとライト・ダークの画面で確認してから変更します。変数名の全体の差はCSS変数の変化も参照してください。
4. MainFormのIDが残っても、レイアウトの箱は変わる
通常版の第二世代CSSは #Editor #MainForm をFlexにし、背景・影・コメント側の疑似要素をこのフォームへ付けます（フォームのレイアウト）。
新版type2の配布CSSでは、#MainForm に display: contents、#Editor .editor-content に display: flex・背景・影などを指定します。
図を読み込み中…
この図はCSS宣言の適用先の比較です。新版の生成HTMLの親子関係をすべて示す図ではありません。
display: contents は要素をDOMから削除せず、その要素自身のレイアウト用の箱を作らない指定です。したがって、IDでMainFormを見つけられることと、MainFormの背景・枠・余白を画面の箱として使えることは別です（displayの箱生成の仕様）。
例えば、旧カスタムCSSが #Editor #MainForm に背景やborderを付けている場合は、移行先で .editor-content のComputedと実際の箱を確認します。新しい枠へ付ける修正の出発点は次のようになります。これは動作確認モジュールの第二世代UI用の例です。
#Editor .editor-content {
border: 1px solid var(--app-border);
border-radius: 8px;
}他の画面の #MainForm にまで当てず、Editorへ限定しています。最終の枠、内側の背景、子要素のはみ出しは検証環境で確認してください。
5. 外側のFieldは残り、内側の部品構造が変わる
実画面比較では、項目IDと Field 付きID、外側のfield-normal・field-wide・field-label・field-control・container-normalは残っています。配布type2 CSSでも通常項目の幅340px、ラベル幅120px、入力側の左余白120px、項目のfloat配置が確認できます。フォーム全体の箱の変更を、すべての項目が新しいGrid配置になった変更だと解釈しないでください（実画面比較、従来の項目配置）。
図を読み込み中…
新版CSSの .c-radio-group はFlex・折り返し・gapで並べ、.c-attachments は縦方向のFlexです。部品の内側が一段増えると、旧CSSの直下指定や親を一つだけ辿るスクリプトは別の意味になります。
| 場所 | 通常版 | 動作確認モジュール | 修正時の確認先 |
|---|---|---|---|
| ラジオ | container-radio → radio-option | c-radio-group → c-radio | wrapperを含めた並びと余白 |
| チェック | label.check-option | label.c-checkbox | ラベルを含めたクリック領域 |
| 読取専用 | span.control-text | span.control-readonly | 入力可能なtextboxと分けた指定 |
| 選択 | div.select-field > select | div.c-select > select | select本体と外枠の違い |
| 添付 | container-normal直下に入力・uploadなど | c-attachmentsの中へ入る | 直下セレクタと追加要素の挿入先 |
| 日付 | date-field.date-field | date-field.c-date-field | 要素名とクラス名の区別 |
通常のtextboxの control-textbox は残っています。読取専用の control-text が変わったことを、すべてのテキスト入力のクラス変更と取り違えないでください。上のDOMの根拠は既存の実画面比較です。
例えば、ラジオの余白を調整する旧CSSと新版の調査先は次のように分けます。サンプルは通常の記録テーブルの分類Aを対象にします。
/* 通常版用 */
#Results_ClassAField .container-radio > .radio-option {
margin-right: 12px;
}
/* 動作確認モジュール用。親のgapで間隔を調整する */
#Results_ClassAField .c-radio-group {
gap: 8px 12px;
}旧ラベルのmarginを新ラベルへそのまま移すと、親のgapと重なります。名前の置換だけでなく、どの要素が間隔を作っているかを確認してください。
6. カンバン・クロス集計・カレンダーは親子関係も比較する
通常の一覧の表と、各ビューの構造を混同しないことが重要です。実画面調査のカンバン・クロス集計では、通常版のgrid-containerの階層がなくなり、tableの外側・セル内の構造が変わっています。
図を読み込み中…
省略したthead・tbody・trも含めた詳細は実画面比較の表で確認できます。#GridWrap のscrollTopを読む独自コードや、.fixed を前提にした幅指定は、新しい対象の箱まで追う必要があります。このカンバンの結果を、すべての通常一覧でgrid-containerが消える変更として一般化しないでください。
FullCalendarでは、残る #FullCalendar の外側に #Calendar.fullcalendar-container があり、内側は #FullCalendar.fullcalendar-body になります。外側全体の幅・背景と、ライブラリが描画する領域への指定を分けます。クロス集計でも、残る #CrosstabBody と、なくなる中間の枠・行クラスを別々に確認します。
7. 両方の画面で同じ調査コードを動かす
同じ項目配置の記録テーブルを用意し、通常版と動作確認モジュールの編集画面で、次をブラウザのConsoleに貼ります。DOM、Computed、矩形、変数の有無をまとめて出力します。設定やレコードは更新しません。
(function () {
const selectors = [
'#MainForm', '#Editor .editor-content', '#EditorTabsContainer',
'#EditorComments', '#Results_ClassAField',
'#Results_ClassAField .container-normal',
'#Results_ClassAField .container-radio',
'#Results_ClassAField .c-radio-group'
];
console.table(selectors.map(function (selector) {
const element = document.querySelector(selector);
if (!element) return { selector, exists: false };
const style = getComputedStyle(element);
const rect = element.getBoundingClientRect();
return {
selector, exists: true, tag: element.tagName,
classes: element.className, display: style.display,
float: style.cssFloat, width: style.width,
rectWidth: rect.width, rectHeight: rect.height,
gap: style.gap, marginLeft: style.marginLeft,
background: style.backgroundColor
};
}));
const root = getComputedStyle(document.documentElement);
console.table([
'--base-text', '--editor-bg', '--control-bg',
'--app-text', '--app-border', '--controller-bg',
'--controller-border', '--primaryColor', '--grid-cell-bg'
].map(function (name) {
return { name, value: root.getPropertyValue(name).trim() };
}));
})();項目がない場合は exists: false になります。フォームが display: contents なら、DOMの存在と自身の矩形を分けて読みます。変数の空文字列だけで、子要素やテーマの別スコープにも定義がないと決めず、実際に色が適用される要素のComputedも確認します。
調査コードはDOM検証環境で存在・不在の分岐と出力を確認しています。最終の幅、色、折り返し、Shadow DOM、ライト・ダークの見え方はブラウザで比較してください。
移行時の確認順
- 同じ画面・項目設定を用意し、UIタイプとカラーモードを揃える。
- DOMに要素があるか、直下の親子関係が変わったかを確認する。
- 対象がレイアウトの箱を作るか、Computedのdisplayを確認する。
- CSS変数の名前と定義スコープを確認する。
- 通常・important、レイヤー、詳細度を確認する。
- 再描画後、読取専用、各ビューでも同じ修正が効くか確認する。