一般的な5つの応答型設計トラップとソリューション

0.目次

ディレクトリ

引用

本文

1は

を導入する.

1意外な文字変更

2望ましくないフォームスタイル

3誤導エミュレータエラーmulator Errors

4デスクトップが良好なアニメーションを表現する移動端に問題が現れる

5タッチイベントTouch Eventの座標登録問題

6まとめ

声明

1.引用
译文:Sitepointの5 Responsive Design Pitfalls and How to Avoid Them訳者:フロントエンドはwhqetを開発して、意訳は主として不当なところで、指摘を歓迎します!皆さんのすべての助けになることを願っています.
2.本文
2.1導入
優れた応答設計を作成したばかりで、モバイルデバイスでテストする準備ができているシーンを想像してください.予期せぬ点でいくつかの問題が発生し、文字が乱れ、アニメーションが荒れ、フォームにデザインされたスタイルが表示されませんでした.その後、これらの問題を修復するのにN時間以上かかり、窓の外にパソコンを投げ出して隣の家の猫に当たった可能性があります.
良いニュースは、この文章であなたを狂わせる可能性のある問題を紹介し、対応する解決策を説明するつもりです.主に以下の5つの問題が含まれています.

意外な文字変更

望ましくないフォームスタイル

誤導エミュレータエラー

デスクトップが良好なアニメーションを表現する移動端に問題が現れる

タッチイベントの座標登録問題

はい、本題に戻ります.
この文書では、応答型Webページ開発の基礎知識を理解していると仮定します.そうしないと、アップグレード(簡明なチュートリアル)が必要になる場合があります.
2.1意外な文字変更
iosデバイスの回転はレイアウトを破壊し、ページ内の文字サイズを変更します.要素(ナビゲーションバー、メニューなど)が固定位置に設定されている場合、ページをリフレッシュしてこそ問題を解決することができます.幸いなことに、未然に防ぐ方法がある.
cssに次のコードを追加します.

html { /*            */ -webkit-text-size-adjust: 100%; }

このコードは、横画面を設定するときの文字のスケールを100%に設定し、予期せぬ文字の変更を防止します.
2.2望ましくないフォームスタイル
タブレットまたはモバイルデバイスは、デフォルトのスタイルを呼び出してフォームのスタイルを台無しにすることがよくあります.次のcssコードを使用して、フォームのデフォルトのスタイルをブロックすることができます.

input[type=text], button, select, textarea{ -webkit-appearance: none; -moz-appearance: none; border-radius: 0px; }

必要に応じてリセットされたフォームを選択できます.たとえば、input[type=text]をinputに変更すると、すべてのタイプのinputが選択されます.
2.3誤導エミュレータエラー(mulator Errors)
ブラウザベースのモバイルシミュレータを使用してテストすると、煩わしい問題が発生することがあります.コードに問題がない場合に問題を投げ出すのは、悩ましいです.
たとえば、開発中のページの下部にあるナビゲーションバーが不思議に消えてしまい、問題の原因を探す準備をしていたところ、Chromeシミュレータのウィンドウの下部が一部切り取られていることに気づき、新しいtabでページを開き、モバイルビューのリフレッシュを切り替えて問題を解決しました.
同様の問題が発生した場合、最も重要なのは、コードに問題がないことを保証するには、シミュレータの問題だけです.問題領域を分離して、コードが正常に動作しているかどうかを確認し、実際のモバイルデバイスでテストしてみてください.
2.4デスクトップ側で良好なアニメーションを表現するモバイル側で問題が発生
モバイルデバイスでアニメーションを使用する場合は、アニメーションのパフォーマンスに特に注意してください.一般に、ブラウザは、以下のような属性translate、scale、rotate opacityなどを効果的にアニメートすることができる.

transform: translate(15px, 40px); /* shift left 15px and down 40px */
transform: scale(2); /* scale to 2 times original size */
transform: rotate(30deg); /* rotate 30 degrees */
opacity: 0.5; /* set opacity at 0.5 */

これらのアトリビュートがアニメーション化されるのは、ブラウザレンダラーの最上位レベルにあるためです.1つのページを1つのテーブルと見なすことができます.アニメーションのこれらのプロパティはスープを移動するのと似ています.アニメーションの下部のプロパティはテーブルクロス全体を移動するのと似ています.上のすべてのカバーを同時に移動する必要があるので、もっと苦労します(パフォーマンスが悪くなります).
この記事を読むことで、アニメーションのパフォーマンスの詳細を知ることができます.
アニメーションを最大化するには、ブラウザプレフィックス(verdor prefix)を追加する必要がある場合があります.Caniuseで互換性を知ることもできます.
また、ボックスシャドウ(box-shadow)はアニメーションのパフォーマンスに影響を与える場合があるので、ボックスシャドウを使用する場合はモバイルデバイスのテストに注意することを強くお勧めします.
2.5タッチイベントの座標登録の問題
タッチイベントの座標登録の問題も微妙で、座標は異なるデバイスで記憶領域が異なるためです.一部のデバイス(iosなど)のタッチ座標はクリック座標と同じであり、他のデバイス(androidなど)は異なる.良いニュースは、任意のモバイルデバイスにおいて、特定のタッチイベントデータ(touch event data)によって座標を取得することができることである.
タッチイベントの場合、e.touches[0].pageXではなくe.pageXを用いてタッチポイントのx座標を取得し、y座標を取得することも同様である.次に、実際に適用される可能性のあるコードを示します.

/* event */
document.onclick = function(e){
    var x = e.pageX; // get x coordinate of click
    var y = e.pageY; // get y coordinate of click
    console.log('x = ' + x + ', y = ' + y); // show coordinates in console
}
/* for touch event */
document.ontouchstart = function(e){
    var x = e.touches[0].pageX; // get x coordinate of touch
    var y = e.touches[0].pageY; // get y coordinate of touch
    console.log('x = ' + x + ', y = ' + y); // show coordinates in console
}

シミュレータで上記のコードをテストしてみてください.
2.6まとめ
本稿では、応答型Web開発における一般的な落とし穴をいくつか羅列し、対応するソリューションを指定し、時間を節約し、面倒を少なくしたいと考えています.
コメントを通じて討論、指導を歓迎します.
3.宣言
フロントエンドはwhqetを開発し、フロントエンドの開発に注目し、関連資源を共有する.csdn専門家のブログ、王海慶はあなたに役に立つことを望んで、作者のレベルに限られて、間違いは避けられなくて、レンガを撮ることを歓迎します!いかなる形式の転載を歓迎して、ロードを明記して、この段落の文字を保留してください.本文のテキストリンクhttp://blog.csdn.net/whqet/article/details/48392167独立ブログへようこそhttp://whqet.github.io