中身のない空の div 要素や空の span 要素は HTML 仕様として妥当なのか？ - dskd
公開日2021-09-06タグHTMLレイアウトや装飾目的で、中身のない div 要素や span 要素、いわゆる「空 div」「空 span」を作ることはままある。しかしそれは仕様として妥当なのだろうか？ 目次 レイアウト目的の空 div の例 装飾目的の空 span の例 HTML にレイアウト目的や装飾目的のための要素はない div と span の仕様から探る フローコンテンツ フレージングコンテンツ コンテンツモデルにおける text "nothing" コンテンツモデル ol, ul, menu 要素 パルパブルコンテンツ カスタムエレメント トランスペアレント ここまでのあらすじ 僕の結論 レイアウト目的の空 div の例 下記は使う場所に応じて幅や高さを任意に設定できる例だ。.Spacer が空 div になっている。 <div class="Hero">...</div>
脱・Atomic Design - HTML+CSSコーディングの粒度分類法（HTML Parts） - Qiita
はじめに HTML+CSSコーディング専用の粒度分類を紹介します。 この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。 世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト… といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。 粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。 ※この記事は標準化ノウハウ公開の一環とし
新しいHTMLタグportal、Portals機能で変わるWebの遷移体験！ CDS2019で紹介されたヤフーの実装例 #UIUX
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。PayPayモールのエンジニア関と、Yahoo!ニュースのデザイナー萩野です。 皆様、突然ですがPortalsをご存じでしょうか。 Portalsとは、新しいHTML要素です。2019年11月11日〜12日にサンフランシスコで開催された「Chrome Dev Summit 2019」（以下CDS）でも紹介されました。 本記事では、Portalsが可能にする新しいWebでの体験をご紹介します。 Portalsとは？ なにができるの？ Webブラウザー上でユーザーにとって良い体験を提供するためには、表示速度の向上が欠かせません。 Portalsを利用すると、画面遷移の体感速度を向上させることが可能です。 まずはこちらの比較
HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
クライアントサイドからサーバサイドまで破壊するテンプレートエンジンを利用した攻撃と対策
ユーザー入力として受け取ったテンプレートをコンパイル テンプレートレベルがProgramming Language Templateは安全にコンパイルするのが難しい 高度なテンプレートはプログラミング言語そのもの コンパイル時に任意のコードが実行できてしまう => ⚠Danger Programming Language Templateをコンパイルする危険例: ローカル メールでマクロ付きのWordファイルを開いて、ローカルで任意のプログラムが実行されてしまうケース マクロはプログラムそのもの 偽装メールが再び拡散、不正マクロを仕込んだ添付ファイルでマルウエア感染：マクロウイルスの再来？ - ＠IT デフォルトではマクロは無効化されており、オプトインで有効化になっている Office ドキュメントのマクロを有効または無効にする - Office サポート Programming Lang
やはりHTML/DOMは再発明されるべきじゃないか - mizchi's blog
と思う次第である。以下理由。 JavaScript, GUI設計の今 JSはそのプラットフォーム特性上、あらゆる言語の使用者の、あらゆる不満が集まる場所で、ヘイトを集めやすい環境だと思う。近年は npm というプラットフォームの登場でエコシステムが生まれ、思いつく限りあらゆるメソッドが適用されてきた。貧弱な言語基盤だが、その中で生き残った方法論が、今一番GUIの課題を上手く扱えている、と自分は考えている。 React/Redux や Angular によって、Flux/MVVMという抽象パターンが枯れてきたように思う。(この際、現場はまだ jQuery だぞ、みたいな話は無視する)。要は View は State の写像である、ということに尽きる。State はシリアライズ可能(JSON)で、Flux Action/Rx.Observable の Event Stream を入力とし、それ
display:table-cell;を安易に使うべきでない理由いろいろ - Qiita
display:table-cell;は特性を理解してから使おう カンタンに横並びや縦横中央揃えができるという理由から「使わな損やで？」みたいに取り上げられがちなdisplay:table-cell;ですが、それ以上に仕様と特性をちゃんと理解していないと、結構危険なCSSプロパティです。 初心者なら「floatって挙動がよくわからないし、clearfixもどう使ったら良いのかわからん。」と理由で、上級者なら「IE8以上から上下中央揃えを実現できるなんて最高だぜヒャッホゥ！」といった理由から選択しがちですが、使う場合は以下の様なデメリットがあることを必ず踏まえておいてください。 レスポンシブレイアウトでの自由さがない コーディングの際にPCで5列、スマホで1列になるグリットレイアウトのデザインがあったとします。 そしてHTMLはなるべく分かりやすく、メンテナンスも簡単に済むように以下の形式で
【Tips】ただただフォーム最適化をまとめたチートシート的なもの - Qiita
概要 主に「2016年 - 2017年」の記事から引っ張ってきて、ただただ羅列したものです。 なので、このまとめ自体の最適化が成されてないですが、そこはご容赦ください… ユーザビリティ・アクセシビリティ 分かりやすさ 入力項目は必要最低限にする 項目名は簡潔で短く分かりやすいものにする できる限り入力フィールドの数は最小限にする 一つの項目の入力フィールドを複数に分けない 例：姓名、電話番号、郵便番号など 必須項目は、「＊」ではなく「必須」と表示する ラベルやヒント（○文字以上必要です）をplaceholderに設定しない フォーカスした際に消えてしまうため、入力例を入れてあげる程度にする フォーカスした際の入力フィールドのデザインを変える 入力フィールドのサイズは、入力される値に合わせる リアルタイムでチェック出来るバリデーションを実装する エラーメッセージは、上部にすべて表示するのでは
マークアップの最適解を
見つけ出す方法
The document discusses markup and how to structure different elements like headings, paragraphs, lists, sections and comments. It provides examples of proper markup for navigation menus using unordered and ordered lists, adding headings and paragraphs within an article and section elements, and using comments to add notes that do not create paragraphs. The document serves as a guide for how to pro
そろそろ真面目に、HTMLで帳票を描く話をしようか - Qiita
帳票といえばPDFとして生成するのが一般的でしょうか? でも、2015年の今、あえてHTMLで描くのがホットです(個人的に)。ミリ単位で設定された高度な帳票も、CSSを駆使して簡単に作ることができます。業務システムでもモダンブラウザを選択することが増え、@pageなども積極的に使えるようになったこと、SPA(Single Page Application)の台頭、いろいろと条件が揃ってきました。 書いてたら結構長くなっちゃったので、さくっとコードだけ見たい方は、Paper CSSリポジトリをどうぞ。 はじめに HTML帳票のメリット 2015年現在、HTML帳票を選択する幾つかのメリットがあります。 ライブリロードで、リアルタイムなスタイル調整 バックエンドではなくフロントエンドで生成できる 前者は、gulpやGruntの普及で、CSSにしろHTMLにしろ、リアルタイムにプレビューできる環
DOMContentLoaded周りの処理を詳しく調べてみました - Qiita
利用者が一定数いるIE6,7,8を除いて、現在利用されているほぼ全てのブラウザで標準仕様として扱えるようになっています。2006年ごろから登場したjQueryの$(document).readyは有名ですが、この存在もDOMContentLoadedが正式に取り入れられるきっかけの1つになっています。 2. jQueryのreadyとの違い HTML5で定義されているDOMContentLoadedとjQueryの$(document).readyは、DOMツリーの構築が完了したことを判定するという点で役割は一緒といえます。ただ、jQueryは古いバージョンのブラウザをサポートするためにDOMContentLoadedを使わないready判定の実装を行っていました。 1. jQuery Core 1.0のready判定（1.0から1.2.1まで） jQyer Core 1.0を見るとIE/
スマートフォンサイト構築時に気をつけたいポイント集
作成：2015/10/5 更新：2017/04/16 Web制作 > 開発環境 スマートフォンサイト構築時のコーディングで気を付けたいポイントを次回コーディングの時のためにメモしておきます。 エンジニア速報は Twitter の@commteで配信しています。 全般 viewport デバイスを横向きにした時の処理一例です。 一般（ページ拡大表示）ピンチアウト/ピンチインOK。通常はこれを使うことが多い。 <meta name="viewport" content="width=device-width"> サイズを変更せず、ピンチアウト/ピンチインOK <meta name="viewport" content="width=device-width,initial-scale=1.0"> 2倍に拡大した状態でページ表示 <meta name="viewport" content="wi
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
もう逃げない。HTMLのviewportをちゃんと理解する
<meta name="viewport" content="width=device-width,initial-scale=1"> と呪文のように書いてきたが、いい加減ちゃんと整理して理解しよう。 いろいろ調査した結果、以下の考え方で理解できると思う。 まず、実際の液晶の解像度は一旦忘れろ。 <meta name="viewport" content="width=480">と指定したとする。 するとそこに幅480pxの仮想的なウインドウが作られる。幅480pxの液晶モニターがあることをイメージして欲しい。これをviewportと呼ぶ。 ブラウザはviewportにレンダリングする。viewportの中では、あたかも本当に480pxのモニターを使っているかのような環境になっている。なので、JSのdocument.documentElement.clientWidthなんかも480を返す
Webパフォーマンス最適化入門 // Speaker Deck
All slide content and descriptions are owned by their creators.
プログラム組んだら負け！実はHTML/CSSだけでできること2015夏
2. 2015 Yusuke Hirao, CC BY-ND. 自己紹介 平尾優典（ひらお ゆうてん） === 株式会社ディーゼロ Webエンジニア ## コミュニティ活動 - 福岡フロントエンド友の会 Fukuoka Frontend Frogs - 福岡マークアップ勉強会 - baserCMSユーザー会 Yusuke Hirao @cloud10designs 3. 2015 Yusuke Hirao, CC BY-ND. 自己紹介 ## コミュニティ紹介 ### 福岡フロントエンド友の会 Fukuoka Frontend Frogs ### 福岡マークアップ勉強会 ### baserCMSユーザー会 「井の中の蛙」にはならないようにと集まった フロントエンドエンジニアのためのコミュニティ。 Webコーディング・アプリ開発の悩める蛙たちが その場で話題を決めて、アンカンファレンス形式で
High Performance HTML -さまざまなデバイスに配慮されたクリーンで簡潔なHTMLの書き方
多くのWeb制作者はパフォーマンスというと、JavaScriptや画像の最適化、サーバーの設定、CSSなどのファイルの圧縮や結合を検討します。そして、Webページのコアとなる言語にも関わらず、HTMLは無視されがちです。 HTMLは単に複雑さと要素の数を減らすだけでは、パースにかかる時間をあまり改善することはできません。しかしよく作られたHTMLはページを素早くロードするための決定的な土台になり、異なるビューポートサイズに対応するレイアウトになります。 さまざまなデバイスに対して素早くロードし、うまくいくコンテンツを作ることができるクリーンで簡潔なHTMLのコードを紹介します。 High performance HTML 下記は各ポイントを意訳したものです。 著者のSam Dutton氏は、Google ChromeのDeveloper Advocateをされています。 ※当ブログでの翻訳
検索じゃ学べない！ HTML/CSS/JavaScriptの気づきTipsまとめ31こ | _level0 - KAYAC Front Engineer Blog
HTMLファイ部のほんだです。 気づきTips！ Σ(・ロ・) カヤックの中でもHTML5のWebフロントエンド実装を担当する エンジニアを集めた部署「HTMLファイ部」では、 制作にあたってはまったことや、気づいたことをメモ的に蓄積・共有しています。 通常は、 1. 制作で何かわからないことがでた ▼ 2. Google等で検索して解決の糸口をさがす ▼ 3. こんな方法があったのか〜 と気づきを得る というフローでスキルアップしていくことがもっぱらだと思うのですが、 学びを増やしていくためには違うアプローチも必要なんじゃないかと思います。 カヤックHTMLファイ部では、 1. みんなで蓄積したTipsをざぁっと読む ▼ 2. こんな方法があったのか〜 と気づきを得る ▼ 3. 制作の際に導入していく というフローを繰り返し実践していくことで、 検索では気づけないことを学び、実装力アップ
ブラウザにやさしいHTML/CSS
1. HTML/CSS 〜 「お・も・て・な・し」をブラウザにも 〜 TAKEHARU IGARI Front-end Engineer / Evangelist ブラウザにやさしい <html5j パフォーマンス部 第⼀回勉強会 /> 2. プロフィール • TAKEHARU IGARI 猪狩 丈治 - 所属 • 株式会社 Lei Hauʼoli フロントエンドエンジニア - 略歴 • 表⽰速度、保守性、ブランディング、SEOを考慮したフロントエンドエンジニアリングを得意とし、 現在、各ナショナルクライアントのプロジェクトや、株式会社リクルートの主要サービスのフロント エンド開発に携わり、⾼速化コンサルティングも⾏う。 - 執筆 • 技術評論社「WEB+DB PRESS」 • Vol.66 〜我流コードからの卒業HTML構造化指南 • Vol.59 〜「Webサイト超⾼速化実況中継 ──
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう - YoheiM .NET
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう こんにちは、@yoheiMuneです。 ブラウザのレンダリングの仕組みはHTML5 RocksやHow browsers workで詳しく解説されてきました。しかしそれらはとても詳細で、読破して理解するのは大変です。 今回のブログでは手軽にレンダリングの概要を理解できるように心がけました。またより詳しく学べるようなリンクも記載しました。 そしてブラウザのレンダリングの仕組みを理解した上で、どのようなJavaScriptを書くべきかについても記載しました。 目次 ブラウザのレンダリングの仕組み この章では、HTMLとCSSが読み込まれてから画面に表示されるまでの間に、ブラウザがどのような処理を行っているかを説明します。 ファイル読み込みから表示までの一連の流れは以下図の通りです。 [1]
![[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/705cdef7654f2f96a242f9a2834ce643b78de75c/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F336.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
