Oo.ホームページを作成したときの備忘録です。ここの落書き人のメモリーが揮発性ですのでメモっておきます。※当該落書き人の備忘録ですのでHTML,CSS,JavaScriptの基礎的な説明は省いてあります。3)Firefoxの不可解な2回リクエストFirefoxがクロスドメインじゃないのにクロスドメインだと宣う。ついでにクロスドメインだった時のnode.jsでのプリフライトリクエスト対応。逐次型プログラミングが染み付いたプログラマがハマるJavaScriptの非同期という落とし穴!!これ、落書き人本人の話です。プログラム・ソース・コードの記述順に実行されるという潜入概念を捨てないとJavaScript記述の非同期の動作が理解できずに不具合を招きます。ハマるのがコールバックで記述する無名関数で記述した場合です。ここで記述した実行コードはコールバック時点で実行されるもので、コールバック記述の次に記述したコードが次に実行される訳でもなく、thisも引き継がれていません。この感覚が逐次型しか経験のないプログラマには理解しずらい部分です。非同期という感覚が身につかないとJavaScriptの理解ができません。2015(ES6)でますます記号のお化けみたいな記述がでてきて頭の切り替えに苦労しています。非同期の素晴らしさはnode.jsで実感できます。逐次型プログラミングでより多くのトランザクション処理を行うためにはスレッド(又はタスク)で多重化して処理性能を上げるのが常識でした。非同期のnode.jsはシングルスレッドで有りながら処理能力が素晴らしい。今はnode.jsで非同期プログラミングに嵌っております。System)手法SPAですが「なっからHP」は文書としては単一なHTMLページです。厳密にはiframeを埋め込んでいますがそれは機能的に別物なページです。SPAにした理由はHTMLページを増やすと整理整頓が苦手な落書き人にとってはトッチカらってしまうのが理由です。単一ページでコンテンツが増えると一文書として大きくなり見通しが悪くなります。Notation)で整理しています。その整理方法ですが、文書作成が楽な某グループウェア・ソフトを利用しています。そのソフトからJSONデータとして書き出して、ウェブ・サーバーにアップロードしています。JSONでデータ化しているコンテンツは以下の通りです。Back/Forwardの関係SPAで構成されたページ内の遷移ではスムーススクロールや表示・非表示で制御した場合に、この遷移をdocument.historyに記録させないと、ブラウザの前ページ・次ページが遷移通りに機能しません。利用者からするとブラウザで前ページで戻りたい場合に「あれ?」という事になります。忘れない為のメモですので、詳細は事例のソースコードを参照してください。falseと書くのが一般的です。これはスムーススクロールした後にハッシュリンク本来の動きを抑止するためです。この短所はhistoryに記録されません。そこでhistory.pushState(state,null,URL)にてhistoryに遷移を記録することで対応できます。Backでもスムーススクロールをさせる為には、window.addEventListener('popstate',function(e){},false);でキャッチします。historyに記録させるために、スムールスクロール後にlocation.hrefに代入する例を見かけますが、これは本来の遷移も加わる為にお勧めできません。trueで抜ければ済む話です。事例1:ちゅんラヂの説明ページ事例2:株式会社ナックのホームページ※依頼されて作成したサイトで、SPA内ナビ方法が少し凝っています。(2).ブロックの表示・非表示でコンテンツを切り替えている場合history.pushState(state,null)でコンテンツが切り替えられた時に、そのブロクのIDなどを記録しておきます。ブラウザの前ページ・次ページが行われたイベントをキャッチして、stateに記録しておいたブロックのIDを取得して、対応するコンテンツに切り替えます。事例:なっからのトップページ※ドロワー型切り替えでやりすぎていて鬱陶しいですが、お遊びサイトなので愛嬌。(3).history.pushStateの引数について引数1であるstateには任意のオブジェクトがセットできます。backに対応していな物が見受けられます。アプリケーションとして一つ前の状態を保持したり再現するのが難しいので気持ちはわかります。その状態保持にstateが使えます。引数2であるtitleはブラウザが対応していない様ですので、現状はnullにしておきましょう。ブラウザのアドレス欄に遷移の状況が表示できます。この値とするかしないかですが、その遷移のステップをお気に入りなどに登録されて、いきなりそのステップに遷移できるのなら、そのURLをセットして、いきなり遷移できないのであればnullをセットするのがお薦めです。セットするURLですが、擬似的なパスを指定した場合には、その擬似的なパスは存在しませんので、不用意にお気に入り登録されると具合の悪い事になります。そこでハッシュリンクをセットするろ方法がお薦めです。Messaging)window間で相互にオブジェクト(*1)を送受信する事ができます。この通信はクロス・ドメイン間でも可能です。信頼出来る別ドメインのウェブ・アプリ間でデータの授受が必用な場合に用います。信頼できるドメインの確認ロジックを組み込む必用があります。これを慎重に組み込み、不用意にデータ詐取されことを防止する必用があります。以下に、ちゅんラヂとそのエリア選択との間で、エリア選択結果の授受を行っいる事例を上げておきます。この事例では信頼できるoriginを確認しなくても、不正利用されて困るようなデータ授受はありません。不正な利用は気持ち悪いことから、信頼できるoriginの確認を行っています。console.log("tunein2area.htmlの単独利用では選択エリアを戻すwindowがありません。console.log("tunein2area.htmlは親windowへ送信する要件のみです。それ以外のwindowへ選択エリアを戻す事は出来ません。}*1:IEでの扱いIE8はStringのみでObjectの授受が出来ません。IE9以降では確認していませんがIEの存在がメッセージ通信の利用を難しくしています。6(2015)*2以降の機能も、IE以外のブラウザが対応した物は使う予定です。実質的にIE切り捨てですが、audio要素を用いなければならないウェブアプリですので、IEの為に上位互換は考慮いたしません。BtoB以外でIEに固執する事はマイナス面しか無いと考えています。新しい機能が取り込まれることがないIE11が退場する2025年10月15日までは長く悩ましい時期が続くのかもいれません。2015(ES6)への対応が進んでいます。BabelとかTypeScriptを使えよという話もありますが、落書きとしてIEは見捨てていることと、デバックがややこしいので素のJavaScriptが好きです。iframeで機能単位に分割ちゅんラヂはiframeを多様しています。iframeを多様することは、文書としてのHTMLでは好ましくありません。ラヂの様に機能(ウェブ・アプリ)の場合は、機能毎に分割管理することで、一つのHTMLが複雑化・肥大化することを防ぎ、メンテナンス性の悪化が防止できます。各機能のHTML(window)間のデータ授受はメッセージ通信を利用しています。blockingの回避が容易にできます。親Windowで何らかのユーザー操作が無い状態でのautoplayは出来なくなります。poricyの実装が進んでいる為です。APIでの「Access-Control-Allow-Origin」の扱いに違いがちゅんラヂの様にクロスドメインで音声配信を再生する時の話です。audio要素で再生している音声のVisualizerを表示してみました。APIを使ってDAW(っぽいもの)を作ってみる」を使わせて頂きました。本題ですがaudio要素にVisualizerを表示する為にAudioContextにaudio要素を渡すと音声出力がzeroになってしまします。それはaudio要素のcrosプロパティに'anonymous'をセットすることで対応できました。これでも駄目な配信がありました。HeaderでAccess-Control-Allow-Originの設定有無で、双方の解釈に違いが有ることが判りました。*1:配信サーバー側にAccess-Control-Allow-Origin設定が無い場合audio要素からはAccess-Control-Allow-Origin設定が無い場合は接続しても良い。APIではAccess-Control-Allow-Origin設定が無い場合は接続の許可が無いと解釈している様です。今回の目的であるちゅんラヂにVisualizerが設置できない。APIで受けるクロスドメイン配信では、必ずAccess-Control-Allow-Originで明確に'*'が指定されていないと接続できないという事になります。Chromeで確認しました。そこでちゅんラヂでのVisualizer表示は、Access-Control-Allow-Originに'*'が送られてこない配信では諦めて、Visualizer無しで接続する様にしました。現状ではradiko.jpがクロスドメイン接続を排除しています。ブラウザでのクロスドメイン可否Access-Control-Allow-Origin対応はブラウザが実施しています。純粋なウェブアプリはこの制限を超えられません。ローカル(ブラウザ以外)からのアクセス可否ローカルプログラムはAccess-Control-Allow-Originによる規制ルールを実装しなければアクセスができます。ローカルプログラムからのアクセスが可能であることからradiko.jp用の録音ソフトが存在します。APIサービスちゅんラヂではIPアドレスからエリアを自動判定する為に「http://ip-api.com/json/」サービスを利用しています。ここでip-api.comがTLSに対応していないために、ちゅんラヂに「https://~」でアクセスすると混在コンテンツになり利用できません。Serverに中継させることで混在コンテンツを回避しました。それを回避する為の中継プログラムはPHPで記述しました。コードは下記の2行です。$_SERVER["REMOTE_ADDR"]);たった2行のプログラムを解説するのは野暮というものですので、解説は割愛します。スムース・スクロールベタですが、スムース・スクロールをこの備忘録で利用しています。私はページ内リンクがスパッスパッと切り替わるのが好みです。それはページ構成がわかっている場合の話です。スムース・スクロールさせることで、感覚的にページ内を上下方向のどちらに動いたのかがわかり、ページ内で迷子にならないのが利点です。</a>」を使わずに、id属性がページ内アンカーの役割をします。コードは下記の通りで、スムース・スクロールはjQueryのanimateで行っています。</script>タブでコンテンツを切り替え(同一ページ内)なっからHPのコンテンツはタブで切り替えています。HTML的にはiframeを除き1ページ構成で、同一ページ内のブロックの表示・非表示を切り替えています。利点はコンテンツ切替時のページ読み込みがありませんので、切り替えは瞬時に切り替わります。この手法はなっからHPの様に、コンテンツ量が少ないウェブページの場合に利点が活かせます。大きなコンテンツの場合は初期ロードに時間がかかりますので、この手法は短所になります。</section>タブメニューのcss紙ベースのインデックス・タブのイメージにしました。基準となるフォントのサイズと相対的なフォントサイズの指定で、全体的な文字サイズのバランスをそのままで拡大・縮小ができる様にする。全体的な文字サイズを変えたい時には、html要素のcss指定を変えるだけで、配下の各要素のフォントサイズを変更する必要がなくなる。基準となるフォントサイズ(em指定)はhtml要素に指定する。Japanese」を利用して、基準をなるサイズをウェイトを指定している。ウェブ・フォントを読み込むことで表示までの時間が掛かるが、プラットフォームに依存しない文字表示が可能になる。「arial」指定は、何らかの理由でGoogleからフォントが読み込めなかった時の代替えフォント指定。html要素は以下の相対フォントサイズ(rem指定)は指定する。基準フォントに対す相対的なサイズを指定することで、全体のフォントサイズ変更時の変更作業を最小限にする考慮を行う。}埋め込みフォントを止めました。Fontを埋め込んだ時は、ウェブ・フォントの読み込み時間が1秒程度で問題ないと判断したのですが、最近は読み込みに5秒以上かかる様になってしましました。私は待ち時間5秒を超えたら実用性に疑問を感じますので一旦、ウェブ・フォント埋め込みを止めました。読み込みが遅くなった原因に心当たりがあります。私が利用しているプロバイダに問題が有るようです。春頃から夕方以降にダウンロード速度が30Kbps程度まで悪化しています。このプロバイダは老舗でパソコン通信時代から使っているメールアドレスがあり止めるに止められない状況です。私の環境に問題が有るのは明白ですが、他にも私のような環境の方が居られると思い、しばらく様子見で埋め込みフォントは見合わせます。複数のYouTube動画を埋め込む時はクリック後に動的再生で「何いってんだ!」と言わないでください。YouTubeの埋め込みはiframeで読み込まれるコードが結構重い。これを複数設置するとローディングに時間がかかります。いうことで複数埋め込むべきでは無いというお話です。そこで、なっからHPでは直接埋め込まずに、一覧はイメージを並べて、そのイメージがクリックされた時に動的に埋め込みコードを生成しています。イメージをクリックした時にpopup風のブロックを動的に作り出して、そこにYouTube動画埋め込みコードを書き出し、再生しています。loadingやsending待ちの時には不用意な操作を防止させるなっからHPではローディングが終わるまで、待っている事を知らせるアイコンが表示しウィンドウ全体を覆うことで、不用意な操作を防止しています。静的なコンテンツだけではなく、動的にJSONデータを読み込んでコンテンツを表示していますので、その処理が完了する前にメニューをクリックされた場合の動作が不定になる可能性があります。これを防止する為です。入力フォームに入力されたデータをサーバーに送信した場合にも、この手法でサーバーからの応答が戻るまで不用意な操作を抑止することで、せっかちは方が送信ボタンを何度もクリックして重複送信になってしまう事を防げます。$('#loading').hide();bxSlider:スライダーが簡単に設置できるjQueryプラグインのbxSliderは高性能なコンテンツ・スライダーでレスポンシヴ・デザインにも対応しています。bxSliderを入手しましょう。bxslider-4こちらの利用方法を参照してください。設定項目が盛りだくさんです。66から自動再生が出来なくなりました。これはサイトを開いたら音が出てビックリを無くす処置です。これにより、ちゅんラヂは「~URL~?recieve=放送局ID」で開くと同時に自動再生をさせる機能がChromeでは使えなくなってしまいました。YouTubeは相変わらず自動再生が出来ています。YouTubeが自動再生できるのだから、ちゅんラヂだって出来る筈と思い色々と試してみました。行ったことはaudioタグの属性に「muted」を指定しておき、JavaScriptにて再生時にそのミュートを解除する。ラジ・プレイヤーを埋め込んであるiframeにautoplay属性を与える。YouTubeの動画が表示される部分を解析してみましたが謎のままです。GoogleのYouTubeだけ特例で認めるのってズルい気がします。ところで、何度か手動再生を行ったサイトからの自動再生が可能になります。Indexで管理され「chrome://media-engagement/」で確認できます。このscoreが高くなると自動再生を認めるようです。Chromeの設定を以下の手順で変更すると以前の状態に戻り自動再生が有効になります。NOW]ボタンをクリックなお、Firefoxの「media.autoplay.esabled」はfalseにすると自動再生ができなくなります。Chromeの様にiframeを介してた自動再生も出来なくなります。3はHTML補完機能に優れています。タグ候補はHTML5対応です。終了タグは“</”と入力すると自動で補完されます。CSSファイルとの連携で対応する行表示などは感動的ですらあります。慣れるとHTMLページを整える作業が効率よくできます。既定値のままでは日本語入力が使いづらいです。そこで日本語のインライン入力用にIMESupportをインストール(*1)します。既定値ではShift-Jisが扱えませんのでConvertToUTF8もインストール(*1)します。それと既定のフォントと行間表示が日本語用には見づらいものです。そこで下記の様に、基本設定のユーザー設定欄に打ち込み、見やすくしました。フォルダからファイルをクリックした時に開くプレビュー機能は慣れないと使いづらい事から、これを切ります。Codeというエディッタのプレビュー機能も使いづらいです。Editor:enablePreviewのチェックを外す事でします。Textで開いたら、これも感動的でした。Textがあれば楽だったのにと感じました。コマンドラインプログラム大好きな虫が、また復活しそう。Textは定期的に購入催促が表示されます。購入催促されても使い続けられますので、気が済むまで試用を続ければ良いと思います。ライセンス購入しても良いという思いになります。Editorも使ってみましたが鈍足でHTML補完も文字入力もかなり不満でした。Editorは手打ち派の私にとっては有り得ないようなソースコードが吐出されるので使いません。Editorが良いと思います。Dreamweaverとか使える環境の方は、それがベストだと思います。Textを使う手打ち派です。Packageを選択しConvertToUTF8をインストールFirefoxの不可解な2回リクエストちゅんラヂあいる(HTTPサーバー)という、ローカルで受信したネットラジオのストリームをちゅんラヂ(ブラウザ)に向けて流し込むプログラムを作成しています。簡単に言えばHTMLとWebサーバーの組み合わせでネットラジオを受信しようという魂胆です。ラヂあいるを公開できる日が来るかは未定です。Web形態に拘っていますので、こんなややこしい構成にしています。目標は国内のサイマルラジオを一堂に全部を集めてザッピング出来うようにすることです。閑話休題:ちゅんラヂあいる作成中にFirefoxの不具合に悩まされました。間違いなく1回しかリクエストしていないのに、サーバー側には2回もリクエストが届くのです。Webアプリにとっては同じリクエストが2回も同時に届くなんて致命的です。セッション管理して、ほぼ同時に届いた処理をぐちゃぐちゃにならないようにすれば済む話です。ラジオを受信するだけのお遊びソフトでそこまでやってもしょうがない、それにFirefoxの不具合を根本的に解消できることにはなりません。それにサーバーはnode.jsを素のまま使っているだけで、至って簡素なプログラムです。自分用でms単位で同じ処理のリクエストなんて想定してもスペックオーバーになるだけです。検索してみるとhrefやsrcを空欄にした場合や、レンダリングが2回さるようなHTMLページで2回リクエストが発生している様です。今回のケースはHTMLページが存在するわけではなく、URLでサーバーにリクエストするだけの物です。ヒットしたケースとは別物です。試していると同じ種類のリクエストでも正常に1回だけの場合もあります。リクエスト方法を色々が変えてもみました。表が駄目ならXMLHttpRequestにて裏側でリクエストも行ってみました。何をやっても症状の改善がみられません。2日も弄り回して回避策を探りました。そこで、上手くゆくリクエストと駄目なリクエストのURLをじっくり比較してみました。語尾に「.m3u8」がある場合に、Firefoxが勝手に2回リクエストを行っていました。※ドットの部分をアンダースコアに補正すると問題なしそこでサーバー側の処理にて「_m3u8」→「.m3u8」変換を行うことで、Firefoxの不可解な動作が回避しました。レアなケースではありますが、これは厄介な不具合です。Firefoxはm3u8に対して何をしようとしているのでしょうか。判ったからといって自力でFirefoxのこの問題を改修できるはずもありません。Mozillaにフィードバックで送信しておきました。(^^ゞそれに、ちゅんラヂあいる環境は自分専用で公開の目処が立っていないですし(^○^)しかし、こんな事があってもFirefoxはメインで使うブラウザです。シンプルな考え方が好きなブラウザです。私はFirefoxを中心に、Chromeで動作確認を行うようにしています。Edgeは気が向いたら時々。IEに至ってはWebアプリはほとんど動かないことが多く敢えて動作確認対象から除外しています。ビジネス用でIEでの動作が求められる場合以外は無視です。Firefoxがクロスドメインじゃないのにクロスドメインだと宣う。ついでにクロスドメインだった時のnode.jsでのプリフライトリクエスト対応。Firefox+jQueryの$.ajaxで不可解な動作に遭遇しました。それはFirefoxがXMLHttpRequestで「クロスオリジン要求をブロックしました」となる不可解な動作のお話です。要求が成功しなかった)。現象Firefoxは上記のURLのをサーバーに送信すらせずにエラーを吐きます。因みにリクエスト先はクロスドメインではありません。Chromeは同じ条件でサーバーにリクエストを送信してくれます。Firefoxでも上記URLの引数「url=」の後ろが上記以外ならリクエストを送信してくれます。動作環境ウェブサーバーはnode.jsです。ブラウザ側のXMLHttpRequestはjQueryの「$.ajax」を利用しています。ブラウザのアドレス入力欄に直接入力してもエラーになります。対策方法GETリクエストをやめて、POSTリクエストで「url=」の引数を渡すようにすることで、Firefoxの不可解な現象を回避できました。結果GETからPOSTに変更したことでFirefoxの不可解な現象が解消しました。以前悩んだFirefoxの「.m3u8」の不可解な動作もこれで回避できることがわかりました。教訓ですが、GETリクエストの長々としたURL引数で情報を送らずに、素直にPOSTで情報を送ったほうがベターだということです。その時の送る情報はJSON書式のプレーンテキストで送ると、データの授受の処理が楽になります。実はテスト段階では同一ドメインですが、公開段階ではクロスドメインになりますので、同一オリジンポリシーに引っかかり動作しません。そこでサーバー側で対応する必要があります。クロスドメインでのPOSTはブラウザが先にOPTIONSメソッドでプリフライトリクエストを送信します。node.jsは低レベルなHTTPサーバー機能ですので、プリフライトリクエストに自動的に応答する機能がありません。そこでnode.jsのJavaScriptでOPTIONSリクエストが来たら、以下の様に許可するレスポンスを返さないと、POSTリクエストをブラウザが送信してくれません。}上記で返すヘッダーの内容は必要最低限の許可を返します。この情報はここで得られました。Content-Typeを許可してもFirefoxはクロスドメインで本来許可されているタイプ以外は拒絶(CSRF対策?)します。詳しくはオリジン間リソース共有を参照して下さい。そこでデータはJSONオブジェクトではなく、JSON書式のプレーンテキストで送ることで対処する必要があります。ところでCSRF対策は、ここで作成しているサーバー(node.js)はlocalhost限定物で割愛しています。公開する時には当然ですがCSRF対策しないと駄目です。音量調整スライダーの可変量と耳で感じる音量変化の感じを近づけるちゅんラヂ・プレイヤーの音量調整スライダーのお話です。APIの音量値を直線的な値で変化させると耳で感じる音量変化に対して不自然でした。耳で感じる音量変化ですがスライダー最小からの音量変化が大きく、スライダーの半分くらいから上で緩やかな音量変化に耳では感じます。耳で感じる変化量が対数グラフっぽい感じです。これでは音量が小さい方の音量調整に不満を感じます。そこでスライダーの値が小さい方での音量値の変化が小さく、スライダーの値の大きな方で音量値の変化が大きくすることで、耳で感じる変化量が自然になるのではないかと思いました。スライダーの変化範囲を0~30で1ステップ毎の変化(WALKMANと同じ)としました。これを音量値0~1(*1)に間に収まる様に指数計算(=2^G3/2^30)してみるとスライダー値29まで0.5まで緩やかに上がり、30でいきなり1.0となりました。そこで以下の計算式に落ち着きました。同じ整数同士を累乗すると尻上がりな値になり、その値を0~1以下の実数にするという単純なものです。こんな単純な計算でも耳で感じる音量変化がかなり自然になりました。30)後で知ったのですが、私が求めた指数っぽい変化をAカーブと云うのだそうです。y=xで信号的に直線的に変化するのがBカーブ、対数っぽいのがCカーブだそうです。オーディオのボリューム調整はAカーブだそうです。Aカーブを細かく調整したい場合はここが参考になると思われますが、なんか難しくて高等数学が苦手な私には理解不能です。APIの音量値は0~1の間の実数です。Chromeの頑固なキャッシュを回避ウェブページを変更し時にhtmlファイルは直ぐに反映されましたがCSSがキャッシュされたままで表示が崩れる現象に遭遇しました。Cstl+Shift+RでリロードさせてもCSSのキャッシュが無効になりませんでした。設定の中の閲覧履歴を消去でやっとCSSが削除されて表示が最新になりました。ウェブページを訪れるユーザーはそんな事はしません。そこでCCSの読み込みURLの引数に変更時日時を指定する事でキャッシュ回避を行いました。仕組み的には引数の値が変わればキャッシュが別もになり読み込みが行われます。type="text/css">「1539181239」の部分には私は更新時点のUNIXタイムをセットしました。JSONPがキャッシュで更新されないときJSONPデータのURLに日時を付加してキャッシュを逃れます。整然と並んだグリッド配列と違って、コンテンツの高さに応じてフレキシブルに配置されるモザイク配列。見やすいかは別としてフレキシブルなのでイイ。なっからHPの「ちゃちゃっと麺作り」の部分がモザイク配列になっています。※記述中ウェブはスマホからの閲覧が増えています。ホームページはスマホにも対応しないといけないのかもしれません。そこで「なっから」サイトもレスポンシブ対応させてみました。条件はW3C準拠のブラウザのみを対象にします。i-Modeなどの古いモバイル環境には対応しません。パソコンもIEは11のみに簡易対応(表示が多少崩れても気にしない)としました。デザイン的には文字やブロックが表示枠幅によってニュルニュルーと回り込むリキッド型にすることにしました。ソリッド型はかっこいいけれどそこまで凝る程のコンテンツじゃないかなと思いパスです。トップページのみイメージ背景を使って居ますので、背景と文字サイズを表示枠幅に対してサイズを可変にしてみました。スマホでは表示サイズが小さくなりすぎてどうかなとも思いましたが、これは技術的な興味を優先しました。対応するのに苦労したのは、安直に絶対位置で配置してある所を考え直す必要があった事です。ブロックも後のことを考えずに行き当たりばったりで作成していましたので、これも改める必要がありました。それと一番厄介だっのが不用意にmargin-leftとmargin-rightを使っていたことです。padding-leftとpadding-rightも同様です。親ブロックの幅を無頓着にはみ出した部分が多々有ったからです。はみ出ていると、スマホで表示した時に画面幅にピタッとフットしません。何処がはみ出ているのかを探すのに一苦労でした。HTML文書構成で見直したこと(1).CSSなしでベタな文書として通用する章立てになるように改めた。CSSの見直したこと(2).大枠(bdoy)以外は相対幅に改めた。%指定もしくはvw指定(縦スクロールの幅を含むので非推薦)にしてみた。(3).フォントサイズはHTMLタグで1.0emとして、その配下は相対的なサイズ指定でrem指定に改めた(4).イメージも相対指定に改めた(5).表示枠幅に応じて見た目を変えたい所に@mediaでcssを指定した(6).TOPページの表示サイズ可変はcalc関数で対応してみた、ユーザービリティはピンチアウトで可読性は大丈夫。CSSなしでベタな文書として通用する章立てになるように改めた。下記の様なHTMLタグで、普通の文書としてコンテンツを書いてゆきます。この段階では文書の見た目は気にせずに章立てのみを気にして書いて行くのが吉です。ここには文書の頭書きを書きます。ここには文書の章を書きます。ここには文書の節を書きます。ここには文書の節の中の節を書きます。ここには文書中の補足などを書きます。ここには文書の脚書きを記述します。<footer>HTML5では文章の章や節を表わせるタグが登場して、HTML4以前と違い、文章としての構成をよりわかりやすく記述できます。ここはあまり肩苦しく考えすぎると手が止まりますので、ワープロのスタイルで見出した段落を整える感覚でタグを利用すれば良いのです。レスポンシブ化を阻害するのは、ワープロでいうところのスタイルを使わずに、文字属性を直接弄って整える様なHTML文書を書くと、レスポンシブ対応が困難になります。(2).大枠(bdoy)以外は相対幅に改めた。%指定もしくはvw指定にしてみた。(3).フォントサイズはHTMLタグで1.0emとして、その配下は相対的なrem指定に改めたリキッドデザインと言われている、ブラウザの表示幅を変えると、ニュルニュルと折り返される文書にするには、書く章立てを絶対値で幅をしない様にします。}上記のCSSはワープとでいうところの見出しや章立ての見え方のスタイルを指定するものです。文書だけなら、これだけで立派なリキッドデザインのレスポンシブ対応完了です。ワープロ文書をスタイルで整えていれば、余白幅を変えようが、用紙設定を縦から横に変えても、文書の見た目が崩れないのと同じ考え方です。それとhtmlタグでフォントサイズと指定しておき、その配下のタグ中のフォントサイズはrem(親要素のフォントサイズに対する相対サイズ指定)で、文字サイズのバランスを整えます。することでバランスを崩さずに、htmlタグのフォントサイズを変えるだけで、全体の文字サイズを大きくしたり、小さくしたりすることが自由自在です。(4).イメージも相対指定に改めたイメージも固定な絶対値サイズではなく、表示枠サイズに合わせて可変表示にします。background-size:contain;↖Top。