プロジェクトで学んだブラウザ間の違い

主要ブラウザの違い主要ブラウザの違い

http://www.cnblogs.com/lhb25/archive/2013/06/05/html5-and-css3-2013.html 

• 1. Trident カーネルの代表的な製品は、IE カーネルとも呼ばれる Internet Explorer です。Trident (MSHTML とも呼ばれる) は、Microsoft によって開発された植字エンジンです。Trident レンダリング エンジンを使用するブラウザには、IE、Maxthon、World Window Browser、Avant、Tencent TT、Netscape 8、NetCaptor、Sleipnir、GOSURF、GreenBrowser、KKman などがあります。

• 2

  2. Gecko カーネルの代表的な作品である Mozilla Firefox Gecko は、C++ で書かれたオープンソースの Web ページ レイアウト エンジンです。Gecko は、Trident に次いで 2 番目に人気のある植字エンジンの 1 つです。これを使用する最も有名なブラウザは、Firefox と Netscape 6 ～ 9 です。

• 3

  3. WebKit コアの代表作品 Safari と Chromewebkit は、KDE ​​プロジェクトと Apple のコンポーネントを含むオープンソース プロジェクトで、主に Mac OS システムで使用されており、明確なソース コード構造と非常に速いレンダリング速度が特徴です。欠点は、Web ページのコードとの互換性が高くないため、標準外の Web ページの一部が正しく表示されないことです。主な代表作としてはSafariやGoogleのブラウザChromeなどが挙げられます。

• 4

  4. Presto カーネルの代表的な作品である Opera Presto は、Opera 7.0 以降で使用するために Opera Software によって開発されたブラウザ レイアウト エンジンです。これは、Opera 4 ～ 6 の古いバージョンで使用されていた Elektra レイアウト エンジンを置き換えるもので、DOM およびスクリプト構文イベントに従って Web ページまたはその一部を再配置できる動的機能の追加が含まれます。

• 元のリンク: https://www.cnblogs.com/lsc-boke/p/5525859.html

5つの主要ブラウザの違い

インターネットをサーフィンしたことのある人なら誰でも、ブラウザについてよく知っています。ユーザーはブラウザ自体を見るだけで、ブラウザの中核部分、つまりブラウザコアを見ることはほとんどありません。最初の libwww (Library WorldwideWeb) ブラウザが開発されて以来、数え切れないほどの競争と敗退を経験してきました。現在、中国で一般的なブラウザには、IE、Firefox、QQ ブラウザ、Safari、Opera、Google Chrome、Baidu ブラウザ、Sogou ブラウザ、Cheetah ブラウザ、360 ブラウザ、UC ブラウザ、Aoyou ブラウザ、Window of the World ブラウザなどが含まれます。しかし、現在、主要な主流ブラウザは、IE、Firefox、Google Chrome、Safari、Opera の 5 つです。
ブラウザの最も重要な部分はブラウザのカーネルです。ブラウザ カーネルはブラウザの中核であり、「レンダリング エンジン」としても知られ、Web ページの構文を解釈して Web ページ上にレンダリングするために使用されます。ブラウザ カーネルは、ブラウザが Web ページのコンテンツとページの形式情報を表示する方法を決定します。ブラウザ カーネルが異なれば、Web ページの構文の解釈も異なるため、Web 開発者は、異なるカーネルを備えたブラウザで Web ページのレンダリング効果をテストする必要があります。

• Web ページのさまざまな文法解釈
• レンダリング効果が異なります
• パフォーマンスが異なり、サポートされるスクリプトの実行速度も異なります。また、部分的な (隠し要素など) 再描画とリフローをサポートする状況はより複雑で異なります。

主要な5つのブラウザを簡単に紹介します。(時系列順)
1. IE ブラウザ:
IE は Microsoft Corporation が所有するブラウザであり、中国で最も多くのユーザーを抱えるブラウザです。IE が誕生したのは 1994 年ですが、当時、90% 近くのシェアを持っていた Netscape Navigator に対抗するために、Microsoft は Windows 上で独自のブラウザ Internet Explorer を開発し、これが第一次ブラウザ戦争の引き金となりました。ご想像のとおり、Microsoft は大勝利を収め、Netscape は AOL に身売りする必要がありました。しかし実際には、問題は終わったわけではなく、後に Netscape が人気の Firefox を開発し、Firefox は世界でトップ 5 ブラウザの 1 つになりました。
1996 年、Microsoft は Spyglass から Spyglass Mosaic のソース コードと認可を取得し、独自のブラウザ IE の開発を開始しました。その後、Microsoft は IE と Windows をバンドルすることで市場シェアを拡大​​し続け、IE が市場の絶対的な主流になりました。現在、Windows システムがインストールされているコンピュータから IE をアンインストールすることは基本的に不可能です。
2. Opera ブラウザ:
Opera は、ノルウェーの Opera Software ASA 社が所有するブラウザです。1995 年、Opera company は、独自に開発した Presto カーネルを使用して Opera ブラウザの最初のバージョンをリリースしました。当時、Opera 社の開発チームは Presto コアの改良を続け、Opera ブラウザを一時はトップブラウザにしました。2016 年まで Qihoo 360 と Kunlun Worldwide は Oprea ブラウザを買収し、それ以降は強力な Presto カーネルも放棄し、当時 Google のオープンソース Webkit カーネルに切り替えました。その後、Opera ブラウザも Google に追随し、ブラウザ コアを Blink コアに変更しました。それ以来、Presto カーネルもインターネット市場から姿を消しました。
3. Safari ブラウザ:
第二次ブラウザ戦争は、Apple が Safari ブラウザをリリースしたときに始まりました。2003 年、Apple は iPhone 上で Safari ブラウザを開発し、その独自の携帯電話市場シェアを利用して、すぐに世界の主流ブラウザになりました。Safari は Webkit カーネルを使用した最初のブラウザであり、現在は Apple のデフォルトのブラウザです。
4. Firefox ブラウザ:
Firefox ブラウザは、Mozilla 社が所有するブラウザであり、先ほど述べた Netscape 社の後期ブラウザでもあります。Netscape が買収された後、Netscape の担当者は非営利団体である Mozilla Foundation を設立し、2004 年に独自のブラウザー Firefox を立ち上げました。Firefox は Gecko をコアとして使用します。Gecko はオープンソース プロジェクトであり、コードは完全にオープンであるため、多くの人に好まれています。Firefox の出現により、第二次ブラウザ戦争の始まりが加速しました。第二次ブラウザ戦争は、第一次二大勢力状況とは異なり、今回は 100 の学派が対立することを特徴としており、1998 年の Netscape 買収以来、ブラウザ市場における IE ブラウザの優位性が崩れてきました。
5. Chrome ブラウザ:
Chrome ブラウザは、Google が所有するブラウザです。Chrome ブラウザはリリース以来、常にシンプルさ、スピード、セキュリティを重視してきたため、現在に至るまで人気を博しています。当初、Chrome はブラウザ カーネルとして Webkit を使用していましたが、2013 年に Google が Apple の Webkit カーネルを使用しなくなり、Webkit のブランチ カーネルである Blink を使用し始めたと発表しました。

上記は 5 つの主要なブラウザの紹介であり、続いて 4 つの主要なコアについて説明します。5 つの主要なブラウザを紹介する一方で、4 つの主要なコアも紹介しました。4 つの主要なカーネルは、Trident (IE カーネルとも呼ばれます)、Webkit、Blink、および Gecko です。5 つの主要なブラウザはすべてシングル コアを使用していますが、ブラウザの発展に伴い、デュアル コアも利用できるようになりました。360 や QQ などのブラウザはデュアルコアを使用します。
フロントエンド開発者として、4 つのコアに精通することが非常に必要です。4 つのコアの異なる解析により、Web ページのレンダリング効果がより多様になります。以下に、一般的に使用されるブラウザで使用されるカーネルをまとめます。
1. IE ブラウザ カーネル: Trident カーネル、一般的に IE カーネルとも呼ばれます;
2. Chrome ブラウザ カーネル: Chromium カーネルまたは Chrome カーネルと総称され、以前は Webkit カーネル、現在は Blink カーネルと呼ばれます;
3. Firefox ブラウザ カーネル: Gecko カーネル、一般的にFirefox カーネルとして知られている;
4. Safari ブラウザ カーネル: Webkit カーネル;
5. Opera ブラウザ カーネル: 最初は独自の Presto カーネル、次に Webkit、そして現在は Blink カーネル;
6. 360 ブラウザ、Cheetah ブラウザ カーネル: IE + Chrome デュアル コア;
7 . Sogou、Aoyou、QQ ブラウザ カーネル: Trident (互換モード) + Webkit (高速モード);
8. Baidu ブラウザ、Window of the World カーネル: IE カーネル;
9. 2345 ブラウザ カーネル: 以前の IE コア、そして今では、IE+Chrome デュアルコアでもあります。
 

通常、一般的なものは次の 4 つだけですが、以下に簡単に紹介します。

 

Trident: IE ブラウザで使用されるカーネル。このカーネル プログラムは、1997 年に IE4 で初めて使用されました。これは、Mosaic コードに基づいて Microsoft によって修正され、
現在の IE9 でまだ使用されています。Trident は実際にはオープン カーネルであり、そのインターフェイス カーネル設計は非常に成熟しているため、
IE の代わりに IE カーネルを使用する多くのブラウザー (Maxthon、The World、TT、GreenBrowser、AvantBrowser など) が登場しています。また、
便宜上、単に IE カーネルと呼ぶ人も多くいます (もちろん、カーネルの名前がわからないためにそう言わざるを得ない人もいる可能性は否定できません)。IE 自体の「独占」 (IE は名ばかりの独占ではありませんが、実際には、特に Windows 95 の時代から XP の初期まで) により、IE は市場シェアの点で「独占」の地位を占めていました。 Windows のヘルプ) その結果、Trident カーネルは長い間 1 つの会社によって独占されてきました。Microsoft は長い間 Trident カーネルを更新していませんでした。これにより 2 つの結果が生じました。1 つは、Trident カーネルがほぼ終了していたことです。 1 つは W3C 標準との接触 (2005 年)、もう 1 つは多数の Trident カーネルです。バグなどのセキュリティ問題はタイムリーに解決されておらず、オープンソースに熱心に取り組んでいる一部の開発者や一部の学者は、 IE ブラウザは安全ではないという意見を表明し、多くのユーザーが Firefox や Opera などの他のブラウザに目を向けるようになりました。非 Trident コア ブラウザの市場シェアが大幅に増加したことにより、多くの Web 開発者が Web 標準と非 IE ブラウザのブラウジング パフォーマンスに注目し始めています。

 

ヤモリ

 /ˈɡekəʊ/
: Netscape 6 から使われ始め、その後 Mozilla FireFox (Firefox ブラウザ) でもこのカーネルが採用されました Gecko の特徴は、コードが完全に
オープンであるため、開発性が高く、プログラマーにとっても優れたカーネルです。コードを記述して機能を追加することができます。オープンソースのカーネルであるため
多くの人に愛用されており、Gecko カーネルを搭載したブラウザも数多く存在しており、これも
若いカーネルにもかかわらず急速に市場シェアを拡大​​できる重要な理由となっています。実は、Gecko エンジンの起源は IE と関係があり、前述したように IE は W3C 標準を使用していなかったため、Microsoft 社内の一部の開発者の間で不満が生じ、活動を中止した Netscape の社員らとともに Mozilla を設立しました。当時のMosaicカーネルをベースに
カーネルを書き換えてGeckosが開発されました。しかし実際には、Gecko コアを搭載したブラウザは依然として Firefox (Firefox) が最も多くのユーザーを抱えているため、
Firefox コアと呼ばれることもあります。さらに、Gecko はクロスプラットフォーム カーネルでもあり、 Windows、BSD、Linux、Mac OS X で
使用できます。

 

Presto: 現在 Opera で使用されているカーネル。2003 年に Opera 7 で初めて使用されたカーネル。このエンジンの特徴は、レンダリング速度が極限まで最適化されていることです。現在、Web ブラウジング用の最速のブラウザーカーネルとしても認識されています。 . ただし、その代償として、Web 互換性が犠牲になります。　

　実際、これは動的カーネルです。以前のカーネルとの最大の違いはスクリプト処理です。Presto には当然の利点があります。スクリプト イベントに応じてページのすべてまたは一部を再解析できます。

また、JavaScript の実行速度が最も速く、同じ条件でのテストによると、Presto カーネルが同じ Javascript を実行するのに必要な時間は、Trident カーネルお​​よび Gecko カーネルの約 1/3 にすぎません (Trident カーネルは最も遅いですが、2 つの違いはあまりありません）。
そのテストでは、Apple マシンのハードウェア条件が通常の PC とは異なるため、WebCore カーネルはテストされませんでした。Presto が商用エンジンであるのは残念ですが、Opera を除けば、Presto を使用しているのは NDSBrowser、Wii インターネット チャネル、Nokia 770 Web ブラウザーなどだけであり、これが Presto の開発を大きく制限しています。

 

Webkit: Apple 独自のカーネル。Apple の Safari ブラウザで使用されるカーネルでもあります。Webkit エンジンには、WebCore 植字エンジンと JavaScriptCore 解析エンジンが含まれており、どちらも KDE の KHTML エンジンと KJS エンジンから派生したもので、GPL 条約に基づいてライセンスされているフリー ソフトウェアであり、BSD システムの開発をサポートしています。
したがって、Webkit もフリー ソフトウェアであり、オープン ソースです。セキュリティの面では、IE や Firefox による制限がないため、中国では Safari ブラウザは依然として非常に安全です。

　　Mac OS X が広く使用されておらず、かつては Safari ブラウザが Mac OS 専用ブラウザでしかなかったという事実に限定すると、Opera の Presto を超えました。もちろん、これは Apple が x86 アーキテクチャに切り替えてから人気が急上昇したためです。また、Safari 3 がついに Windows バージョンをリリースしたためでもあります。

OmniWeb や Shiira for Mac などの人気のあるブラウザもあります。

　　Google の Chrome もカーネルとして Webkit を使用します。　

　WebKit カーネルは携帯電話でも広く使用されており、たとえば Google の Gphone、Apple の iPhone、Nokia の Series 60 ブラウザで使用されているブラウザ カーネル エンジンはすべて WebKit に基づいています。

 

 

2. ブラウザのレンダリング原理 (http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)

Web ページはさまざまなブラウザで実行されます。ブラウザがページをロードしてレンダリングする速度は、ユーザー エクスペリエンスに直接影響します。簡単に言うと、ページ レンダリングとは、ブラウザが CSS で定義されたルールに従ってブラウザ ウィンドウに HTML コードを表示することです。 . このプロセスの。まず、ブラウザがどのように機能するかを一般的に理解しましょう。
　　1. ユーザーが URL を入力し (これが HTML ページであり、初めての訪問であると仮定します)、ブラウザはサーバーにリクエストを送信し、サーバーは HTML を返します。ファイル; 2. ブラウザが
　　起動します HTML コードをロードすると、<head> タグ内に外部 CSS ファイルを参照する <link> タグがあることがわかります;
　　3. ブラウザは CSS ファイルのリクエストを再度送信し、サーバーは CSS ファイルを返します。
　　4. ブラウザは、コードの html の <body> 部分の読み込みを続けます。CSS ファイルが取得されると、ページのレンダリングを開始できます。 5. ブラウザは <img> タグを見つけます
　　。コード内で画像を参照し、サーバーにリクエストを送信します。このとき、ブラウザは画像がダウンロードされるまで待たずに次のコードのレンダリングを続けます;
　　6. サーバーは画像ファイルを返します 画像は一定の領域を占めるため、後続の段落の配置に影響を与えます。ブラウザは戻って再レンダリングする必要があります。コードのこの部分;
　　7. ブラウザは、JavaScript コードの行を含む <script> タグを見つけて、すぐに実行します。
　　8. Javascript スクリプトは、このステートメントを実行します。コードの特定の部分を非表示にするブラウザ

(style.display=”none”)。おっと、突然そのような要素が失われ、ブラウザはコードのこの部分を再レンダリングする必要があります;
　　9. 最後に </html> の到着を待ったので、ブラウザは突然泣き出しました...
　　10. 待ってください。まだ終わっていないので、ユーザーがインターフェースの「スキン」ボタンをクリックすると、JavaScript がブラウザーに <link> タグの CSS パスを変更するように要求しました。 11. ブラウザーは、その場にいた全員 <span><ul><li> を呼び出しました
　　。皆さん荷物をまとめてください。最初からやり直さなければなりません...」 ブラウザは
　　サーバーに新しい CSS ファイルを要求し、ページを再レンダリングしました。

 

 

　　ブラウザは毎日このように行ったり来たりして実行されますが、人によって書かれた HTML や CSS コードの品質は異なり、ある日実行中にクラッシュする可能性があることを知っておく必要があります。幸いなことに、この世界にはページ再構成エンジニアというグループがまだ存在します。彼らは通常はあまり目立たないのですが、ビジュアル デザイナーが写真を切り取ったり、単語を変更したりするのを手伝うだけです。実際、彼らは舞台裏で多くの実用的なことを行っています。

なぜページが遅いのかと言えば？これは、ブラウザーがレンダリングに時間と労力を費やすためであり、特に特定の部分がわずかに変更されてレイアウトに影響を与えていることが判明した場合、戻って再レンダリングする必要があるためです。専門家はこのロールバック プロセスをリフローと呼んでいます。

 リフローはほぼ避けられません。ツリー状のディレクトリの折りたたみや展開 (基本的には要素の表示と非表示) など、現在インターフェイスで人気のあるエフェクトの一部は、ブラウザのリフローを引き起こします。マウスのスライド、クリック... これらのアクションにより、ページ上の特定の要素の領域、位置、余白、その他の属性が変更される限り、ページ内、ページの周囲、さらにはページ全体の再レンダリングが発生します。通常、ブラウザがコードのどの部分をリフローするかを予測することはできません。それらはすべて相互に影響を及ぼします。

リフロー問題を最適化し、不要なリフローを最小限に抑えることができます。たとえば、冒頭の例の <img> 画像読み込みの問題は、実際にはリフローであり、画像の幅と高さを設定するだけで回避できます。このようにして、ブラウザは画像が占める領域を認識し、画像をロードする前にスペースを予約します。

また、リフローとよく似た用語にリペイントというものがありますが、中国語ではリドローといいます。要素の周囲や内部のレイアウトに影響を与えずに、要素の背景色、テキストの色、境界線の色などを変更するだけの場合、ブラウザは再描画されるだけです。再描画の速度は明らかにリフローよりも速いです (IE では用語を変更する必要があります。リフローは再描画よりも遅いです)。

3. ブラウザーのレンダリング原理の観点から CSS のパフォーマンスについて語る (http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)

私たちは通常、ほぼ毎日ブラウザを使用しており、作成したページはブラウザによって表示方法が異なる可能性があります。勤勉なフロントエンド シージ エンジニアは、さまざまなブラウザと互換性を持たせるために常にテストとデバッグを行っており、さまざまなバグや解決策を頭の中に書き留めていますが、私たちは積極的に注意を払い、理解していないようです。ブラウジング デバイスの動作原理。これについて少しでも理解すれば、プロジェクト中にいくつかの問題を効果的に回避し、それに応じてページのパフォーマンスを改善できると思います。今日は主に、ブラウザのレンダリング原理に基づいて CSS の書き込みパフォーマンスを改善します (もちろん、JS については今回は考慮しません。以降の記事で紹介します)。レンダリング原理を明らかにしましょう。ブラウザの謎のベール:

ブラウザによって表示されるページ効果の違いを最終的に決定するのは、通常「ブラウザ カーネル」と呼ばれるレンダリング エンジン (植字エンジンとも呼ばれる) であり、Web ページの構文 (HTML、 JavaScript) とレンダリング、Web ページの表示。同じコードが異なるブラウザで異なる効果を表示する場合は、異なるブラウザ カーネルが原因である可能性があります。

ページを読み込むときのブラウザの具体的なワークフローを見てみましょう (図 1):

(写真1)

1. HTML を解析して DOM ツリーを構築する (HTML を解析して DOM ツリーを構築する): レンダリング エンジンは HTML ドキュメントの解析を開始し、ツリー内のタグを「コンテンツ ツリー」と呼ばれる DOM ノードに変換します。

2. レンダー ツリーの構築: CSS (外部 CSS ファイルおよびスタイル要素を含む) を解析し、CSS セレクターに基づいてノードのスタイルを計算し、別のツリー (レンダー ツリー) を作成します。

3. レンダー ツリーのレイアウト: ルート ノードから再帰的に呼び出され、各要素のサイズ、位置などが計算され、各ノードに画面上で表示される正確な座標が与えられます。

4. レンダー ツリーのペイント: レンダー ツリーをトラバースすると、UI バックエンド レイヤを使用して各ノードが描画されます。

主なプロセスは次のとおりです: dom ツリーを構築し、ページに表示される各要素はこの dom ツリー内に作成されます。新しい要素がこの dom ツリーに追加されるたびに、ブラウザは CSS エンジンを通じて CSS スタイル シートを検索します。そして、この要素に一致するスタイル ルールがこの要素に適用されることを見つけます。

#{} 内の名前

ちょっと不可解ですが、速いように見えますが、実際は遅いです#_#。私たちのほとんど、特に左から右に読む人は、おそらくブラウザも左から右へのマッチングを実行するため、このルールのオーバーヘッドは高くないと考えているでしょう。私たちの頭の中では、ブラウザーが次のように動作すると想像します。つまり、ID nav を持つ一意の要素を見つけて、このスタイルを直接の子要素の li 要素に適用します。ID nav を持つ要素があり、子要素がいくつかしかないことがわかっているため、この CSS セレクターは非常に効率的であるはずです。

実際、CSS セレクターは右から左に一致します。この知識を理解した後、この以前は効率的だったルールが実際には非常に高価であることがわかります。ブラウザはページ上の各 li 要素を走査し、その親要素の id が nav であるかどうかを判断する必要があります。

*{}

特定の ID はページ内の 1 つの要素にのみ対応するため、追加の修飾子を追加する必要がなく、効率が低下します。同時に、クラス セレクターを修飾するために特定のラベルを使用せず、実際の状況に応じてクラス名を拡張します。たとえば、ul.nav を .main_nav に変更することをお勧めします。

ウル リ リ リ .nav_item{}

以前にこのタイプのセレクターについて書いたことがありますが、結局のところ、子孫セレクターがいくつあるか数えることができませんでした。.extra_navitem などのクラスを使用して最後のタグ要素を関連付けて、クラス extra_navitem を持つ要素のみが関連付けられるようにしてはいかがでしょうか。一致させる必要があり、効率的です。大幅に改善されました

この点に関して、CSS 作成プロセス中に、次のパフォーマンス向上ソリューションが要約されました。

驚くほど多くの回数が計算される可能性がある *{} などのワイルドカード ルールの使用は避けてください。使用する必要がある要素のみを選択してください。
選択するタグはできるだけ少なくしてください。代わりに、クラスを使用してください。たとえば、#nav li{}。nav_item のクラス名を li に追加できます。.nav_item{} を選択します。は次のとおりであり、タグは使用しません
。ul#nav などの ID またはクラス セレクターを制限し、#nav に簡素化する必要があります。
子孫セレクターの使用はできる限り少なくし、セレクターの重み値を減らします。子孫セレクターのオーバーヘッドは、セレクターの深さを最小限に抑え、最大でも 3 つのレイヤーを超えないようにし、より多くのクラスを使用して各タグ要素を関連付けます。継承を考慮してどの属性を継承できるかを理解し、これらの属性のルールを繰り返し指定することを避けて
ください
。効率的なセレクターを使用してページのレンダリング時間を短縮し、それによってユーザー エクスペリエンスを効果的に向上させます (ページが高速であればあるほど、より多くのユーザーが気に入ります^_^)。CSS セレクターのテストを見てみましょう。この実験の焦点は次のとおりです。複雑なセレクターと単純なセレクターのコストを評価します。おそらく、レンダリング速度を最大化したい場合は、個別のタグごとに ID を構成し、これらの ID を使用してスタイルを記述することになるでしょう。それは確かに超高速で超バカバカしいことでしょう！その結果、セマンティクスが非常に貧弱になり、後で保守することが非常に困難になります。

しかし、最終的には、CSS のパフォーマンスは小規模なプロジェクトでは実際には重要ではなく、改善は明らかではないかもしれませんが、大規模なプロジェクトでは間違いなく役立ちます。また、CSS を書く良い習慣と方法は、自分自身に対してより厳しくなるのに役立ちます。

元のリンク: https://blog.csdn.net/qq_36379597/article/details/101382234

プロジェクト中

1. IE、Firefox、Chrome のクリック オブジェクトの違い:

　　このプロジェクトでは、ページに登録されているイベントが多すぎるため、モーダル ボックスを閉じるボタンのクリック イベントを伴うモーダル ボックス (ポップアップ レイヤー) を大量に作成しました (閉じるボタンはブートストラップ スタイルです)。 、イベント委任の形式が使用されます Do it、誰もが知っているように、ブートストラップスタイルの閉じるボタンは次のように書かれています

<button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">&times;</span></button>

ボタンには識別子として使用されるタグが埋め込まれており、ターゲット イベント オブジェクト (event.target) をキャプチャすると、Chrome ブラウザでは埋め込まれたスパン タグがキャプチャされますが、IE と Firefox ではターゲット イベント オブジェクトのみがキャプチャされます。スパンの代わりにボタンをキャプチャします。空！Chromeで開発していた時はspanタグにidを書いて対応していたのですが、IEでデバッグすると反映されず、一晩中落ち込んでいました。

　　解決策は、span タグをネストする代わりに、ボタン タグに記号「×」を入力し (主要な入力メソッドにはすべてこの記号があります)、ID がボタン タグにバインドされます。

2. Ajax キャッシュの問題

　　サーバーをデバッグすると、必ずキャッシュの問題が発生します。このキャッシュは、JS コードを変更した後のページの更新に影響するだけでなく、変更された JS コードを更新できなくなります。さらに恐ろしいのは、IE では、このキャッシュが Ajax リクエストに影響を与えることです。 .データ。

　　例: ページがロードされると、バックグラウンドに ajax リクエストを送信してデータをリクエストし、次に情報を更新し、同じリクエストを送信してページのデータを更新します。これら 2 つのリクエストは同じリクエストとみなされます。 、ブラウザはこれら 2 つを認識します。リクエストが同じになった後は、データはサーバーから再度取得されず、前のリクエストのデータのみが返され、サーバー リクエストを減らす効果が得られますが、これは私が望んでいることではありません。欲しい。

　　解決策は、jq の ajax にはキャッシュ オプションがあり、これを false に設定するか、リクエスト バックグラウンドで URL の末尾にタイムスタンプを追加します。次に例を示します。

$.ajax({
            url: '/Management/file/ajaxDeleteFile.action?t=' + new Date().getTime,
            type: 'POST',
            dataType: 'json',
            data: "accuid=" + accuid + "&uid=" + uid,
            success: function(data){
                if (data.code == 100) {
                    //请求成功后刷新文件列表
                    depFileListModule.initFileList(curPath,curDepId);
                    //关闭对话框
                    s("#drop-file-floor").style.display = 'none';
                    alert("删除成功");
                }else if(data.code == 300) {
                    //后台状态码为300 表示这个账号在另一个浏览器或终端登录
                    //返回错误信息并跳转到登陆页
                    alert(data.message);
                    window.location.replace("/Management/public/login.action");

                }else{
                    alert("删除失败，遇到未知错误请重试");
                }
            }
        })

またはキャッシュを false に設定します

$.ajax({
            url: '/Management/file/ajaxDeleteFile.action',
            type: 'POST',
            dataType: 'json',
            data: "accuid=" + accuid + "&uid=" + uid,
            cache: false,
            success: function(data){
                if (data.code == 100) {
                    //请求成功后刷新文件列表
                    depFileListModule.initFileList(curPath,curDepId);
                    //关闭对话框
                    s("#drop-file-floor").style.display = 'none';
                    alert("删除成功");
                }else if(data.code == 300) {
                    //后台状态码为300 表示这个账号在另一个浏览器或终端登录
                    //返回错误信息并跳转到登陆页
                    alert(data.message);
                    window.location.replace("/Management/public/login.action");

                }else{
                    alert("删除失败，遇到未知错误请重试");
                }
            }
        })

 

これは、他の人のブログで書かれた、Ajax キャッシュに関する一般的な科学的説明です。

　　1: ブラウザは GET アクセスを冪等であるとみなします。

　　同じ URL に対する結果は 1 つだけです (これは、URL 文字列全体が完全に一致することを意味します)。
　　したがって、URL 文字列が 2 回目の訪問中に変更されない場合、ブラウザは最初の訪問の結果を直接取り出します

　　2: POST

　　GET の冪等アクセスが URL の後に追加されるのを防ぐために、アクセスが変更されているか (ブラウザーは POST 送信が変更されたに違いないと考える) を考慮しますか? +new Date();, [要するに、訪問ごとに URL 文字列を変える]

　　この原則は、WEB ページをデザインするときにも従う必要があります。

http://www.cnblogs.com/fullhouse/archive/2012/01/17/2324842.html

//-----------------7-22追記----------------

非常に重要な問題を無視しました

3. IE の getComputedStyle によって引き起こされる問題 

少し前に、要素の最終スタイルを取得する getComputedStyle js メソッドを見ました。元のリンクはマスター Zhang Xinxu からのものです: 要素の CSS 値を取得する getComputedStyle メソッドに精通しています « Zhang Xinxu-Xin Space-Xin Life

学校のプロジェクトで試してみたいのですが、ブラウザの違いにより、この関数を IE と互換性を持たせるにはこのように記述する必要があります。

element.currentStyle? element.currentStyle : window.getComputedStyle(element, null)

 

ここで別のメソッドが表示されていることがわかります: currentStyle

この方法は IE と互換性がありますが、要素スタイルで幅が設定されていない場合、IE では auto! として表示されます。

このように、いくつかの値を計算したい場合は非常に困難ですが、解決策は 2 つあります。

1. プロジェクトが IE の下位バージョン (ie9+) と互換性がない場合

次に、 getComputedStyle メソッド　　を直接使用できます 。このメソッドは、幅を値で返します。

2. 互換性の高いoffsetWidth または clientWidth に切り替えます(当時の私はまったく盲目で、上記の役に立たない方法を使用していましたが、新しいことを試すのは悪いことではありません (笑))

//--------------------------2017-10-17追記------ ---- -

4. FirefoxでgetComputeStyleを呼び出すとpadding属性が取得できない

そうです、また getComputedStyle の話です。今回と同じように要素の属性を取得するためにこのメソッドを呼び出す際もブラウザの違いによって違いが出てきます。

クロムの場合:

window.getComputedStyle(elem, null).padding

対応するパディング属性はここで取得できます。

Firefox では、この方法でパディングを取得するのは少し抽象的すぎると感じるかもしれません。そのため、getComputedStyle メソッドにはパディング属性はなく、次の属性があるだけです。

マージンについても同様です

  そして国境はさらに

そのため、ブラウザとの互換性を考慮して、paddingは省略せず、borderにはどのようなborderの内容を取得したいのかを明確に記載してください。

記事リンク: https://www.cnblogs.com/stitchgogo/p/7204333.html

注：この記事はインターネットからのものです