タブやアコーディオンの非表示コンテンツにはhidden="until-found"を使うべし ｜ TAKLOG
タブやアコーディオンの非表示コンテンツにはdisplay:noneがよく用いられますが、hidden="until-found"を利用するほうがメリットがあります。 hidden=“until-found”で非表示にしたコンテンツはページ内検索でアクセスできるuntil-foundはhidden属性に新たに追加された属性値です。 hidden - HTML: ハイパーテキストマークアップ言語 | MDN 従来のhidden属性とは違い、until-found"属性値を指定した場合はブラウザのページ内検索やページ内リンクでそのコンテンツが検出された場合、自動でhidden属性が取り除かれて表示することができます。 従来のdisplay:noneを使用した非表示ではコンテンツ内にページ内検索でマッチすべきワードがあったとしても検出できませんでしたが、hidden="until-found"を使
HTMLのdialog要素とフォーム機能 - Hatena Developer Blog
こんにちは、id:nanto_viです。この記事ははてなエンジニアAdvent Calendarの1日目の分です。 Webアプリケーションでモーダルダイアログを実現しようとして苦戦したことはないでしょうか？ 自前でHTML、CSS、JavaScriptを組み合わせて実装していくと、フォーカスやスクロールの制御が大変ですよね。そんな悩みを解決してくれるのがHTMLのdialog要素、Webブラウザ組み込みのモーダルダイアログ実装が利用できるという優れものです（モードレスダイアログとしても利用できます）。 dialog要素を使うことで、モーダルダイアログに要求されるJavaScript機能をブラウザが肩代わりしてくれるので、アクセシビリティの確保も簡単になります。 2021年12月現在、ChromeやEdgeはすでにdialog要素に対応しています。FirefoxやSafariの開発版でも対応
中身のない空の 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>
話題の Portals を使った画面遷移 UX の未来 | ウェブボウズ
ご無沙汰しております。ウェブボウズを立ち上げて 1 年が経ちました。皆さま如何お過ごしでしょうか。私は、この 1 年間ひとつもブログポストできていません。さらには私の坊主頭（スキンヘッド）にちなんでウェブボウズという名前をつけた個人ブログでありましたが、5 年間共にしたこの Hair-less style から心機一転して 2019 年は髪を育んでいく方針を固めましたので、もはやボウズでもなくなってます。変わり続けることだけが普遍であると胸に刻んで今年も強く生きていきたいと考えております。 さて、最近 Signed HTTP Exchanges やら Performance Budget やらさまざまな面白いことに関わらせていただいて忙殺と幸せを噛み締めている中でも、Chrome Dev Summit 2019 でも大きくフィーチャーされました Portals という新しい HTML 要素
制作者のためのHTML
主にユーザー側の視点から語られることが多いアクセシビリティですが、制作という側からはどのように捉えることができるのでしょうか。2つの切り口から考えてみます。 # アクセシビリティという文脈において、何のためにHTMLを書くかという話になると マシンリーダビリティのため スクリーンリーダーのアクセシビリティのため というように、ユーザーが利用するため、というところにフォーカスした語られ方が多いように感じています もちろんユーザーのために作るというのは正しいのですが、今回はあえて視点を変えて、制作者自身の作るというところに視点を合わせて話してみたいと思っています 僕がどういうものなのかというと、 # 参照: 全部入りHTML太郎(@_yuheiy)さん | Twitter ツイッターでは「全部入りHTML太郎」という名前でやっています # 参照: シフトブレイン／スタンダードデザインユニット
div要素の正しい使い方
2017年11月17日の「まぼろしのマークアップ勉強会 #1」でお話したスライドです #mbrs_markup_study
RSSが衰退し、SNSが繁栄する時代に改めて考えたい、ニュースリリースのマークアップ
7月下旬のことですが、またひとつフィードリーダーが終了してしまいました。 【重要】Live Dwango Reader/LDR Pocketサービス終了のお知らせ(blog.livedoor.jp) 終了の理由はこの数年で利用者も大幅に減少しており、サービスとしての役割を終えたとのことですが、ユーザーが別サービスに移行したというより、RSS/Atomフィードで新着をチェックする需要そのものが減っているのでしょうね。代わりに今はSNSで更新告知をしたり、プッシュ通知ができるサービスも増えたりしています。 RSS/Atomフィードでの更新チェックは、10分に1回、30分に1回などの間隔で巡回をするため、 リアルタイム性に劣る 更新頻度が少ないサイトほど無駄な通信の割合が高い など時代遅れの面もありますが、サイトの新着情報を確実に把握するという意味で総合的に考えると、その特性は未だ捨てがたいもの
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
続・よくある3つのデザインから考える、マークアップの最適解
マークアップシリーズの第2回は、前回のよくある3つのデザインから考える、マークアップの最適解と同じく、html5jマークアップ部主催のイベント「MarkupCafe」で出題された3つのお題から最適なマークアップを探ります。 イベントではAからDの4つのチームにわかれてマークアップを考えました。それぞれのチームごとに違ったマークアップへの考えが表れていてとても興味深いです。また今回はイベント終了後に「HTML5 Experts.jp」のエキスパート兼マークアップ部の部長でもある村岡正和氏に、氏自身ならこうするといったマークアップを公開してもらいました。 本記事ではWebサイト制作の際にありがちな”ページング”、”フォーム”、”データテーブル”の3つについて要素の使いどころや仕様、アクセシビリティやユーザビリティといった観点からマークアップを考えていきます。 1.ページングの中身と重要度 最初
リンクかボタンかそれ以外か - Unreviewed
あるアクションを引き起こす「モノ」を「リンク」とするか「ボタン」とするかは、何を基準に判断すればよいのでしょうか。ここでは最近の私の解釈を書きます。 最近の私の解釈 最近の私の解釈は「アクションが、ページの遷移かフォーカスの移動を発生させるものはリンク、そうでなければボタン」というものです。この解釈はWAI-ARIA 1.0のある注記がきっかけになっています。 WAI-ARIA 1.0 WAI-ARIA 1.0 （2011年1月18日勧告候補）にはlinkロールとbuttonロールがそれぞれ用意されています。中でもlinkロールには私の解釈の直接のきっかけとなった注記があります。 Note: If pressing the link triggers an action but does not change browser focus or page location, authors
ボタンの押し込みをCSSで表現する
時代は:active！ タッチ・デバイスに:hoverなどない！ みたいになりつつあるような気がしないでもないので、ボタンの押し込みの表現を色々考えている。とは言ってもタッチ・デバイスでは:active擬似クラスもいまいちアレなのでまだあんまり意味なかったりするけど。三周回ってデフォルト使えみたいな感じになっている節もある。ですよねー。 Demo: Pixel Pushing padding 一番のメジャーで安定のクオリティー。 .test { padding-top: 10px; padding-bottom: 10px; } .test:active { padding-top: 11px; padding-bottom: 9px; } 欠点はpx単位でpaddingプロパティーを制御せざるを得ないのでスケーラブルにしづらくなること。 position ボタンのテキストだけでなく全体を
✌🐷✌ on Twitter: "http://t.co/BkmRaDkJ そう言ってるけどさ、HTMLの意味は大事だが、表現性や可能性を殺してまでそれを厳守するのはいただけない"
http://t.co/BkmRaDkJ そう言ってるけどさ、HTMLの意味は大事だが、表現性や可能性を殺してまでそれを厳守するのはいただけない
CSS3で表現力が高くなったからと言って、span等でボタンを作るのはやめて下さい。いえ、やめなさい。もう少し真っ当なHTMLを作ることを心がけましょう。むしろ今すぐwebの仕事辞めて腹を切って死ぬべきである!
もう禿げ上がるぐらいに同意。teramakoさんはアクセサビリティの観点で言及した訳ではないみたいだけど、アクセサビリティの観点からも、spanやdivでボタン作るwebデベロッパは死ぬべきだと思う。恐ろしい事に、Googleなんかもこの過ちを犯している。 これが、Vimperatorのような『利用者が敢えてポインティングデバイス以外での操作を好んでいる』という場合だけ問題になるのならば兎も角、例えば音声ブラウザを利用せざるを得ない、視力に問題を抱える閲覧者にも影響が有るというのはどうなのか。そんな奴らは知ったこっちゃないって？ふーん? せめて、WAI-ARIAのrole属性を付けるとかして欲しい。role="button"とか。それならば、ある程度問題は小さく出来る筈だ。 取り敢えずteramakoさん始めVimperator使いな人達は、.vimperatorrcで'hinttags'
HTML5の考察
ホーム APPENDIX HTML5の技術・政治的考察 HTML5とは何か 技術的考察 HTML5でHTMLを記述するに当たっては、当然、「新たに採用もしくは変更された要素や属性をどのように使うのか」が、焦点になります。 2010年前半でHTML5が話題に上ったとき、そこでは動画をブラウザ自体で再生できるようにするvideo要素の存在が、Adobe Flashとの対比で注目されていました。また、それ以前からもスクリプトなどを使って動的に画像をブラウザ上で描画できる、canvas要素なども関心を集めているようです。実際、遅ればせながらcanvas要素に対応したIE 9 Betaが登場した際には、canvas要素を効果的に採用した協賛サイトが多数紹介されています。 こうした、動的で応答性に優れた「Webアプリケーション」をサポートすることも、HTML5の目的になっていますが、私自身は、オーソド
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Popover API - JavaScript不要、HTMLのみでポップオーバーUI
メニューボタンを span だけで実装するのは良くないのでやめた話
h1要素は複数回使って良いのか!? HTML5.1に関するW3CとWHATWGの主張の違い
README.ja.md#%E5%8F%AF%E8%83%BD%E3%81%AA%E3%82%89%E3%81%B0for%E5%B1%9E%E6%80%A7%E3%81%AF%E7%9C%81%E7%95%A5%E3%81%99%E3%82%8B
Extend existing HTML elements instead of creating custom ones · Issue #583 · ampproject/amphtml
フォーム関連要素（2） HTML5でinput要素に追加された新しいタイプ13連発
