Cardのマークアップでもう悩まない！NestedでClickableなUIを実現する、Link Area Delegationとは
Cardのマークアップでもう悩まない！NestedでClickableなUIを実現する、Link Area Delegationとは2024-12-16 Open UI Community Groupで、仕様の策定が検討されているProposalの一つに、Link Area Delegationがあります。 本エントリでは、Link Area Delegationの仕様がどのような背景から検討され、何が可能となり、これから私たちがどのように利用していけるのかを紹介します。 Link Area Delegationとは Link Area Delegation（= リンク領域の委譲）Proposal は、コンテナがインタラクティブな領域を特定の要素に委譲することで、コンテナを「クリッカブル」にする機能を標準的に導入しようとする試みです。 例えば、提案されている手法のひとつである、linkar
フォーム全体を非活性化（ちょっと良いUIおれおれAdvent Calendar 2024 – 05日目） | Ginpen.com
ちょっと良いUIおれおれAdvent Calendar 2024 – 05日目 フォーム送信を HTML ではなく JavaScript から管理するとき、応答待ちの間はくるくるを出すのと合わせて各種入力を非活性化しておいてほしいなと思います。何か条件を満たすまで利用できないようにしておくとかも。 でも入力欄が 100 個あると全部に disabled 付けるのダルいですよね。<fieldset> を使うとひとつで済みます。あきらめないで！ デモ https://codepen.io/ginpei/pen/ByBjLYR <fieldset> <fieldset>: フィールドセット要素 – HTML: ハイパーテキストマークアップ言語 | MDN <fieldset> はフォームのグループ化を行う要素です。普通は（本来は？） <legend> と組み合わせて使います。 disabled
jQueryは1個の要素と複数個の要素を同じように書かせる - fsubal
「1個の要素と複数個の要素を同じように書かせる」というのが実は jQuery の特徴の一つだと思っている。 document.querySelector() や querySelectorAll が出現して以降 jQuery の必要性はほとんどなくなったと言われる。
Don’t use custom CSS scrollbars
In the spirit of “everything old is new again,” browsers are once again supporting the ability to style the scrollbar. Much like custom CSS mouse cursors, I feel this is also a mistake. When you style things on the web, you get control over almost the entire experience. From ten thousand feet up, your scope of concern is this: The scope of concern for the browser is this: The browser’s UI is infor
多要素認証におけるワンタイムパスワードの入力欄 | Accessible & Usable
公開日 : 2022年10月17日 カテゴリー : アクセシビリティ / ユーザビリティ 各種サービスへのログイン、インターネットバンキングなどの取引実行前の本人確認、といったシチュエーションで、多要素認証としてワンタイムパスワード (†) の入力が求められることが珍しくなくなってきました。従来の認証方法であるユーザー ID とパスワードの組み合わせに加えて、都度、動的に生成される一定の桁数の数字の並びをユーザーに入力させることで、セキュリティをより強固なものにしています。 † ワンタイムパスコード、確認コード、認証コード、などと呼ばれることもあります。 ところで、このワンタイムパスワードの入力欄の実装には、<input type="password"> が用いられているケースを時折見かけます (個人的な感覚としては、インターネットバンキングでこのような実装が比較的多く見られる印象です)。
CSS設計における、すべてがコンポーネントであるという誤謬
後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。 BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。 もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。 典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してB
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
High-Level Programming Languages in AI Era -Human Thought and Mind-
キーボード操作を意識したHTML/CSSコーディング
この記事は 「Webアクセシビリティ Advent Calendar 2020」 5日目の記事です。 アクセシビリティ Advent Calenderの記事を寄稿するにあたり、少しの工夫であらゆるユーザーに対して優しいWebサイトを作れるようなHTML/CSSコーディングの方法についてまとめました。より多くの人にとって優しい・使いやすいWebサイトを作ることは訪れてくださるユーザーの方々だけでなく、クライアントにとってもユーザーの機会損失を防ぐことができるので多大なるメリットがあります。（よくコードが適当でもデザインが見えていれば良いって意見を聞くけれどそんなことはない） ただ、アクセシビリティを意識したHTML/CSSコーディングについてのまとめだと内容量が非常に多くなりZennなら記事より本で出したほうがベターになってしまうので、今回は数あるアクセシビリティの視点から「キーボード操作で
（ユーザ受けする）プログラミング言語の構文について考えてみた
多くのユーザに受け入れられる構文にはどのような要素が必要なのかを、だらだらと考えてみたものです（残しておくためにセルフまとめにしました）。根拠が極度に私個人の経験依存で、データの裏打ちもないのでツッコミ歓迎です。あと、駄文22から33に番号飛んでいますが、眠いせいでミスしただけです…。
Googleアシスタントのマルチモーダルレスポンスの考え方と最近のレスポンスまわりの変更点 - Qiita
音声は、会話形式の入力としてはとても自然で、ITの知識も必要なく、どのような年齢層でも利用できる利点があります。一方で、お店でメニューを見るような場合、メニューのすべてを音声で聞いて頭で覚えておき、それから選ぶのは大変です。目で「スキャン」したほうが自然な行動でしょう。音声と画面は文脈にあわせて、返し方を比較する必要性があります。 Googleアシスタントのレスポンス構成 こちらもGoogle I/Oからですが、Googleアシスタントのレスポンス構成は以下のように分離されます。 ユーザの文脈に合わせて自然な会話にしていくためには、会話のターン毎に、Visual Componentを含むすべての方法を検討する必要があります。例えば、prompt、cards, suggestion chipsなどです。例えば、上記の例ですと、Spoken promptですべて話しているトピックを画面上ではリ
CSSシークレット
本書はデザインの手引書ではありません。――「はじめに」より 本書では、デザインに焦点を当てるのではなく、「いかに問題を解決するか」がコードで示されます。視覚効果、ページ構造、ユーザーエクスペリエンスといった8つのカテゴリーから47の項目を挙げ、日々直面する現実的な問題――同じことを繰り返さず（DRY）、保守性、柔軟性に富み、軽量かつ標準に準拠したCSSスタイル設計を実現する――をコーディングで解決していくテクニックを学ぶことができます。解決策を発見するまでのプロセスを理解することが課題解決までの近道であるという考えのもと、背景にある考え方までひもといて解説。すでにCSSを使っている中・上級のCSS開発者を対象とした本書は、CSSで実現できることを広げてくれる一冊です。 推薦の言葉 はじめに 謝辞 メイキング 本書について 1章 イントロダクション Web標準は敵か？ 味方か？ CSSコーデ
オブジェクト指向で料理を例える場合，chicken.cut()かchef.cut()か
実用的で無い内容なのでここで聞いて良いのか悩みましたが，一応クラスの設計の参考になるだろうと思って質問しました。 自分の普段使いがPythonなので，説明用のコードはPython風ですが，どの言語にも共通する問題だと思います。 先ほど友人と，「鶏肉を5つに切る」にはどうすれば良いかという例えばなしをしていました。 これを実装する場合， chicken.cut(5) # chickenは (Foodクラスを継承した) Meatクラスのインスタンス chef.cut("chicken", 5) # chefはChefクラスのインスタンス。あらかじめset_foodなどで{"chicken": chicken}を内部に保持した状態にしておく の2通りが考えられるのではないかと思います。 鶏肉の状態が変化するという意味では，「chickenが5つに分割された状態になる」前者の方が自然であるように思
ワイヤーフレームを捨ててHTMLプロトタイプに移行した結果 | ベイジの社長ブログ
私たちの会社では長らく、画面設計といえばPowerPointを使い、ワイヤーフレーム（以下、WF）を作っていました。Web制作会社における非常にスタンダードなやり方であったため、ベターな方法と受け入れつつも、例えば以下のような無駄も多く、決してベストではないとも感じていました。 設計者がコーダーに文書構造の意図を説明する時間の無駄 設計者が考えたファイル構造やヘッダ情報を定義するためのドキュメントの無駄 コーディング時にWFやPSD上のテキストをコピペして移し替える無駄 リンク構造や動き、使い勝手を紙面上で表現しようとする努力の無駄 共通パーツに修正が入った時に各ページごとに修正を入れていく無駄 PC用とスマホ用の2種類のWFを作る無駄 更新するたびに新しいWFを印刷する紙の無駄 いずれも工夫次第で軽減できる問題でしたが、意思疎通のための中間成果物の体裁を整えるための多くの時間が無駄では？
その Dialog は本当に必要ですか？ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ダイアログは、ユーザとの対話の中でも特に「確認」や「注意」を促すために用いられる UI コンポーネントの一つです。二択あるいは三択の項目を配置して、YES/NO や OK/Cancel などのインタラクションを用意することで、ユーザとの対話をすることが出来ます。あるいは、単に現在の状態を表示（読込中など）し、その他の各種操作をブロックすることで、待つ必要が有ることを明示することも出来ます。 一方で、ダイアログはその表示が画面の前面に大きく表示され、時にダイアログ以外へのインタラクションを禁じる場合もあることから、使いどころを間違うと非常
[Ruby] Ruby 3.0 の特大の非互換について - まめめも
タイトルは釣りです。すみません。Ruby 3.0 はかなり先の将来の話なので、最終的にどうなるかはわかりません。でも Ruby 3.0 に重大な変更が予定されているのは事実なので、一緒に考えて欲しいと思います。 immutable string literal Ruby 3.0 では文字列リテラルをデフォルトで immutable （破壊的変更不可） にする、という方針が『決定』しました。(Feature #11473: Immutable String literal in Ruby 3) つまり、次のようなプログラムが動かなくなります。(当チケットから少し改変して引用） sql = "SELECT #{sec_id}, pt.path, st.doc_count " sql << "FROM #{stats_tablename} AS st " #### ←ここで例外: can't m
![[Ruby] Ruby 3.0 の特大の非互換について - まめめも](https://cdn-ak-scissors.b.st-hatena.com/image/square/41a89fcb974590a4899db1f15a2fdeffe4b3148f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126965966783%2F17680117126965970435%2F1550317722)
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
lightline.vim作りました - プラグインの直交性について - プログラムモグモグ
lightline.vimというVimプラグインを作りました。statuslineをなんかかっこよくしてくれるやつです。 https://github.com/itchyny/lightline.vim からインストールできます。 デフォルト (powerlineと同じ配色) wombat solarized landscape どうしてこれを作ったのかということを話すには、vim-powerlineとの出会いまで遡らなくてはなりません。 vim-powerlineとの出会い vim-powerlineとの出会いは約一年前になります。それ以前から気になってはいましたが、フォントにパッチを当てるのが面倒でためらっていました。しかし、重い腰を上げてインストールしてみました。 vim-powerlineがすごい - プログラムモグモグ インストールしてすぐ感じたことは、配色が気に入らないことでし
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高齢者でも使えるプロダクトUIの挑戦 / Designing User Interfaces for the Elderly
api-guidelines/Guidelines.md at master · microsoft/api-guidelines
