投稿

ラベル(JavaScript)が付いた投稿を表示しています

【解決済み】bubbly-bg.jsというJavaScriptのIE11対応。

bubbly-bg.jsという、ちょっとおもしろいJavaScriptがあります。 ページの背景にランダムで動く水玉模様を簡単に作れるというものです。 https://tipsy.github.io/bubbly-bg/ jsファイルを読み込んで実行するだけ、という簡単なもの。 実行は「<script>bubbly();</script>」と記述するだけで、基本のブルー背景の水玉が表示されます。 しかもこれ、色とか変えられるんですよね。 例えばこんな書き方になります bubbly ( { colorStart : "#111" , colorStop : "#422" , bubbleFunc : ( ) => `hsla(0, 100%, 50%, ${ Math . random ( ) * 0.25 } )` } ) ; 背景が黒から赤、赤い水玉が出るようになります。 問題はここから。 この指定をすると、IE11で動きません。 ■IE11で動かない原因 2点ありますが、いずれも上記スクリプトの4行目。 この4行目の書き方が、IE11で対応していないバージョンのJavaScriptの記述法になっていて、これを書き直すだけで対応できます。 ■修正版 bubbly ( { colorStart : "#111" , colorStop : "#422" , bubbleFunc : function(){ return "hsla(0, 100%, 50%, " + Math.random() * 0.25 +")" } } ) ; これだけ。 要するに、bubbly-bg.js自体はIE11でも動作するのですが、色変更を行う場合のサンプルとして挙げられているスクリプトが対応していないだけというわけです。 あとはカラーコードの部分や倍率(上記の0.25のところ)を変えてあげると、いろいろな効果が楽しめます。

【解決】MixItUp.jsで要素を絞り込んだときのアニメーションがおかしい

要素をタイルで並べておいて、フィルタをかけたりソートしたりできる、便利なjQueryプラグイン「MixItUp.js」。 これを使ったところ、アニメーションがおかしくなるという現象が起こりました。 発生するのはこんな感じ。 1.フィルタを設定してあるボタンをクリック 2.条件に応じて要素の表示が切り替わり、移動のアニメーション開始 3.一度移動が終了 4.要素が再びおかしな位置にワープし、アニメーションがもう一度発生 要するに、ちらつくといいますか、一回終わったのにまたパパっと2回目のアニーションが始まってしまうのですね。 で、これ、原因は簡単でして、CSSのtransitionが指定してあると発生します。 transitionはCSSの設定が変わったときに、一瞬で切り替わるのではなく、アニメーションしながら切り替わるようにする設定です。 MixItUpの場合は、移動はjQueryで制御しているのに、CSSのtransitionも入っていると両方が動作してしまうということですね。 transitionを設定するときはめんどくさいのでallとしてしまうことが多いと思いますが、jQueryのアニメーションと競合しがちなので最低限の要素に設定したほうが安全です。 また、もちろん不要なら削除しましょう。

Firefoxで、別ページから飛んできたアンカーリンクの位置がずれる問題の対策

Firefoxでアンカー付きで別のページに移動したときに、ページが正しくない位置にスクロールするという現象が発生しました。 A.htmlページ内のリンクで、「href="B.html#anc1"」などとなっていて、クリックすると、B.htmlのanc1の箇所が表示されないということです。 この現象、ググってみると、同じような症状の報告が結構古くから有るようです。 Firefoxに以前から存在する問題なのかも。 ただし、古くから報告されている問題が、現在発生している問題と同じものかどうかは分かりません。 現象が同じでも原因が違うことは考えられます。 当然もともと発生しない場合もあるし、「こうするとなおる(かも)よ」というアドバイスはいろいろ出てきます。 しかし、いくつかの方法を試しても今回僕が遭遇した現象は解消しなかったのと、いちいち原因を考えるのもしちめんどくさえので、一気に解決できるJavaScriptを組んでみました。 ■■==スクリプトここから  window.onpageshow = function(){   //ページのURLからアンカー部分を取得   var myhash = $(location).attr('hash');   if ( myhash.length > 1 ) { //アンカーがあった場合     if($(myhash).length){ //アンカーに対応するidの要素があった場合       var nScrolltop = $(window).scrollTop();       var nOffset = $(myhash).offset().top;       //現在のスクロール位置とアンカーに対応するidのY座標(本来有るべき位置)を取得       if( Math.abs(nScrolltop-nOffset) > 5 ) { //2つの位置の差が5以下の場合   ...

よく分からないけど、JavaScriptがIE7でうまく動かない場合

他のブラウザ(IE8以降、FireFox、Chrome、Opera等)でOKなのに、IE7でJavaScriptが期待通りの動作をしない場合のチェック点。 連想配列で、各要素の区切りに入れるカンマを、最後にも入れてしまう。 これ、よくやっちゃうんだよな。。。 ■■■■例 (OKな書き方) var test_array = new Array(); test_array = {   val1 : 1,   val2 : 2,   val3 : 3 } (NGな書き方) var test_array = new Array(); test_array = {   val1 : 1,   val2 : 2,   val3 : 3, } どこが違うって、「val3 : 3」の後のカンマの有無です。 これ、書式的には最後には入れないのが正しいと思うのですが、なぜか大方のブラウザではNG例でも問題なく動作してしまう。 ところがIE7ではこれが厳密なんですね。 (たしかIE6も。最近IE6は動作対象にしてないので忘れた) IE7はNG例だと、「val3 : 3,」のところでエラーが発生し、以降のスクリプトがキャンセルされます。 これは、IE10でも、歯車をクリックして開発ツールを使い、動作モードをIE7にすれば確認できます。 またスクリプトのデバッグモードを使えば、この箇所でエラーが出ているとはっきり分かります。 でもねー、なかなかここに気づかないんですよ。(いや、気づけよ。。。) 以降のスクリプトが全て無視されるというのがミソで、例えば タグをクリックした時の動作のなかでこのエラーがあったとする。 その後ろには のhrefを無視するために「return false;」を書いていたとする。 NG例だと「return false」が実行されないため、hrefで指定されたページへ移動するような動きをしてしまうわけです。 この時点で、IE7での「return false」の使用に問題があるのではないかと、見当違いなところを疑ってしまったりしてね。 (実際、IE7でreturn falseが効かないという現象もあるようですが) まぁ、まずはきちっ...

画面サイズ(縦幅)に合わせてサイズ変更するコンテンツ

画面の縦幅(天地)サイズによって、各要素の大きさや位置を調整したい場合があります。 これ、いろいろやり方はあるのでしょうが、僕はjQueryの「$(window).height()」で画面サイズを取得して、それに併せて各要素の位置やサイズを計算で設定するようにしています。 この場合、ページ読み込み時に調整用の処理を実行するのはもちろんですが、ウインドウサイズが変更された場合も再調整する必要があります。 「$(window).bind("resize", 関数名);」としてリサイズ時の対応をしていたのですが、これだとiPhone/iPadの縦横向き変更時のイベントがとれていないことが発覚。 iPhone/iPadの向き変更のイベントは「$(window).bind("orientationchange",関数名);」とするようです。 処理が同じなら「$(window).bind("load orientationchange resize ",関数名);」で、読み込み時も含めてOKかと。

半透明のPNGをjQueryでfadeしたとき、IE7・IE8で問題

半透明の部分があるPNG画像にたいして、jQueryでfadeIn・fadeOutを行ったり、animateでopacityを設定すると、半透明部分がべた塗りで(濃く)見えてしまいます。 この現象はIE7・IE8で発生するようです。 (IE6は透過PNG未対応として検証対象外) 何通りかやり方を試してみましたが、元々半透明の部分がある場合、jQueryで透明度が変わるような処理を行うとどうしても問題が発生してしまうことが避けられませんでした。 完全に透明な部分と完全に不透明な部分は問題有りません。 結局これについてはデザイン側で妥協して、半透明の処理をやめました。 IEでも9以降では大丈夫ですし、今後は減ってくる問題でしょうが、今のところIE8はまだ切れない感じなので致し方ないですね。

jQueryプラグイン「jscrollpane.js」がchromeでうまく動かない。

jQueryのプラグインで、divのスクロールバーのデザインを変更できるjscrollpane.js、基本的に簡単端で便利なんですが、うまく動かない現象が発生しました。 【Google Chromeで確認された現象 】 jscrollpaneを組み込んだページを表示したときはスクロールバーがきちんと表示されるのに、リロード(更新)するとスクロールバーが出なくなる。 Chromeの他にもwebkit系のブラウザでは発生するようです。 スクロールバーが出なくなってしまうので、コンテンツが途中で切れてしまい、みられなくなります。 発生条件はやや不安定、というか起こるときと起こらないときがあるようで最初混乱しましたが、リロードすると発生するというのはほぼ確実なようです。 【原因】 スクロールさせようと思ったdivの中身がimgのみで、高さを指定していなかったことが原因でした。 jscrollpaneを「$(function(){});」の中で実行しようとしていたのですが、この「$(function(){});」を使うとChromeでは画像の高さを取得できない(ゼロになる)ようなのですね。  「$(function(){});」 はDOMの構築が終わったときに実行されると言うことで、IEやOperaでは高さを明示していないimgの高さも取得できるのですが、Chromeではダメなようです。(バグじゃ無い?これ) 【対処法】 imgの高さを明示的に指定する方法もあると思いますが、後で変更になったときに面倒かもしれません。 なので、JavaScript側で対処しました。 具体的には実行のタイミングを変えます。 つまり、 「$(function(){});」で呼び出すのではなく、window.onloadのタイミングで呼び出すようにします。 ただまぁ、状況によってwindow.onloadが使えるかどうか分からないので、jQueryからonloadにセットする方法をとりました。 こんな感じです。 $.event.add(window,"load",function(){   $('.scroll-pane').jScrollPane(); }); ※2行目は状況によって変える。 い...

「Google Maps JavaScript API v3」で、マウスオーバー時にマーカー画像(アイコン)を変える。(hoverのような処理)

google mapsで地図上に表示されているマーカーを、マウスオーバー時に変えたい場合の方法です。 意外にこれが、マーカー マウスオーバーとかで検索しても出てこなかったんだなぁ。 マーカーを作るときは例えばこんな感じですよね。([LatLngオブジェクト]のように記載しているところは、その種類のオブジェクトを渡す、という意味です。) myMarker = new google.maps.Marker({   positon: [LatLngオブジェクト],   map:[マーカーを表示する地図],   icon:[MarkerImageオブジェクト] }); 上記では最初にマーカーを作るときに「icon」のところで、カスタムの画像を設定するわけです。(画像のURL、サイズ、中心点など) ここまでは基本で、次にマウスオーバー、マウスアウトの動作を設定します。 setIconというメソッドを使用します。 例えば、 google.maps.event.addListener(myMarker, 'mouseover', function(){   myMarker.setIcon([画像のURLもしくはMarkerImageオブジェクト]) )}; マーカーにイベントのリスナー(マーカーに対してイベントが起こったことを伝えるもの)を設定し、mouseoverイベントを取得します。 その後、setIconを実行して、画像を差し替えるわけです。 setIconの引数は画像のURLだけの場合、中心点が画像の下の真ん中になるようです。この辺をカスタマイズしたい場合はMarkerImageできちんと諸々の設定を渡してあげる必要があるようです。 ということで、マウスオーバー時のマーカー画像の差し替えについて、でした。 CSSとかjQueryならhoverだけですぐにできちゃったりすることなのに、google mapsはヤヤ面倒ですねぇ。

javascriptのdocument.write()がうまく動かない

最近ではあまりdocument.write()なんて使わなくなりましたね。 jQueryを使っているならappend()で後から置き換えるという方が普通でしょうし。 でも、この間書いていたスクリプトで、とある事情からdocument.write()を使わなくてはいけなくて、後から考えれば馬鹿な間違いなのですが、ちょっとやっちまったのでメモ。 (そもそも、document.write()以外の方法もあったかもしれないけど、その辺は置いといて) jQueryで$(function(){});の中に命令をいろいろ書いていたのですが、その中にdocument.write()を追加したとたん、動きがおかしくなった。document.write()で書き出したもの以外がすべて消えてしまうんですね。 ブラウザごとに挙動は違うかもしれませんが、原因は一緒。 $(function(){});の本来の意味を考えればすぐ分かる話な訳で。 $(function(){});は、その中に書かれた命令文を、ページの読み込み終わった段階で実行します。DOMが操作可能になった段階ですね。 つまり、ページがもうできあがってからスクリプトが走ると言うことです。 これは重要なことで、スクリプトが操作したいDOM要素が読み込まれる前に(準備ができる前に)操作を開始しようとすると、「オブジェクトがない(undefined)」のエラーが出てしまいます。 jQueryでは、ページに対して後から動的に操作する場合が多いと思いますので、 $(function(){});の中に書くわけですね。 これをもう、ほとんど無意識にやっていたもんで、ちょっとポカをやったわけです。 document.write()は、引数で指定された文字列をHTML内に書き出す命令ですが、ページ自体ができあがった状態になった後に書き出そうとしたらダメに決まってます。 ページを作る途中に、必要なタイミングで書き出しをしていかないと行けないですよね。 そんなわけで、document.write()した以外のものがすべて消えるという現象は、ページ読み込みが終わった後に別の文字列を書き出したことにより、それまでのものが全部消えたということだと思います。 jQueryとdocument.write()が併用でき...

window.openがIEでうまく動かない。

window.openをしたとき、IEで真っ白いウインドウが開いたりすることがあります。ポップアップに中身が表示されません。 ブラウザのURL欄には、スクリプト(window.openだったりカスタムのfunctionだったり)が表示されます。 意図としてはwindow.openで指定したURLのページを開いて欲しいのですが、そうなりません。 原因として考えられるのは、window.openを指定してあるリンクに「target="_blank"」が指定されていること。別ウインドウを開くという点で同種の目的に使うものですから、制作途中でtargetを入れていて、javascriptに変更したときに抜き忘れると言うことがあるようです。 要するにIEでは、同じリンクにwindow.openとtarget="_blank"が同時に設定されているとおかしくなりますので要注意です。

WYSWIGエディタを作りたい。

最近、よくあるWYSWIGエディタの簡易版を作りたいと思って調べてみました。 フォームなんだけど、文字の装飾もできるというやつですね。 もちろんJavaScriptを使います。 で、キモはcontenteditableですね。 集めてみた情報をメモっときます。 Web上で直接編集できる文字や画像 contenteditable (直接編集) の傾向と対策 簡易WYSIWYGエディタを作る 簡単にいうと、 iframe等を作ってcontenteditableをtrueにする ↓ submitの時に、編集後のソースをtextareaにコピーしてから送る それだけ。 あとはcontenteditableのブラウザ毎の実装の違いとか、 HTMLタグを動的に挿入する(文字の装飾をする機能)を付けていけばいいと言うことになりますね。 意外と簡単にできておもしろい。

.css、.jsなどの外部ファイルが正常に読み込まれないとき

パスもちゃんと設定しているはずの外部ファイルが、正しく読み込まれない(適用されない)場合があります。 私がたまにはまる原因は単純ですが、文字コードが違う、というもの。 別ファイルだとたまにやってしまいます。 当たり前のことですが、読み込むHTMLと読み込まれるCSS、JavaScriptの文字コードはあわせなくてはいけません。 さらに、先日起きた現象。 Safari4、iPhoneOS3のSafariで、CSSが無効になると言うもの。 調べてみたら、外部CSSの最初に入れるべき文字コードの宣言が2行目になされており、文字コード宣言の前に日本語のコメントが入っていたことが原因でした。 これも当たり前と言えば当たり前のことですが、文字コードの宣言はできるだけ上に入れるものです。 ファイル自体のエンコードが正しかったせいか、Safari5を含め、ほとんどのブラウザで正しく表示されていたため、最後の最後まで見落としてしまいました。 社員の一人がアップデートしていないiPadでサイトを見たことで気づくことができたという。。。 無精もたまには役に立ちます。(笑) 文字コードは目に見えないので、注意が必要ですね。 --