HTML / CSSの命名規則に関する実用的な考慮事項（構文）[終了]

質問： 構文classおよびid値の実用的な考慮事項は何ですか？

たとえば、このブログ投稿で説明されているように、セマンティクス、つまり使用されている実際の単語については聞いていないことに注意してください。命名規則のその側にはすでに多くのリソースがあり、実際には、さまざまな構文上のビットに関する実用的な情報の検索をあいまいにしています：大文字小文字の区別、インターパンクションの使用（特にダッシュ）、使用または回避する特定の文字など-

私がこの質問をしている理由を要約すると：

• 命名制限にIDとクラスが自然に任意の規則につながりません
• 命名規則のセマンティック側の豊富なリソースは、構文上の考慮事項の検索をあいまいにします
• これに関する信頼できる情報源が見つかりませんでした
• このトピックについては、SEプログラマーに関する質問はまだありませんでした:)

私が使用を検討した慣例のいくつか：

1. UpperCamelCase、主にサーバー側のコーディングからのクロスオーバーの習慣として
2. lowerCamelCase、JavaScript命名規則との一貫性のため
3. css-style-classes、これはcssプロパティの命名と一致しています（ただし、Ctrl + Shift + ArrowKeyでテキストを選択すると迷惑になる場合があります）
4. with_under_scores、私は個人的にあまり使用されていません
5. alllowercase、覚えやすいが、長い名前では読みにくい
6. UPPERCASEFTW、仲間のプログラマを困らせる素晴らしい方法として（おそらく読みやすさのためにオプション4と組み合わせる）

そしておそらく、私はいくつかの重要なオプションや組み合わせも省略しました。命名規則にはどのような考慮事項があり、どの規則につながるのでしょうか？

報奨金の有無にかかわらず、ある程度選択は常に「好みの問題」になります。結局のところ、W3Cがあなたが正しいと感じなかった特定の慣習を推奨（または課す）した場合、どう感じますか？

とはいえ、私は個人的にlowerCamelCaseコンベンションを好むので、私が決めた理由と実際の考慮事項を説明します-あなたの質問からの番号付けを使用して、排除のプロセスによってそうします：

（5.）単語の開始位置と終了位置がわからないため、簡単に読み取り可能です。

（6.）ASABOVEPLUSITSANNOYINGLIKESOMEONESHOUTING。

（4.）history_incompatibility_plus_see：Mozilla Dev Documentation。

（3.）a-bit-trickier-to-explain ...おっしゃるように、テキストエディターでの選択可能性は1つの問題です（エディターによってはアンダースコアの場合と同様）が、私にとっては、それが私に思い出させるという事実でもあります構文はベンダー固有のキーワード用に予約されています。たとえそれらがハイフンで始まり、単語で区切られていてもです。

これにより、それぞれ（1.）および（2。）、UpperCamelCaseおよびlowerCamelCaseが残ります。Java クラスへの精神的なリンク（より明確に定義された規則により、UpperCamelCase）にもかかわらず、CSSクラス名は小文字から始めるほうが良いように思えます。おそらくそれはXHTMLの要素名と属性名によるものですが、CSSクラスにUpperCamelCaseを使用させると、それらを区別するのに役立つと主張することもできると思います。別の理由が必要な場合、lowerCamelCaseは、W3Cが適切なクラス名の例で使用するものです（ただし、URL自体は迷惑なことに、私には同意しません）。

上記の理由により、（4。）、（5。）、および（6.）に反対するアドバイスをしますが、他の3つのいずれかについて議論ができると仮定します。

ただし、あなた（またはそのことについて他の誰か）がこの問題について私に同意するかどうかはあなた次第です。信頼できる情報源を引用する明確な答えを今のところ得ていないという事実は、この問題に関する明確な標準というものがないというヒントとしてとらえることができます（そうでなければ私たちは皆それを使用するでしょう）。それが必ずしも悪いことだとは思いません。

CSSクラス名の単語はダッシュ（class-name）で区切る必要があります。CSSプロパティと擬似クラスの単語はどのように区切られ、その構文はCSS仕様で定義されているからです。

ID名の単語もダッシュで区切る必要があります。クラス名の構文スタイルと一致するためです。ID名はURLでよく使用され、ダッシュはURLで最も一般的な元の単語区切り文字です。

それは主に好みの問題です。この問題に関しては、信頼できる情報源はもちろんのこと、確立された標準はありません。最も快適に感じるものなら何でも使用してください。ただ一貫してください。

個人的に、私はを使用していますがcss-style-with-dashes、複数語のクラス名を避け、可能な限り複数のクラスを使用しようとしています（そうbutton important defaultではなくbutton-important-default）。私の経験から、これは高品質のWebサイトとフレームワークの中で最も人気のある選択肢のようです。

またnowordseparatorswhatsoever、少なくともUSキーボードでは、Shiftキーを使用する必要がないため、ダッシュ付きの小文字は他のオプション（読みにくい規則を除く）より簡単に入力できます。

idについては、JavaScriptでIDによって要素を直接参照する場合（例document.forms[0].btn_ok：）、ダッシュはそれほどうまく機能しないという実用的な追加の考慮事項があります-しかし、jQueryを使用している場合は、$()とにかくそれらを使用するので、あなたはちょうど持っていることができます$('#btn-ok')。

記録のために、私は定期的に遭遇し、別の規則は、特にフォームコントロールのために、要素の型を示すために、IDの中にハンガリーのイボを使用しています-あなたが持っていると思いますので#lblUsername、#tbUsername、#valUsernameユーザ名のラベル、入力、およびバリデータのため。

最も重要なのは一貫性だと強く信じています。

これを見るには2つの方法があります。

1. 良い議論は、彼らが入るコードと最も一貫性があるため、alllowercaseまたはcss-style-clauses（おそらくより良い選択）にすることができます。 。

2. 読みやすくするためにIDとクラスを区別する場合は、HTMLタグ名やCSS句とは異なるスタイルに対しても同様に適切な引数を作成できます。たとえば、UpperCamelCaseIDとクラスに使用し、それを他の構成または目的に使用しなかった場合、その形式のトークンを見るたびにヒットしたことがわかります。これが課す可能性のある制限の1つは、すべての IDまたはクラスが2つ以上の単語名である場合に最も効果的であるということですが、多くの場合、これは妥当です。

この回答を書き出す中で、私は2番目の選択にずっと傾いていることがわかりましたが、両方のケースにメリットがあると思うので、両方を残すことにします。

それはすべて好みの問題、または怠inessの問題です。CamelCasingは入力しやすいですが、CamelCaseよりも読みやすく、デバッグが個人的に簡単だと思うので、アンダースコア表記を使用することを好みます。従うべきコーディング規約はありません。以前と同じコーディングガイドラインを持つ場所で働いたことはありません。

ほとんどの企業には、誰もが作業しやすいようにコードをクリーンで簡単に保つために、一般的に何らかの方法で従わなければならないガイドラインがあります。あなたがフリーランサーなら、あなたがコードに取り組んでいる唯一の人であるので、あなたは全力を尽くすことができます。私が従うべきコーディング規約は、キャメルケース表記またはアンダースコア表記の2つだけです。私のアドバイスは、1つを選んでそれを使い続けることです。

1つの簡単な事実に気付かないようです：ほとんどのCSSはプログラマーによって行われません。

グラフィックデザイナーによって行われます。

彼らは私たちの編集戦争を気にせず、シフトキーで何をするかについてあまり気にしませんでした。
彼らはおそらくその派手な_キーがどこにあるかさえ知らないでしょう。（またはその名前は何ですか）

彼らはコードの美学を気にしないで、美的美学を気にします。

（そして、彼らはそこにポイントを持っているかもしれません）

彼らは仕様書を読まず、チュートリアルを入手します。
そして、w3schoolsの参照を再確認してください。

それらのいくつかはおそらく、理由のために大文字のクラス名を使用できないと信じています。
彼らは奇妙で、ほとんど無関係な誤解に満ちています。