やりたいこと <input>tagを使用して検索バーを作ると、focusしたときのスマホキーボードのEnter Keyは「改行」と表示される。 検索バーの場合Enter Keyを押したときの挙動は「改行」ではなく「検索」させたいため、Enter Keyの表示も「検索」に変更したい。

DOMとはJavaScriptでhtmlの要素を操作するための仕組みのことだ。 JavaScriptを扱っていく上で、絶対に知らないといけない仕組みのひとつだろう。 このページではDOMの仕組みと使い方について初心者の方でもわかるように解説した。 DOMとは「Document Object Model」の略だ。直訳すると、「ドキュメントを物として扱うモデル」になる。プログラムからHTMLやXMLを自由に操作するための仕組みだ。 例えばブラウザに表示される文字の色を変更したり、大きくしたりと、Webページの見た目をプログラムで処理をしたい場合があるだろう、しかし何もしていない状態のHTMLファイルではJavaScriptから手を出す事が出来ない。そこでファイルの特定の部分に目印を付けて「この部分」に「こういう事をしたい」という処理を可能にするための取り決めがDOMである。 DOMは以下のよう

JSを使わずにCSSだけで、 「要素の個数に応じてスタイルを出し分ける」やり方の紹介です。 前にどこかのサイトで紹介されてたのですがブックマークなかったのでメモです。 Demo "個数に応じたスタイルの出し分け" http://codepen.io/skwbr/pen/JKbNMP 説明 個数に応じてスタイルを変える場合、下記を組み合わせて使います。 :nth-last-child 擬似クラス … 最後から数えて何番目か 間接セレクタ ~ … それ以降の後続する弟要素(同階層) <ul> <li class="item"></li> <li class="item"></li> <li class="item"></li> : </ul>

[レベル: 中級] ネイティブ Lazy-load を簡単に実装する WordPress 用のプラグインを Google が公開しました。 ネイティブ Lazy-load は JavaScript のライブラリを利用することなく loading 属性を追加するだけで、画像と iframe の遅延読み込みを可能にします。 1 か月前にリリースされた Chrome 76 でサポートされました。 設定不要、インストールするだけで WP で Lazy-load Native Lazyload プラグインの使い方は非常にシンプルです。 インストールして有効にするだけです。 設定項目はありません。 有効にすると、img タグと iframe タグに loading=”lazy” 属性をプラグインが自動的に追加します。 現状では、loading 属性をサポートするブラウザは Chrome 76（以上）だ

[レベル: 上級] Google Chrome 76 がネイティブ lazy-load をサポートするようになりました。 JavaScript のライブラリを利用することなく、ブラウザの標準機能として画像の遅延読み込みが可能になります。 ネイティブ lazy-load は開発版 Chrome (Canary) で試験運用されていました。 自動で遅延読み込み 次の動画は子猫の画像だけを掲載したデモ用ページをスクロールした様子です。 デベロッパーツールの Network パネルで見ると、スクロールに応じて画像が順に読み込まれているのがわかります。 この遅延読み込みは JavaScript で実装しているわけではなく、Chrome の標準機能として実装された lazy-load の機能で実現しています。 loading 属性でネイティブ lazy-load ネイティブ lazy-load を利用

↓↓↓最新の2021年版を作成しましたのでこちらもご覧ください。↓↓↓ hashimotosan.hatenablog.jp PDFはこちらからどうぞ[508KB] 2019年Pixel 3aやGalaxy S10など一通り新機種が発表されたので、2019年改めてブレイクポイントについて考えてみました（3年ぶり！）。 3年経ってほとんどのサイトがレスポンシブデザインになって、ブレイクポイントを少なく効率よく設定していく方向になっているのだと思います 前回、ブレイクポイントの設定はフレイムワークも参考に考えていましたが、 改めて考えてみると、モバイルファーストの観点からも640px/1024pxではないのではないかと感じました。 以下が3年前の前回の記事です。 いくつかブレイクポイントを調べましたが、 だいたい以下のような分け方が多かったです。 640px/1024px 480px/896x

[レベル: 上級] WordPress サイトを AMP 対応する公式プラグインのバージョン 1.0 安定版が正式公開されました。 AMP プラグインのディレクトリからダウンロードできます。 統一されたデザインと機能を AMP で実現 v1.0 の大きな特徴の 1 つは統一されたデザインと機能を AMP ページで実現できる点です。 v1.0 以前のプラグインは、AMP ページのデザインが変わってしまい通常のモバイルページと比べるとかなり簡素に変換されてしまっていました。 しかし、v.1.0 では、AMP ページの外観および機能は通常のモバイルページとなんら変わりありません。 最新の AMP プラグインには 3 つのモードがあります。 Native Mode（ネイティブ モード）: サイトを完全に AMP 化する。すべてのページが AMP になり、通常の PC ページやモバイルページはなくな

[レベル: 中級] 昨日とおとといに続いて、今日も Chrome Dev Summit 2018 のセッションレポートをお届けします。 セッションのタイトルは “Speed Essentials: Key Techniques for Fast Websites” です。 昨日レポートしたセッションと同じようにモバイルウェブの高速化がテーマです。 しかし、こちらはより実践的な内容になっています。 パフォーマンス改善に非常に役立つテクニックが満載です。 パフォーマンス改善の優先対象は画像とJS、フォントの3つ モバイルウェブで 1 ページあたりデータ量が多いリソースは次の順番（HTTP Archive 調べ） 画像 (約 500 KB) JavaScript (約 380 KB) フォント (約 80 KB) この 3 つは Performance Budget（パフォーマンス バジェット）

[レベル: 上級] SEO と相性がいい Lazyload の実装を解説するドキュメントを Google はデベロッパー向けサイトで公開しました。 3つのアドバイス ドキュメントには3つの指針が書かれています。 1. viewport 内で見えるようにする viewport 内にあるコンテンツは、必ず Google にも見えるようにしておきます（viewport は簡単に言えば、スクリーンに表示される領域）。 つまり、重要なコンテンツが viewport に入ったときは確実に読み込ませます。 IntersectionObserver API と polyfill を実装するように Google は指示しています。 2. 無限スクロールでは paginated loading を使う 無限スクロールを採用している場合は、paginated loading を実装します。 paginated

いかがでしょう？　WEBブラウザにもよりますが、結構実際の見た目も違うように思います。 で、冒頭の「半角スペースと &nbsp;」の件ですが、ちゃんと意識しておかないと「あれ？」と思うことがあります。 「&nbsp; を半角スペース (0x20) に置き換える」プログラムがあるように、「&nbsp; を半角スペースに置き換えず、nbsp (0xC2A0) に置き換える」プログラムもありますから、WEB ブラウザのように 0xC2A0 を表示できる場合はいいですけど、表示できないプログラムだと困りますよね。 冒頭の画像は、わが愛するテキステエディタ Emacs だとこんな感じになります、というサンプルでした おまけとして、&nbsp; を 0xC2A0 に置き換える例を。雰囲気をお楽しみください。 use HTML::Entities; use Encode; use Data::Dumpe

「最近Qiitaを検索結果でよく見るようになったなぁ」と感じる人はいませんか？ SEOを頑張ってるWebサービスは数多存在しますが、Qiitaもその中の1つです。 SEOっていうとやれキーワードがどうだこうだ、サイト内リンクがどうだこうだ、という話になってしまいがちですが（そういうのが不要と言っているわけではないですよ）、今回はQiitaがSEOの一環として行なっている数多の取り組みの中で、比較的Web上での言及数の少ない印象のある、HTMLのマークアップについて、外に出せる範囲で、前編と後編に分けて解説したいと思います。 後編はこちら 免責事項的な SEOというのは完全に結果論でしか語ることのできないものです。また時と共に効果的とされるテクニックは変わっていきます。この記事はQiitaの中の人が「効果あるんちゃうか」と試行錯誤しながらあれこれ行なっていることの一部を紹介するものであって、

メールコーディングをする上で重要なポイント <table>タグを組むときにcolspanやrowspanを使わないように組み立てる 半角スペースは極力削る(Gmailは文字数やファイルサイズが大きいと制限で切られてしまうため、なるべく無駄な空白は削ったほうが良い) 画像のパス指定は 'http://' から記述 スタイルはインラインに記述、レスポンシブ対応はヘッダのCSSに記述する Outlook対策 画像のサイズは必ずwidth="size" height="size"を指定する(これを書かないと、元の画像サイズで表示されてしまう。どちらかをautoにしたい時は、width="300" height="*"と書く。 pxは書かない 、 *はauto という意味になる。) 今回の記事で実機確認しているのは、以下の通り。 Mac Mail Gmail(Chrome/FF) Inbox(Chr

Googleは、schema.org（スキーマ）のサポートを去年から開始しています。そして、GoogleはData-Vocabulary.orgの開発を終了していることから、すでに構造化データをschema.orgで記述しているサイトも多いのではないでしょうか？schema.orgを導入するメリットとしては、Google、Yahoo、Bingの3社が共同で取り組んでいることが挙げられると思います。それによって、それぞれの検索エンジンにサポートされ、検索結果に表示されるスニペットを装飾することができます。（リッチスニペット）ということで、これから構造化データを導入する場... パンくずリストを設置する理由 まず、パンくずリストを設置する目的とその理由についてご説明します。 それは大きく分けて、ユーザビリティとクローラビリティの二つから考えられます。 では、ひとつずつご説明します。 ユーザビリ

[レベル: 中級] Google検索でリッチスニペットを表示させるための構造化データとして、旧式の data-vocabulary.org を今でも利用することができます。 しかし、現在Googleが公開している仕様としての schema.org を利用することが推奨されます。 schema.org 対 data-vocabulary.org GoogleのJohn Mueller（ジョン・ミューラー）氏がTwitterでフォロワーから schema.org と data-vocabulary.org の利用について質問を受け、それに対してアドバイスしています。 @Ck_eMrkg I'd use the markup as in our docs: https://t.co/IUvzMZGv2W — John Mueller (@JohnMu) 2016年4月13日 @Ck_eMrkg

[レベル: 上級] サイトリンク検索ボックス向けの schema.org を用いた構造化データをマークアップすると、検索結果に自サイトのサイト内検索システムで実行できる検索ボックスを表示することができます。 このサイトリンク検索ボックス用の構造化データマークアップは、Google の検索結果にサイトリンク検索ボックスがすでに表示されているサイトに対してのみ機能します。 検索結果にサイトリンク検索ボックスが表示されていないサイトでマークアップしても、サイトリンク検索ボックスを表示するように Google に指示を出すことにはなりません。 サイトリンク検索ボックスのマークアップはどちらのバージョンを選ぶかの指示 Google の John Mueller（ジョン・ミューラー）は、サイトリンク検索ボックスのための構造化マークアップについて次のように説明しました。 サイトリンク検索ボックスに関して

って海の向こうの人が言ってました。 私はjQueryさえあれば概ね生きていけるので全然知らないけど、 あなたは全部知ってるフロントエンドエンジニアなんだね。すごーい！ 以下はFront-End Developer Handbook 2017の第三部、Front-end Developer Toolsからリンクされているツールと、その簡単な紹介です。 ドキュメントツール Dash 150以上のライブラリのAPIリファレンスを検索できる。有料、Mac専用。 DevDocs 200以上のライブラリをオンラインで検索できる。無料。 Velocity 中身はDashと同じ。 有料、Windows専用。 Zeal 200以上略 無料のオフラインドキュメント。 SEOツール Keyword Tool 検索ワードを入れると関連キーワードを教えてくれる。 Google Webmasters Search C

ここ数年でフロントエンドエンジニアという言葉を聞くことが多くなったと感じますが、フロントエンドエンジニアの定義は会社によって異なるものです。 ただ多くの場合、「JavaScriptやHTML5/CSS3、PHPといったプログラム言語など、高度なWeb制作スキルを持った人」を指しており、それらのスキルを活かしてWebサイトを構築する仕事内容がほとんどです。（アプリ制作会社の場合アプリ開発のフロントエンド部分を担当するエンジニアを指すこともあります。） 当コラムではフロントエンドエンジニアとは「Web制作においてHTML/CSSはもとより、それに関連するJavaScriptや各種API、WebGLやキャンバスなどWebサイトを表示するうえで必要となるさまざまな技術・知識を持ち、それらを取捨選択できる人」と定義します。 そのうえで、フロントエンドエンジニアとしてWeb制作の現場で働く際に必要とな

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