[転送] DIV+CSSウォーターフォールフローの簡単な分析layout_html/css_WEB-ITnose

はじめに

よくインターネットをサーフィンする人は、この不均一な複数列のレイアウトに見覚えがあるでしょうか?

同様のレイアウトは、Pinterest (このレイアウトを使用した最初の Web サイトのようです)、Mark、Mogujie、Diandian、そして Taobao の最新のローンチなど、国内外の大小の Web サイトに一夜にして表示されるようです。とても人気があります〜近々タオバオで発売される多くの商品の中にもこの形がたくさん見られます。

このレイアウトは、小さなデータ ブロックに適しています。各データ ブロックの内容は類似しており、焦点はありません。通常、このレイアウトではデータのチャンクもロードされ、ページ スクロール バーが下にスクロールするときにそれらのデータが現在の末尾に追加されます。そこで、このレイアウトにウォーターフォールフローレイアウトという鮮やかな名前を付けました。

いくつかの実装方法

このレイアウトを使用するデザイナーが増えているため、フロントエンドとして、ビジュアル/インタラクション デザイナーのニーズを満たすために最善を尽くす必要があります。したがって、このレイアウトの実装方法をいくつか整理しました。次の 3 つがあります:

1) 従来の複数列フローティング。つまり、以下の図に示すように、Mogujie と Wow が採用した方法です。

各列は固定幅で左に移動します
列内のデータ ブロックはグループであり、各データ ブロックは列は順番に配置できます ;
より多くのデータをロードする場合は、別の列に挿入する必要があります;
オンラインの例。

利点:

レイアウトはシンプルで、特別な困難はないと言えます。
データ ブロック内に画像がある場合、データ ブロックの高さを明示的に知る必要はありません。画像の高さを指定する必要があります。

短所:

列の数が固定されており、拡張するのが簡単ではありません。 ブラウザのウィンドウサイズが変更された場合、x 列しか固定できません。列を追加したい場合、配置を調整するのが困難です。データブロックの数;
さらにデータをロードするためにスクロールするとき、どの列に挿入するかを指定するのは依然として不便です。

2) CSS3 定義。 W3C の複数列レイアウトに関するドキュメントがあります:

は、chrome/ff ブラウザーによって直接レンダリングされます。 列数、列間隔、列中央の境界線、および列幅を指定できます。 ;

    #container {          -webkit-column-count: 5；          /*-webkit-column-gap: 10px；          -webkit-column-rule: 5px solid #333；          -webkit-column-width: 210px；*/            -moz-column-count: 5；          /*-moz-column-gap: 20px；          -moz-column-rule: 5px solid #333；          -moz-column-width: 210px；*/            column-count: 5；          /*column-gap: 10px；          column-rule: 5px solid #333；          column-width: 210px；*/      }

column-count は列の数、column-rule は各列の幅です。列; 列幅のみが設定されている場合、ブラウザ ウィンドウは 1 列よりも小さくなります。 幅が設定されている場合、列数のみが設定されている場合は、各列の幅が平均して計算されます。 、幅を超える場合、列のコンテンツは非表示になります。column-count と column-width の両方が設定されている場合、ブラウザーは count Compare に基づいて幅と幅を計算し、それぞれの大きい値を幅として採用します。列を拡大し、ウィンドウを縮小すると、幅の値は各列の最小幅になります。これは実際には非常に簡単です。詳細については、https://developer.mozilla.org/en/CSS3_Columns の手順を参照してください。
オンラインの例。

利点:

CSS の直接定義が最も便利です。
拡張が簡単で、コンテンツをコンテナに直接追加するだけです。

欠点:

高度なブラウザでのみ使用できます。
データ ブロックは上から下に一定の高さまで配置され、残りの要素が順番に次の列に追加されます。これは本質的に異なります。
これら 2 つの主な欠点を考慮すると、この方法はハイエンドのブラウザーに限定されることになり、複数列でのテキストの配置により適しています。

3) 絶対的な位置決め。つまり、Pinterest、Mark、KISSY が採用した方法:

が最良の解決策であると言えます。これは、データコンテンツの追加、ウィンドウの変更、列/データブロックの数が自動的に調整されるのに便利です;
オンラインの例。

欠点:

画像が含まれている場合、
JS はデータ ブロックの位置を動的に計算する必要があります。頻繁に、パフォーマンスが消費される可能性があります。
KISSY.Waterfall 実装アイデア

KISSY の Waterfall コンポーネントには主に 2 つの部分が含まれています。1 つは既存のデータ ブロックを配置し、それぞれの位置を計算することで、もう 1 つは下にスクロールするときにデータの読み込み操作をトリガーし、データをターゲットに追加することです。コンテナの中。

1) データブロックの配置、アルゴリズムの手順を以下に簡単に説明します。

最初の計算はコンテナ内の既存のデータ ブロック要素に対して実行されます。 a、コンテナ要素? これはコンテナの合計幅を取得するために使用されます。最小列数; 最終的な列数 コンテナ幅/列幅の最大値と最小列数が採用され、ウィンドウが小さい場合でも最小列数のデータが表示されます。列の数を取得した後、各列の現在の高さを保存する必要があります。これにより、各データ ブロックを追加するときに、開始時の高さだけがわかります。
コンテナー内のすべてのデータ ブロックを順番に取得し、最初に見つけます。現在の高さが最も小さい列を選択し、列番号に従ってデータ ブロックの左と上の値を決定します。左は列のシリアル番号に列の幅を乗算し、上は現在の高さです。列の現在の高さにデータ ブロック要素の高さを加えて更新されます。この時点で要素の挿入は終了します。すべての要素が挿入されたら、コンテナーの高さの最大値が更新されます。
パフォーマンス効率に関する注意: a. 調整が現在実行中で、サイズ変更イベントがトリガーされた場合は、最後の調整を一時停止してから、この調整を実行する必要があります (timedChunk 関数を参照)。 ; b、サイズ変更は非常に頻繁にトリガーされます。コールバック関数を一定期間キャッシュしてから実行できます。つまり、この期間中にサイズ変更イベントが複数回トリガーされた場合、コールバック関数は 1 回だけ実行されます。 S.buffer関数を参照)
センス 興味のある方はソースコードを参照してください。

2) データの非同期ロード。先ほど説明したのはコンテナ内の既存の要素を配置する方法ですが、多くの場合、この目的のために、独立したモジュール KISSY.Waterfall.Loader を継続的にロードする必要があります。実際、この関数はさらに単純で、次の 2 つのステップのみです:

スクロール イベントをバインドし、プリロード行の高さの値を決定します。つまり、高さまでスクロールした後、データをロードする必要があります。実際、これは列の最小の高さの値なので、過度の制限を課さないように、現在のスクロール値と最小の高さの値を比較することでデータのロードをトリガーするかどうかを判断できます。データ ソースに関しては、データ ソースをどこから取得するか、およびユーザーが使いやすい形式を決定するのは完全にユーザー次第です。このため、このコンポーネントは、load(success、end)インターフェイスのみを提供し、ロード方法はユーザーによって定義され、success/endはそれぞれ、新しいデータの追加方法(successはaddItemsと同じ)/how toのインターフェイスを提供します。読み込みを停止します。これはとても便利です~~

興味があれば、ソースコードを参照してください。

KISSY.Waterfall の例とドキュメント

これを見たら、本当に試してみたくなりますか~~ さて、ここにいくつかの関連する学習資料と参考用の例があります:

ウォーターフォール API ドキュメント、関連するコンストラクター、構成項目とメソッドすべてここにあります

例には、静的と動的が含まれます。