はじめに
コーディング依頼時のレギューレーション備忘録。
実際に依頼する際は、各項目を該当Webサイトにあったものに書き換える想定。
不要な箇所はトルツメして依頼用のレギュレーションを作成する。
下記はそのサンプルプロットです。
あくまでサンプルなので、都度加筆修正予定です。
コーディングレギューレーション
【動作担保】
※動作担保が必要な条件は、事前にリストアップして共有する方が良い。
●対象OS
Windows 10,11
Mac OS
iPad OS
iOS
Android
各 対象OS最新版
※Linux系（Ubuntu 等）は対象外とする
※実機確認必須機種：Xperia ●●、iPhone ●●、iPad mini(第●世代以降) ***などなど
→実機でしか生じない症状も多々あるので、実機確認必須の機種があれば、事前に指定しておく。
●対象ブラウザ
PC：Edge（Chromium）、Chrome、Firefox、Safari 最新版
Tablet：Edge、Chrome、Safari(iPadOS) 最新版
SmartPhone：Edge、Chrome、Safari(iOS) 最新版
●利用可否、標準仕様の確認
対象OSおよび対象ブラウザでの
利用可否確認を必ず行ってください。
《利用可否の確認》
-
Can I use
動作担保が必要な環境での利用可否については、
「Can I use」で必ずご確認をお願いします。
https://caniuse.com/ -
MDN Web Docs
基本的な仕様の確認は、「MDN Web Docs」をご参照ください。
https://developer.mozilla.org/ja/
《最新の標準仕様の確認》
-
WHATWG（ブラウザでの表示に関する標準仕様）
ブラウザAPIについては、Living Standardとして策定された仕様をご参照ください。
https://spec.whatwg.org/
HTMLの標準仕様は、「WHATWG」にてご確認をお願いします。
https://html.spec.whatwg.org/ -
W3C（CSSの現段階での標準仕様）
CSSの標準仕様は、W3Cにて公開されている最新のSnapShotをご参照ください。
https://www.w3.org/Style/CSS/specs.en.html
https://www.w3.org/Style/CSS/current-work -
TC39（JavaScript（ECMAScript）の現時点での標準仕様）
ECMAScript: https://tc39.es/ecma262/
Intl API: https://tc39.es/ecma402/
https://github.com/tc39/proposals
ブラウザごとの Hack（ハック）や Polyfill (ポリフィル)は極力利用をお控えください。
※どうしても実現出来ない内容があった時のみ利用可。
●確認環境
案件によって、恐ろしいほどに条件が異なるので、
あくまでも参考までに。。。
※下記の項目内の内容は案件にあったものに都度変更する想定※
-
環境
ローカル環境での構築を想定。
dockerfileを提供予定。
（PHP ●.●.●、MySQL ●.●.● *** 、利用想定） -
テストサーバー
弊社側で立てる予定。
SFTP（秘密キー利用）でのアクセス想定。
→もしくはGit経由で受領したデータを弊社側でテストサーバーにアップ予定。 などなど。
※VPN、ユーザID、パスワード、秘密キー等、接続に必要な情報は追って提供予定
●その他注意点
ウェブページUXの重要指標「core web vitals（コアウェブバイタル）」にご注意ください。
※特に、LCP（Largest Contentful Paint（最大コンテンツの描画））
CLS（Cumulative Layout Shift（累積レイアウト変更））の値が著しく低下する実装はお控えください。
※参考：「【重要】コアウェブバイタルとは? LCP/FID/CLSをわかりやすく解説【SEO情報まとめ】」
https://webtan.impress.co.jp/e/2020/06/05/36210
【設計】
事前確認することで、その後の工程での工数削減に繋がることも多々あるので、
事前に決めれそうならば、可能な限り記載したうえで共有する。
●コーディング 共通ルール（希望）
※下記の項目内の内容は案件にあったものに都度変更する想定※
-
モバイルファースト
コーディングは、なるべくモバイルファーストでお願いします。
モバイルフレンドリーテストでエラーが出ないように実装してください。
モバイルフレンドリーテスト
https://search.google.com/test/mobile-friendly -
改行コード
圧縮などをしないでそのまま納品するファイルについては、CR + LFを用いてください。 -
インデント
圧縮などをしないでそのまま納品するファイルについては、インデントはスペース4つを必ず使用してください。
Tabは使用しないでください。 -
HTMLの要素名と属性名の文字
HTMLの要素名と属性名は、すべて小文字で記述してください。
先頭文字は基本的にアルファベットを利用して下さい。（数字での開始は不可） -
連番の振り方
連番の数字が入る想定の箇所は、2桁～4桁での記載をする。
0を含めて記載し、桁数を統一させる（01、0001 等）
→ Emmetでの連番表記（「$」）利用可能想定
※補足：案件によっては連番で0抜き指定が入るケースがある。連番時の仕様は事前にエンジニアに確認する。 -
行末の余分な空白を無くす
行末に余白（スペース）が残らないようにしてください。 -
コメント
* 複数行の場合
関数の前には、その関数の役割と、パラメータ/戻り値の説明を加えてください。
* 1行コメントの場合
tabを使わず、2スペースでフォーマットしてください。
* 長いコードの場合
1行が長いコードの場合は、右にコメントをつけず、コードの上にコメントを付与してください。 -
カラーコード
alphaの指定が必要な場合を除き、カラーの指定は原則Hexカラーを用いてください。
Hexカラーは大文字ではなく小文字で指定してください。
●命名規則（希望）
※下記の項目内の内容は案件にあったものに都度変更する想定※
-
基本ルール
* 半角英数字のみを使用してください。
* 記号は「-」（ハイフン）、「」（アンダースコア）のみ使用してください。
** 「-」は意味のまとまりのある一つの単語に対して使用する、半角スペース、&の代わりになるものです。
Ex) banana-juice
** 「」は意味的に分離された単語に対して使用する、 /（スラッシュ）などの代わりになるものです。
Ex) banana-juice_omotesando
* 全角スペース、半角スペースは使用しないでください。
* 機種依存文字は使用しないでください。
* 数字から開始せず、必ずアルファベットから開始してください。
* 連番数字はアンダースコアで接続してください。 Ex) sidebar_002
* 英単語は慣例的に使われている名前にしてください。
* ファイル名から何のコンテンツか推測出来るようにしてください。
* ディレクトリの場合は内包するコンテンツのカテゴリ名にしてください。 -
画像ファイル名命名規則
画像ファイル名は、以下のように名前を付けます。
「部位 _ 種類 _ 詳細 _ 連番 _ 状態 . 拡張子」
* 部位（ページ内のどの部位か）
* 種類（UIの大分類）
* 詳細（どのような場面で使うか）
* 連番
* 状態（ユーザの操作やページ状態で切り替える場合）
* 拡張子（.jpg 等）
※必要ない項目は省略可
●HTML
※下記の項目内の内容は案件にあったものに都度変更する想定※
-
HTML Living Standard 準拠（旧：HTML5）
https://whatwg.org/
https://html.spec.whatwg.org/
※WHATWG側の内容に準拠想定
※コードについては、Validatorでチェックまでお願いできると助かります。 -
レスポンシブ対応
可能な限り、PCとSPは共通のソースコードを利用してください。
共通利用が厳しい場合に限り、PCとSPは異なるコードを利用する方針でお願いします。
※pag等のコンパイルで作成する想定 かつ コンパイル前のデータを納品してもらう想定の場合は
ディレクトリ設計等のリクエストも追記する想定。
●CSS（SCSS）
※下記の項目内の内容は案件にあったものに都度変更する想定※
-
リセットCSS
「A Modern CSS Reset」 利用想定
https://github.com/hankchizljaw/modern-css-reset/blob/master/dist/reset.css -
CSS（SCSS）設計：「FLOCSS」ベースでの設計希望
原則は「FLOCSS」のルールに則り、「MindBEMding」をベースとした命名を行います。
MindBEMding：
https://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
《参考URL》
https://github.com/hiloki/flocss -
プレフィックスは下記参照
* “.l-” Layoutレイヤー
* “.c-” Componentレイヤー
* “.p-” Projectレイヤー
* “.u-” Utilityレイヤー
* “.js-” Javascriptで操作する要素
* “.is-” JavaScriptで操作された要素
* “.gtm” GTM、計測周りで利用想定のプレフィックス。計測以外での利用は禁止。（動作やスタイルをもたせない） -
その他注意点
* リセットCSSを除き、要素（タグ）に直接スタイルを当てるのは控えてください。
* IDにスタイルを当てるのは控えてください。
* classに要素名をつけるのは控えてください。（.u-h3 等、要素名を含めた命名は禁止）
* 略語の利用は極力控えてください。
* ブラウザごとの Hack（ハック）の利用は極力控えてください。
* 新しいプロパティをご利用になる際は、「Can I use」で必ず利用可否のご確認をお願いします。
https://caniuse.com/
●JavaScript
※下記の項目内の内容は案件にあったものに都度変更する想定※
-
ES2015(ES6) 利用可
※IEでの動作担保不要なので、ES6でOK -
ライブラリ/フレームワーク
弊社側からの指定は特に無し
※「jQuery」「React」「Vue.js」「Angular」等、
利用想定のものがあれば、事前にご連絡いただけると幸いです。 -
JSで操作する要素へのプレフィックスを付与ルール
* “.js-” Javascriptで操作する要素
Javascriptによって操作を行う要素には、”.js-“プレフィックスから開始されるクラスを付与してください。
また、この要素へのCSSによるスタイルの追加はしないでください。
これにより、 jsのDOM操作の対象となっている要素かどうかを分かりやすくすると同時に、
JSとCSSを明確に分離することが可能になります。
* “.is-” JavaScriptで操作された要素
Javascriptによって操作を行った要素には、”.is-“プレフィックスから開始されるクラスを付与してください。
これにより、jsで操作されている要素かどうか分かりやすくすると同時に、
jsによるスタイルの変更の影響範囲を”.is-“プレフィックスがついた箇所に限定でき、
スタイル全体の見通しがよくなります。
※FLOCSSでは”.is-“クラスにスタイルを持たせるのを禁止していますが、当プロジェクトではこれを許可します。
”.js-“クラスには、スタイルを持たせることを禁止します。
- その他注意点
* 現時点でPolyfill (ポリフィル)は利用しない想定ですが、
対象端末での表示担保ができない場合は利用してください。
【納品物】
案件ごとに条件が異なるので、
必要なファイルの指定と納品方法は必ず指定する。
※下記の項目内の内容は案件にあったものに都度変更する想定※
●納品物
表示に必要なファイル一式
HTML、CSS、JS、画像・動画データ 等
※指定する
コンパイル前のデータ一式
SCSS 等
※必要な場合は指定する
●納品形式
Zip等での圧縮ファイルで、上記の納品物を受領想定。
（Gitを建てる場合は、プルリクしてもらったデータがマージされた段階で納品完了とする）
以上
おわりに
上記はあくまで参考プロットです。
OS、ブラウザ、各種仕様の最新情報はどんどん変わるので、都度加筆修正予定で
他にも書いたほうがよかったり、変更した方が良いものがあれば直して行きたいな・・・と、思います。。。