はてなブックマーク

まえがき先日新しいiOSであるiOS15が発表されました。その中でもSafariのアドレスバーの仕様が大きく変更されたことがWeb制作関係の間で話題になりました。 というのもその仕様が変更が、以前までは上部にあったアドレスバーが下部に移動し、かつフロートするというものだったからです。 ※画像はこのページをキャプチャしたものです。 下部にUIを集めたWebサイトはどうなってしまうのか、、心配してしまった方も多いかと思います。自分もその一人です。 というわけで、iOS15のPublic betaをインストールして検証してみました。 この検証結果はあくまでPublic beta版の検証結果であり、実際のリリース時にはどうなっているかはわかりません。追って検証する予定です。 TL;DRTwitterですでに検証結果を載せています (誤字脱字ご容赦ください)。今回の記事はその検証をまとめ直したもので

three.jsを使用したプロジェクトのファイルサイズを できるだけ小さくしたい three.jsは大変便利なWebGLのフレームワークですが、その他機能差ゆえ、minifyされたthree.min.jsですら600KBを超える大きなフレームワークです。 Webサイトで使用することを考えると、読み込むファイルのファイルサイズが大きいほどページが表示されるまでに時間がかかってしまいます。 とりわけモバイルデバイスでネットワークの状況がいまいち不安定だったりすると、ローディングを待っている間に離脱される可能性もあります。 つまりファイルサイズは小さければ小さいほど良いので、three.jsも使用する機能に絞ってできるだけファイルサイズを小さくしたいですね。 一番簡単な方法: カスタムビルドthree.jsはGitHub上にソースコードと、three.jsをビルドするための環境が置いてあります。

2020.03.13 更新 以下gulpをやめて、自作のタスクランナー的なものを作った話です。結構長いです。 まず最初にリポジトリへのリンクを載せておきます。 そもそもなぜずっとgulpを使っていたかNuxtやcreate react appのようにモダンな環境がある中でそういうものが使えないプロジェクトが多々あるので、割とどんなプロジェクトにも対応できるような汎用的な環境をつくってずっと運用していました。 具体的には以下のような構成です。(一部機能省略) ・ソースディレクトリからgulpのタスクを通して公開ディレクトリに展開 ・cleanタスクで公開ディレクトリ内のファイルを消去 ・htmlは単純に公開ディレクトリにコピー ・pugはコンパイルして展開 ・cssはautoprefixer、minify (options)して展開 ・sass/scssはコンパイル → autoprefix

もうすでにリニューアルされてしまっていますが、水曜日のカンパネラのオフィシャルサイトの背景にこの表現を使用していました。 当時、デザイナーさんに「こういうのやりたい」と参考サイトを見せられて、「できますよ」と言ってみたはいいものの、WebGLにあまり慣れてなかった自分には実装難易度が高く、心を折られかけた表現です。 いろいろ調べていると、この表現は「stable fluids」である、ということを知りました。 ちょっと前にホムンクルスの荒井さんがおしゃれなコンテンツを実装していたり(Chrome Experimentsに掲載！！)

スマートフォン用サイトを制作するデザイナーさんに伝えたいWebブラウザのViewport(表示領域)の話。エンジニアにも役立つかも。 Part2 今回は ・少し厄介なランドスケープ時のViewportの高さの話 ・かゆいところに手が届きそうで届かないCSSのvw/vhの話 ・これまた厄介なアプリ内ブラウザ (WebView)でのvhの話 の三本立てでお送りしたいと思います。 ・・・ 少し厄介なランドスケープ時のViewportの高さの話Webコンテンツ閲覧中に、スマートフォンを横向きで使うシチュエーションって個人的にはそんなにないですが、全画面 (html, bodyのwidth, heightが100%)のコンテンツだったり、キービジュアルをViewportに合わせた大きさにする、といったようなコンテンツではランドスケープ時の挙動に注意が必要です。 Android Chromeの場合 A

基本的には実装側で見え方に破綻がないようにしますが、実機でみたときにデザイナーさんは自分でデザインしたものとは少なからず違うものがあがってくるはずなので、違和感を感じることはないのかなと、疑問に思いました。 結局はデザイナーさんと実装者との間で、あらゆる画面サイズにどのように対応するかのルールがしっかり共有できればいいですが、口頭や文字だけだったりすると、なかなかわかりにくかったりするものです。 なので、デザインデータに入れてもらったほうが、実機に近い形での見え方がイメージできるのでデザイナーさんもエンジニアも幸せになれるのでは、と思いました。 スマートフォンの画面サイズはさまざまですが、基本的にはiPhoneを基準につくるデザイナーさんが多いかと思うので、少なくとも多くのユーザを占めるiPhoneの見え方は担保できるかな、という感じです。 まぁそんなデザイナーさんの手助けになればと思いま