Chrome拡張を長年造ってきたなかで 手法や自作ライブラリが充実してきたのでこの辺で公開します。 Chrome拡張は本当に効果的に改善できて、すばらしい仕組みです。 これで皆さんが簡単に現場改善が進んだら嬉しい限りです。 (なお、これは 2017-08-05 Builderscon Tokyo 2017 でのトーク用に作成した資料です) わりと ウケた 改善 どんなことができるのか、ざっと見てみましょう。 サンプルページ ※各項目ごと、「拡張を有効化」をクリックすることで拡張が入った状態を見ることができます。 Chrome拡張を作るのに必要な 環境 必要な環境はシンプルです。 Google Chrome Text Editor or IDE(UTF-8 が扱えるなら何でもいい) （公開するなら）Zip 圧縮ができるソフトウェア （公開するなら）クレジットカード これだけ。 あとは、ソース

@ymmt2005 こと山本泰宇です。 今回は cybozu.com を安全に利用するために暗号化した通信（SSL）を常時使用するための取り組みを紹介します。 HTTP と HTTPS HSTS とその弱点 Preloaded HSTS Chrome のリストに cybozu.com を組み込む まとめ HTTP と HTTPS Web ブラウザのアドレスバーに "www.cybozu.com" と打ち込むと、通常は暗号化されない HTTP 通信が行われます。そこでまず考えられるのは、Web サーバーにて HTTP 通信を受け付けたら、HTTPS に永続的リダイレクトをすることです。Apache なら以下のような設定になるでしょう。 <VirtualHost *:80> ServerName www.cybozu.com Redirect permanent / https://www.c

HTML の a 要素に target 属性をつけて、リンク先の文書をどこで開くのかを指定できますね。 デフォルトは _self で、元のドキュメントと同じフレーム。無指定だとこれになるので、わざわざこれを書くことは少ないと思うけど。 一番よく使うのは target="_blank" じゃないでしょうか。リンク先のドキュメントを新しいタブやウィンドウで開くやつですね。 これ、以前はよくつかってました。ルールとして サイト内リンクは target 指定なし 外部サイトへのリンクは target="_blank" というのが多かったんじゃないかな。 でも最近、これはもうリンク先がどこであろうと指定しない方がいいんじゃないか、と思ってます。 もちろんサイトによってそれぞれ使いわけはあると思うんだけど、少なくともほとんどの手元のサイトの場合はいらない。 target="_blank" を使ってきた

[レベル: 上級] HTTPSで通信していない非セキュアなサイトに対して、そのページは安全ではないと警告を表示する仕様をChromeブラウザに実装することをGoogleは提案していました。 開発版として提供しているGoogle Chrome Canaryの最新バージョンにこの機能が実装されました。 設定変更が必要 HTTPSで通信していない非セキュアなページであっても、デフォルトでは警告は出ません。 設定変更が必要です。 そのまま状態だと、僕たちが使っている通常のChrome（や一般的なブラウザ）と同じように振る舞います。 つまりHTTPSページに対してだけ安全であるマークを付けます（たいていはアドレスバーの鍵マーク）。 HTTPページには、何かを示すマークを特に表示しません。 設定を変更するにはChromeのアドレスバーで次のコマンドを入力します。 chrome://flags/#mar

注 : このドキュメントは暫定版であり、変更される場合があります。 ドキュメントの互換性は、Web 開発者にとっての重要な考慮事項です。Windows Internet Explorer 8 には、ドキュメント互換モードが用意されており、Web 開発者はブラウザが古いバージョンと同じ方法でページをレンダリングするように指定できます。これにより、開発者は更新の時期を調整することができます。 このドキュメントでは、Windows Internet Explorer 8 でサポートされるドキュメント互換モードについて説明し、カスタム ヘッダーを使用してそれらのモードをページごとまたはサイトごとに実装する方法を解説します。適切な互換モードを実装することにより、サイトでは Windows Internet Explorer 8 およびそれ以降のバージョンとの互換性を確保できます。 各種の互換モード

[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう こんにちは、@yoheiMuneです。 ブラウザのレンダリングの仕組みはHTML5 RocksやHow browsers workで詳しく解説されてきました。しかしそれらはとても詳細で、読破して理解するのは大変です。 今回のブログでは手軽にレンダリングの概要を理解できるように心がけました。またより詳しく学べるようなリンクも記載しました。 そしてブラウザのレンダリングの仕組みを理解した上で、どのようなJavaScriptを書くべきかについても記載しました。 目次 ブラウザのレンダリングの仕組み この章では、HTMLとCSSが読み込まれてから画面に表示されるまでの間に、ブラウザがどのような処理を行っているかを説明します。 ファイル読み込みから表示までの一連の流れは以下図の通りです。 [1]

2022年9月27日 クリーク･アンド･リバー社でのUXデザイン基礎セミナー第4回 「プロトタイピングとユーザビリティテストで「UXデザイン」を練りあげよう！ | UXデザイン基礎セミナー 第4回」のスライドです。ユーザビリティテストとプロトタイピングの手順をていねいに解説するとともに、じっさいに2名のユーザーを会場にお招きし、公開でユーザビテリィテストをします。 公開ユーザビリティテストの題材として、英会話アプリ 「Langaku（ランガク） https://langaku.app/ 」 を運営するMantra株式会社さまのご協力をいただきました。 【著作権表示】 ・本Figma/FigJamのデータは英会話アプリ「Langaku」のユーザビリティテストのために作成したものです。英会話アプリ「Langaku」の画面の著作権はMantra株式会社に帰属します。 ・本Figma/FigJam

[対象: 上級] この記事では、「DNSプリフェッチ」という仕組みを利用してウェブページの表示速度を高速化する方法を解説します。 DNSプリフェッチとは 上級者向けの記事なのでDNSが何かの説明は省きます。 DNSプリフェッチを利用すると、外部ドメイン名（ホスト名）の名前解決（DNSルックアップ）を事前に強制できます。 ユーザー（ブラウザ）がそのドメインにアクセスする前にすでに名前解決が完了しているので、読み込み時間の短縮を図ることができるのです。 DNSの名前解決にかかる時間は平均して200ミリ秒とわずかですが、モバイル回線では無視できる長さではないかもしれません。 またときとして1秒以上かかることもあり、遅延による表示速度の低下の防止に役立てられます。 DNSプリフェッチは、ページの読み込みと同時に実行されまたCPUやネットワークへの負荷が低いため、そのほかの処理を遅らせてしまう心配も

スマホ用のブラウザ判別を行うための「 jquery.browser.sp.js 」 普段スマホ用のブラウザ判別を行うために利用しているjQueyプラグインを公開したのでご紹介します・ ダウンロード / GitHub 利用方法 jQuery本体を読み込んだ後にダウンロードしたjquery.browser.sp.jsを読み込みます。 <script src="jquery.js"></script> <script src="jquery.browser.sp.js"></script> そうすると以下の様な$.browserオブジェクトが利用できるようになります。

By penulis • January 10, 2023 • comments off Sebelum langsung ke poin utama yaitu mengenai trik rahasia main togel online yang beneran udah terbukti gacor buat hasilkan kemenangan, kalian yang mungkin masih berstatus pemula di game…