JavaScript不要! HTMLとCSSでつくるカルーセルUI - ICS MEDIA
2025年4月にリリースされたChrome 135、Edge 135からHTMLとCSSのみでカルーセルUIがつくれるようになりました。新たに追加された::scroll-button()、::scroll-marker疑似要素を使用して、ボタンやインジケーターが実装可能です。 ▼HTML・CSSだけで実装したカルーセル カルーセルUIといえば、いちから自前で用意するのではなくSwiper.jsなどのJSライブラリを採用してきたコーダーも多いのではないでしょうか？ ICS MEDIAでもカルーセルUIを作成できるJSライブラリをまとめた記事があります。 『カルーセルUIを実現するJSライブラリまとめ - 導入手間や機能の比較紹介』 本記事では、新しいCSSでどのようなカルーセルが実現可能になるのか紹介します。 ご注意：本記事のデモは、Chrome 135・Edge 135以上で閲覧ください。
aria-expandedの理想的な使い方 -- 名前と状態は適切に区別したほうが良い - ARIA-Barriers
@yncat です。 近頃のAIとの対話は本当に楽しいです。今回の記事でも、具体例のコードや、考えの整理のために大いに役立ってくれています。技術者としては、新しいツールのネイティブになっていかないと、すぐにおいて行かれるなと思って、精進する毎日です。 aria-expanded と aria-label 重複はよくないという意見 先日、 こういう意見をGithubに送りました 。 内容を簡単に要約します。 GitHubのマイページ で、自分の行ったコミットやpull requestの実績が出るところで、 aria-expanded で状態が示されている項目に対して collapse や expand などの aria-label がついているのが不要だという主張です。 これは、 WAI-ARIA を利用してアクセシビリティを実装しているウェブサイトでたびたび見られる、典型的な誤用であると私
dialog 要素の罠 - Esc キーを連打すると preventDefault が効かない - Qiita
はじめに 最近の Web 開発では、モーダル UI のマークアップに <dialog> 要素を利用することが主流となってきました。 最小限の JavaScript でモーダルを実現可能 フォーカス制御や Top layer などのアクセシビリティへの配慮が標準実装されている Esc キーで閉じる機能が標準搭載（本記事のテーマ） Chrome, Firefox, Safari, Edge など、主要なモダンブラウザでサポートされている この記事では、<dialog> 要素に標準搭載されている Esc キーで閉じる機能が、とある条件下で制御できない問題についてまとめます。 結論 最初に結論まとめです: <dialog> 要素の Esc キーによる閉じる操作は cancel イベントを発火する Chromium では、Esc キーを連打すると2回目以降の cancel イベントは event.c
Dialog と Popover #1 | blog.jxck.io
Intro HTML の <dialog> 要素と、 popover 属性、および関連する様々な仕様が標準化され、実装が進められている。 Open UI を中心に進められているこれらの改善は、多くのサイトで共通したユースケースがありながら、長らくミッシングピースとなっていた重要な機能だ。 もし今、同等のユースケースを自前で実装しているのであれば、適切な仕様を用いた実装に刷新することで、従来はほぼ不可能だった UX を提供できるようになる。 今回から、数回の連載形式で、これらの仕様がどのように標準化され、我々開発者はこれをどのように使っていくべきなのかについて解説する。 showModalDialog Modal や Dialog と言われる UI の歴史は Web においても古く、ブラウザでは IE4 くらいのころに独自実装された window.showModalDialog() が最初に
CSSを書く人の為のHTML5 inline or block 早見表 - Qiita
ドーモ こんにちは 皆さんはCSSは書いておられますか？ 毎日書いてるよって人も、たまに書くだけだよって人もおられるかとは思いますが、ごくまれに書いてるはずのCSSが上手くHTMLに当たらないって経験は必ずされると思います。そのような時は、CSSで"display:ほにゃらら"と当ててやるとたちまちご機嫌なCSSに立ち返ります。MDN"display"正確な解説はMDNをご覧ください この原因はHTMLの初期値のスタイル block or inlineという要素がCSSの邪魔をしているのです。 block要素には、block要素のCSSルール(具体例:inline要素とは異なり高さと幅を指定できる。) inline要素にはinline要素のCSSルール(具体例:inline要素の marginは、 左右のみ指定可能。上下は指定不可。)がそれぞれ独自にあります。 わかりやすく言うとサッカー部
混合状態のチェックボックス - ARIA-Barriers
@nishimotz です。 ウェブアクセシビリティLT＆交流会 vol.4 に参加して、交流会で話したことを、あとで気になって調べてみたのが今回の記事です。 混合状態(部分的にチェック済み)のチェックボックスは、あるオプションが複数のサブオプションを統括しているような場合に便利な UI 要素です。 しかし、アクセシビリティを確保するためには、適切な実装が必要だとされています。 さて、どうしたらいいのでしょうか。 APGの実装 ARIA Authoring Practices Guide (APG) Checkbox Example (Mixed-State) の実装を見てみましょう。 テキストだけ日本語に翻訳しました。 <fieldset class="checkbox-mixed"> <legend> サンドイッチの具材 </legend> <div role="checkbox" c
Customizable Select Element (Explainer) | Open UI
Customizable Select Element (Explainer)Table of ContentsSection titled Table%20of%20ContentsBackgroundOpting in to the new behaviorTesting out the customizable select elementHTML parser changesUse casesCustomizing basic stylesRich content in <option>sReplacing the buttonRendering the <option> differently in the buttonPutting custom content in the listboxAnimationsSplit buttonsButton behaviorThe se
要素を非活性にするのに、まさか disabled を使ってないよね？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに フロントエンドエンジニアのみなさん、 要素を非活性にする際、disabled=trueを使っていませんか？ アクセシビリティ的にそのやり方は良くないです。 最近、アクセシビリティに配慮したアプリケーションの開発に携わっています。 その中でシニアエンジニアから頂いたフィードバックについて共有したいと思います。 結論 disabled=true ではなく aria-disabled=true を使う disabledの場合 disabledが付与されている要素はフォーカスができません。 そのため、キーボードを用いて操作しているユー
スクリーンリーダーの操作にはTab以外のキーも必要です - Qiita
macOSのSafariでは、ボタンやリンクにTabキーでフォーカスを移動できないのがデフォルトの設定になっている Safariでは、「設定」画面の「詳細」パネル内にある「Tabキーを押したときにWebページ上の各項目を強調表示」のチェックを入れていないと、Tabキーを押したときにボタンやリンクにフォーカスが移動しません（Optionキーを押しながらTabキーを押すと移動できます）。デフォルトではチェックが入っていない状態になっています。 また、macOS版Firefoxでは、「設定（about:preferences）」内の「タブキーでフォームコントロールおよびリンク間のフォーカスを移動する」にチェックが入ってないと、Safariと同じくボタンやリンクにはTabキーでフォーカスが移動しないようになっています。これはSafariの挙動にあわせて追加されたようで、やはりデフォルトではチェック
若い世代が知らない2000年代のHTMLコーディングの地獄 - ICS MEDIA
ウェブの黎明期である2000年頃と比べてはるかにHTMLはコーディングしやすくなりました。10〜20年前のHTMLコーディングはどのようなものだったのでしょうか。 この記事では、NetscapeとIEのブラウザ戦争に決着がついた後の、IE6が全盛期となった2000年代のウェブサイト制作を振り返ります。懐かさに浸たり、現代のウェブの成り立ちに通じる温故知新な情報として参照ください。 テーブルレイアウト / spacer.gif XHTML・CSSが普及するまではテーブルレイアウトが一般的でした。テーブルレイアウトとはtableタグを使い、格子状にレイアウトしていく手法です。テーブルレイアウトは、デザインファイル（Image ReadyやFireworks）から画像を切り出す「スライス機能」と相性のいい方法でした。 <table border="0" cellspacing="0" cellp
令和のHTML / CSS / JavaScriptの書き方50選
Web制作の技術は日々進化しており、会社やプロジェクトによっては昨今の環境に適さない書き方をしているケースも時折見受けられます。 そこで今回は「2024年のWeb制作ではこのようにコードを書いてほしい！」という内容をまとめました。 質より量で、まずは「こんな書き方があるんだ」をこの記事で伝えたかったので、コードの詳細はあまり解説していません。なので、具体的な仕様などを確認したい方は参考記事を読んだりご自身で調べていただけると幸いです。 1. HTML 画像周りはサイトパフォーマンスに直結するので、まずはそこだけでも取り入れていただきたいです。また、コアウェブバイタルやアクセシビリティも併せて理解しておきたい内容です。 Lazy loading <img>にloading="lazy"属性を付けると画像が遅延読み込みになり、サイトの読み込み時間が早くなります。
contenteditableについてのメモ書き17選 - Qiita
contenteditable contenteditableというものを知っていますか？ textareaではプレーンテキストを扱うことができますが、contenteditableな要素では様々な種類のNodeを扱うことができます。 色付のテキストから、図形、画像、動画まで、いろいろ扱える高機能なもの、それがcontenteditableな要素です。Twitter(X)のツイート画面がイメージしやすいかもしれません。 contenteditableについてのメモ contenteditableについてのメモをつらつら紹介していきます。 僕はtextareaで特定文字にハイライト表示するようなもの(リッチテキストエディタ)を目指していたので、それ前提のものが多いです。さきにこの記事に目を通しておくといいかもしれません。 1. range書き換えの注意その1 EnterやBackspaceが
decoding="async" について詳しく調べてみる
この記事は2023年7月19日時点の Chrome の最新版 115.0.5790.98 を使って検証しました。今後 Chrome の実装によって挙動が変わる可能性はございます。 はじめに 画像表示のパフォーマンス改善において、「decoding="async" をつけましょう」というのをよく見かけますが、おそらくほとんどの人がその実際の挙動を理解していない、あるいは誤った認識をしていると思います。今回詳しく調べる前の僕も含めて。 loading と decoding の違い 画像のパフォーマンス改善で decoding="async" のほかに、もう一つよく言及されるのが loading="lazy" です。decoding 属性について詳しく見る前に、まずは loading 属性との違いについて理解したほうがいいと思います。 loading とは、ブラウザがどのように画像を読み込むかを
想定外の新機能！ HTMLの<input type="checkbox" switch>だけで、スイッチUIが実装できるようになるぞ
WebサイトやアプリのUIで、スイッチを実装するのはなかなか面倒です。CSSで書くと、なかなかのボリュームになってしまいます。 そんなスイッチがHTMLだけで実装できるようになります。 Release Notes for Safari TP 185によると、HTMLの新機能としてswitch属性がサポートされました。これにより、スイッチUIがHTMLで簡単に実装できるようになります。 switchについては、かなり前から実装についてGitHubで議論されていました。スイッチは人気のあるUIコントロールだけど、CSSで実装するのは簡単じゃないよね、簡単に実装できるようにしよう。という感じです。 スイッチUIを実装するHTMLは、下記の通りです。
コンポーネントごとに考えるアクセシビリティ - Qiita Advent Calendar 2023 - Qiita
はじめに みなさん初めまして。🎅🏻 Qiita株式会社で マネージャー・PdM・デザイナーをしている、自分のことをデザイナーであると自認 @degudegu2510 です。 去年に続き、今年のQiita Advent Calenar 2023でも、1人で25記事以上投稿した方 全員 に完走賞がおくられる企画を開催しています。🎉 🎉 Qiita運営として、ユーザー様だけに25記事完走してもらうのは、とても忍びないので、今年も25記事完走してやろうとこのカレンダーを作成しました。 「有給を使ってでも、25記事完走するぞ！💪🏻」という気概でいるので、購読・応援していただけると嬉しいです。 ※ 2022 完走賞：【完走賞ゲットだぜ！】CSSでポケモンマスターになってやる Advent Calendar 2022 テーマ このカレンダーは、 UIコンポーネントごとに考えるアクセシビリティ
MDN を過信してはいけない - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は 2023 年の MDN 翻訳 Advent Calendar 向けに作成したものです。 こんにちは。debiru です。HTML のことを考えるのが趣味です。 今回は MDN に記載されている内容が正しいとは限らない、盲目的に信用してはいけない、Wikipedia と同じくらい誤りがある可能性があるものである、MDN というものは懐疑的に解釈すべきものであるということをお伝えしていきたいと思います。 h1 要素は複数使うべきではない？ ここでは「h1 要素は複数使うべきではない」という MDN の主張に対して私が殴
MDNとかをみんなで編集！翻訳！ - Qiita Advent Calendar 2023 - Qiita
オープン Web の開発者向けドキュメント MDN Web Docs には、Web アプリ開発に役立つノウハウなど、英語ドキュメントが日々どんどん追加されていっています。ただそのぶんドキュメントの日本語化(l10n=localization)は後手後手になっています。 新しいウェブ技術やウェブ標準に興味ある 翻訳に興味あるけど、どうしたらいいか分からない 英語は苦手だけど、日本語の文書を読みやすくするとかならできるかな Mozilla のコミュニティ活動に参加してみたい フォクすけに萌える MDN を翻訳してきたけど最近ご無沙汰気味 などなど、色々な方面からの参加をお待ちしています。 参考情報: みんなで編集！翻訳！カレンダー 2021 みんなで編集！翻訳！カレンダー 2020 みんなで編集！翻訳！カレンダー 2019 みんなで編集！翻訳！カレンダー 2018 MDN Web Docs ド
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
popover=hint - Chrome Platform Status
HTML: object要素で変な物を仕込む - Qiita
HTML: iframeを使った手品 - Qiita
