HTML、CSS、JavaScriptを記述して、バックエンドの開発者の作業を容易にする方法を教えてください。
デザイナーからデザインを入手すると、PSD（Photoshop）ファイルとして入手します。私は常に適切なレイヤー名とフォルダー名、基本的にはクリーンで管理されたPSDを期待しています。この設計から、HTML、CSS、JavaScriptを開発し、バックエンドの開発者に提供します。彼らが理解しやすくするために、私は
- セマンティックコードを書く、
- javaScriptとCSSを外部ファイルに保存し、
- hTML、CSS、JSファイルに役立つコメントを追加します。
- cSSスプライトを使用する（ただし、開発者はそれを好まない）。
- hTML5ボイラープレートを使用し、
- javaScriptにはjQueryを使用し、
- 可能な限り新しいHTML5タグとCSS3を使用してみてください。
- hTML、CSS、JS、画像を含むZipファイルを送信しました。
レイアウトに小さな変更を加える必要がある場合、開発者はそれを処理できると思います。
バックエンドシステムやバックエンドテクノロジー、PHP、.NETとの統合を容易にするために、ファイルの編成やマークアップの観点から、他に何ができるかをバックエンドの開発者や他のCSS忍者から聞きたい、Rubyなど）異なるクライアントは異なるシステムを使用します。
これらの回答の多くは幅広いアイデアを網羅する予定ですが、ここに私の個人的な回答があります。
- エラーメッセージ用にフォームデザインにスペースを残します。
- 入力ボックスにラベルを入れないでください！
- CSSとJavaScriptを別のファイルに入れてください。何をしているのかがわかっていて、適切に気分が悪い場合を除きます。
- ページ間でデザイン要素を同じに保ちます。デザインコンポーネント（「最近表示した」ボックスなど）のマークアップがページごとに異なると、それは腹立たしいことです。
- 簡単なことをするのではなく、正しいことをしてください。
<button>タグは吸う。backround-image本当にあるべきもの<img>タグは吸う。 - ページコンポーネントを作成している場合は、スケーリングできることを確認してください。私は最も優れたフロントエンド開発者がこれを行うことを知っていますが、私は誰かがトップ/ボトムキャップの状況であるはずの状況で単一のイメージを使用した多くの例を経験しました。プログラマーはPhotoshopを開くのが嫌いです。
- テンプレートを校正します。プログラマー（善意のプログラマー）は、献身的で詳細指向の人々です。デザインで問題が発生し始めた場合（フッターナビゲーションにスペルミスや一貫性のないスペルがある可能性があります）、質問を投げかけ、作業を遅くします。
最後に、そしておそらく最も重要なこと：
- バックエンドで開発されている言語の基本的な規則を学びます。 PHPテンプレートを見て、
foreachまたはifステートメントの背後にある基本構文を理解し、echoをフォーマットする方法ステートメントまたは<?php ?>タグを付けると、フロントエンド開発者としての価値が大幅に高まります。フロントエンド開発者が簡単な変更を行う必要があり、それを行うことができるときは大好きですテンプレート内新しいものを渡す代わりにすべてのファイルのZip。 - 補遺として、バージョン管理ソフトウェアの使い方を学びましょう。エキスパートである必要はありませんが、2つのZipファイル間で何が変更されたかを理解する必要がなく、diffを見ることができれば、作業が100倍簡単になります。
それらはほんの数例です-私はもっとたくさんあると確信していますが、これらのすべてを達成すれば、あなたのテンプレートをウェブサイトに変えている人の尊敬と感謝を確実に得るでしょう。
私がバックエンドの男の人生を楽にするだろうと私が考えることができる明白なことは、行動の単純さです。さまざまな動作（ロールオーバー、メニューなど）を持つWebページの要素を設計する場合、開発者が継続的にチャートに戻って自分の機能を判断する必要がないように、この動作はすべて共通の方法で標準化する必要がありますページを動作させるにはを呼び出す必要があります。
グリッドは、データまたは機能のセル操作によるセルを必要としません。ページのブロック要素は、共通の要素として簡単に定義できるため、コードビハインドで簡単にセグメント化できます。これにより、開発者はコードを再利用したり、ページのさまざまなファセット間の通信を容易にしたりできます。
ページの領域は、特定のデザインの境界を越えてはなりません。ある要素のアイテムが別の要素のアイテムに侵入してはなりません。
ただし、開発者がフープを焼き尽くすことを避けられないという点があります。一部のインターフェイス要素は、その性質上、作成するのが難しい場合があります。
場合によっては、バックエンド開発者向けのソリューションを簡単に変更できるようにするか、最適化するかを選択する必要があることに注意してください。
あなたが引用したCSSスプライトは良い例です。スケーラビリティとパフォーマンスが重要で、すべてのページから100個の画像、5個のCSS、15個のJavaScriptファイルへのリンクがある場合に、誰かがどのようにWebサイトを作成できるか理解できません。一方、CSSスプライトは維持が容易ではなく、デザインを少し変更するだけでも多くの作業が必要になる場合があります。
たとえば、3つの状態アイコンが上下にあり、4番目の状態を追加する必要がある場合、4番目のアイコンを他の3つのアイコンとは別に、画像の下部に追加しますか？または、3番目のアイコンの後に追加し、他のすべてを一番下に移動して、そのための空きスペースを確保しますか？
同じことが、CSSファイルとJavaScriptファイルを組み合わせて縮小することでも得られます。あなたはある程度の規模のウェブサイトのためにそれをしなければなりません、しかしそれは追加の努力を必要とするでしょう。
CDNの場合もまったく同じです。大規模なWebサイトではこれを使用する必要がありますが、変更を行うのはより困難です。たとえば、CSSファイルを変更した場合、ファイルのURIをcdn.example.com/g.css?r=2、次にcdn.example.com/g.css?r=3などに変更して、ブラウザに新しいファイルをダウンロードさせる必要があります。
また、"easier"は相対的です。たとえば、CSSコードを作成するためのガイドラインを参照してください。個人的には、空白なしで、1行に1つのスタイルを使用します。
#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}
ほとんどの人はこの構文を嫌い、私が嫌いで読みにくいと思う構文を好みます（いいえ、私は狂っていません）。
#TopMenu a
{
text-decoration: none;
color: #fff;
padding: 5px 10px;
float: left;
}
同様に、jQueryを使用しても、バックエンドの開発者がファイルを簡単に変更できるようになるとは限りません。一部の開発者は、Prototypeまたは他のフレームワークの経験があるためです。
すべての場合において、開発者が読みたい場合は詳細なドキュメントが役立ちます（ほとんどのドキュメントは読みません）。また、フレームワークを構築しながら、特定の開発者にどのように実行するかを正確に尋ね、最初にside by sideを実行することで、開発者の生活をより簡単にすることもできます（たとえば、ファイルを縮小して組み合わせるために使用するワークフローの設計）。
すべての世界で最も優れているのは、デザイナーがZipファイルを壁に投げず、実際に開発者の1人としてプロジェクトで作業しているときです。設定には少し手持ちが必要ですが、設計と開発の間で変換がなく、誰もが同じ反復に参加できる場合は本当に素晴らしいです。摩擦のないアジャイルプロセスを実現できれば、それほど難しくはありません。
ほとんどの場合、バージョン管理された方法で作業し、それを配布メカニズムとして使用するデザイナーのために解決します。小さな変更があるたびに大きなファットZipファイルを処理したくありません。
あなたにとっての柔軟性とは、一般的に彼らにとっての柔軟性です。あなたがフォローしているすべてのベストプラクティスは、アプリの両面での勝利です。
ただし、重要な、見逃されがちな点の1つは、堅牢なUIを作成することです。非常に多くのUIコンポーネントが1つのコンテキストまたは過度に厳密なHTMLのセットに過度に固定されており、CSSが失敗するように設定されています。
たとえば、ドロップダウンがある場合、絶対位置のドロップコンポーネントを相対セット（座標は不要）のクリックされたコンテナー内に固定するJS作業は、JQueryハンマーを引き出して座標を取得するよりもはるかに少ないですエレメントの上に置き、所定の位置に貼り付けます。また、ページが移動したり、いくつかの新しいブラウザー機能によって位置情報がオフになったりした場合でも、壊れる可能性ははるかに低くなります。 JSの作業を回避するためにHTML/CSSスキルに依存するほど、UIは通常より堅牢になります。
一般的なルールとして、UIコンポーネントに必要なのは、適切なIDまたはクラスで動作するHTMLタグのみであることを確認します。 UIを壊さずにそのコンテナで実行できること、またはコンテナのサイズが変化するにつれて拡大/縮小してフィットするようにコンテナが実際に対応できるほど、クライアント側を必要とせずにアプリのどの部分にも簡単に実装できます専門家。彼らがしなければならないすべてはそれにクラスを貼り付けることです。
ボタンのようなエンドポイントノードにリスナーを直接割り当てるよりも、UIコンテナーのイベント委任を優先します。そのUIコンポーネントは静的HTMLで動作する可能性がありますが、誰かがHTMLを取り出してinnerHTMLか何かで書き直したい場合があるかどうかはわかりません。コンテナーがそのままで、すべてのイベントが委任されている場合（jqueryの 'on'メソッドを参照）、そのことを心配する必要はなく、HTMLを置き換えることでリスナーが壊れる難しい方法を学習することはありません。
オプションとして委任を維持するために、stopPropagateをエンドポイントノード以外の場所に使用せず、あちこちにスパムを送るばかフレームワーク開発者にヘイトメールを送信します。
レイアウトに関しては、HTMLを最小限、セマンティックに保ち、divラッパーを避けます。 HTMLが少ないほど、レイアウトの新人が診断しやすいレイアウトの問題が発生します。
ユーティリティCSSには自明のクラス名を使用してください。 「行」クラスは、「clearfix」よりもCSS noobsに対してより明確である可能性があります。
常に一意の断面要素、一意のIDを指定します。これにより、セクション固有のことがどこで発生しているかを簡単に特定でき、オーバーライドが容易になり、JSの読みやすさとパフォーマンスも向上します。
明らかにクラススキームで過剰になるのは悪いニュースですが、バックエンドの開発者が適切なクラスを追加するだけで設定できるほど、既存のページを簡単に変更できるようになります。
そしてもちろん、プロジェクトの最初に、少なくとも次の1つに同意してもらいます。バックエンドとフロントエンドはHTMLとJSONのみを介して接続します。 「JavaScriptを作成する」ものを使用させないでください。それは流血の混乱とメンテナンスの悪夢です。
開発関連のすべてのものと同様に、DRYとミニマリズムを好みます。
それでも私はコメントするだけではありません（とても愚かです）が、個人的なメモとして、私はPHPコーダーを毎日続けて（そして彼の仕事を手伝っています） ）そして私たちが見つけた最も簡単なツールは Komodo のツールボックスを使用し、ツールボックス内の各ビュー/コントローラー/モデルの「転送された」変数を一覧表示することです。これにより、いつでもそのページに送信された一連のデータの周りのページのデザインを見て、ツールボックスを調べて、送信されているデータと送信されている「タイプ」を正確に確認できます。また、その逆も同様です。 。ヒントにすぎません。