web-dev-qa-db-ja.com

HTMLでCSSフックからJSフックを分離する必要があると人々が考え始めたのはなぜですか？

編集：明確化のポイント、IDとクラスを個別のフックとして使用することは、JSで行うようにCSSに同じフックを決して使用しないという問題の適用されたアイデアの1つの形式にすぎません。また、js-combo_boxやcss-combo_boxなどを同じ要素のクラスとして必要とする人もいます。

これは私が近年ますます遭遇し始めたものです。 JSにはIDを使用し、CSSにはクラスを使用したいという人。あるいは、JSがクラスとIDにまったく触れないようにして、HTML5データ属性フックなどに依存することを望まない（これは、現在のブラウザーでさえ、実際に要素を見つける最も遅い方法であり続けるでしょう）。

5年以上の時折のヘビーデューティ/めちゃくちゃな環境のクライアント側のWeb開発では、完全にめちゃくちゃになっていたeコマースの小売業務が1つもあり、HTMLの誰も操作していなかったため、さまざまなレベルのコードの読み書きができない200人のオフショア開発者がいたので変化しました（完全にローエンドで、冗談ではありません）ソース管理なしでバックエンドのコードベースを上下にジャンプすると、HTMLの共有属性をターゲットとするJSとCSSが何らかのメンテナンス性や簡単さを引き起こす問題に遭遇したことがありません私にとって修正の問題。私はこの認識された必要性を何が伝えているのか、そして多くの人に思い浮かぶものを見逃しているのではないかと思いますか？

セレクター経由のHTMLとDOM APIは、事実上すべてを結び付ける抽象化のポイントではありませんか？ JSとCSSが同じ属性を共有することで問題が発生するのはなぜですか？

javascripthtmlcssseparation-of-concerns
6
Erik Reppen

自分で言ったように、経験の浅いプログラマーと一緒に仕事をしなければならないので気づくかもしれません。

実際には、観察する区別は存在しません。ところで、フレームワークはそのような区別を思いとどまらせます。

たとえば、jQueryでは、一般的な方法でセレクターを使用することを推奨しています。つまり、IDを使用して単一の要素をターゲットにし、クラスを使用して複数の要素をターゲットにすることを推奨しています。

同様に、完全に遅延していない開発者は、クラスがページ上の一意の要素の候補として不適切であることをすぐに認識（学習）します。もちろん、すべてのIDをHTMLと対応するCSSの両方のクラスで置き換えることができますが、少し...だれもパフォーマンスを気にしない場合は判読不能としましょう。

経験の浅いプログラマは奇妙なことをする傾向があります。ある同僚に次のことを説明するのに数週間かかりました。

<div id="entry">Some text here</div>
<div id="entry">Some other text</div>

iDは一意であるため、誤りです。 CSSでクラスを使用する方法を説明する記事を読んだばかりの初心者とjQueryでのdata-属性に関する別の記事を読んで、この初心者がCSSとdata-でjQueryのクラスを使用し始める理由を簡単に理解してくださいセレクタ。

7
Arseni Mourzenko

このパターンを採用した人として、私がこれを行った最大の理由の1つは、マークアップがもう少し意味論的になると感じていることです。 .js-クラスが含まれている要素に影響する変更に取り組んでいる場合、この要素をリッスンしているまたは操作しているJSがどこかにあるはずです。 JSがこの要素を使用していることを知っているということは、私がそれをどのように変更するかに細心の注意を払っていることを意味します。

データ属性の使用についても同じことが言えますが、IDやクラスを使用しないことでJSをCSSから分離することで、さらに一歩進んだと主張できます（通常、データ属性をJSセレクターとして使用しませんが、見た）。

2
David Eugene Pratt

JSのクラスを使用することは完全に理にかなっています。

クラスは、名前のようにclassifyDOM要素を示します。

たとえば、アイテムのリストがある場合

<div class='item'>Item1</div>
<div class='item'>Item2</div>
<div class='item'>Item3</div>
<div class='item'>Item4</div>

それぞれにIDを割り当てる代わりに、次のセレクター.itemを使用してそれらを選択することは完全に理にかなっています。

さらに、多くの一般的に使用されているJavaScriptライブラリとコードベースでは、要素の選択にクラスセレクターが使用されます。私はそれを製品コードで何度も使用するのを見てきましたが、それは許容できる慣行のようです。

IDセレクターよりもクラスセレクターの方が優れているのは、IDセレクターが高速（perf here ）であることだけです。ほとんどの場合、それはそれほど重要ではありません。

2
Benjamin Gruenbaum

第一に、分離は絶対的だとは思いません。たとえば、IDはドキュメントに固有であるため、CSSとJSの両方で使用するのが理にかなっています。ただし、クラスの場合、これらが分離していることには十分な理由があります。

基本的な問題は、CSSとJSが、相互の関心事と考えるものを実装していることです。 CSSはレイアウト、表示、タイポグラフィを実装しますが、JSはbehavior。を実装します。または、少なくともこれが最も頻繁に（そして私が思うに）使用される方法です。これらは直交関係または次元と考えることができるため、個々のDOMオブジェクトを、機能の行ではなく、次元が表示および機能である2次元領域に配置する必要がある場合があります。

繰り返しになりますが、単一の要素を検索する場合、CSSとJSはどちらもIDでこれを行いますが、グループを検索する場合は、表示と動作をあまり密接に結び付けたくないでしょう。

これは一般的な問題であり、開発者の経験や使用しているツールには依存しないと思います。懸念事項が異なる限り、複数のタイプの懸念事項に従って要素を分類できるようにしたい場合があります。これは、これが発生する1つの方法です。

0
Chris Travers

2020年には、次のようなことをする傾向があります。

アコーディオンメニューを想像してください。

<nav class="mainMenu">

  <ul class="mainMenuList">

  <li class="mainMenuSection">
    <strong class="mainMenuSectionTitle">Site Section A</strong>
    <ul class="mainMenuPageList">
    <li class="mainMenuPage">Page A1</li>
    <li class="mainMenuPage">Page A2</li>
    </ul>
  </li>

  <li class="mainMenuSection open" data-main-menu-section-state="open">
    <strong class="mainMenuSectionTitle">Site Section B</strong>
    <ul class="mainMenuPageList">
    <li class="mainMenuPage">Page B1</li>
    <li class="mainMenuPage">Page B2</li>
    <li class="mainMenuPage">Page B3</li>
    <li class="mainMenuPage">Page B4</li>
    </ul>
  </li>

  <li class="mainMenuSection">
    <strong class="mainMenuSectionTitle">Site Section C</strong>
    <ul class="mainMenuPageList">
    <li class="mainMenuPage">Page C1</li>
    <li class="mainMenuPage">Page C2</li>
    <li class="mainMenuPage">Page C3</li>
    </ul>
  </li>

  </ul>

</nav>

（明確にするために、data-main-menu-section-state="open"はアコーディオンの開いたセクションであり、訪問者が開いたときに、ページB1からページB4へのすべてのリンクが完全に明らかになるまで、下に向かって広がります。）

これに対する議論は、両方であるため、

  • .open
  • data-main-menu-section-state="open"

開いているアコーディオンセクションを示します。最初のセクションのみが必要です。

しかし、この種の設定では、

  • classesはCSSフックを表します。そして
  • HTML5 Custom data-* attributesはJSフックを表します

ドキュメントのリファクタリング時に特定のクラスの名前を削除または変更できることを確信できることを意味します（特に、私が最後に数か月前に取り組んだプロジェクトに戻っている場合は特に）。 Presentationであり、同じ要素に現在適用されているJSBehaviourが無効になることはありません。

さらに、総称クラス.openをドキュメントの別の場所にデプロイすると、次のように、スタイルシートに2つの類似しているが同一ではないスタイルブロックが表示されます。

  • .mainMenuSection.open
  • .headerMenuSection.open

クラス.openを追加した新しい要素は、必要のない、または必要としないJavaScriptの動作をすぐに採用しないことを確信しています。

まとめ：

CSSをリファクタリングしているとき、これが望ましくないJavaScriptの副作用を引き起こすかどうかについて常に考えている必要はありません。

そして、JSをリファクタリングしているとき、これが望ましくないCSS副作用をもたらすかどうかについて常に考えている必要はありません。

以下も参照してください：アンクルボブマーティンの 単一の責任の原則

0
Rounin