キャンバスベースのUIコンポーネントを作成することには意味がありますか？
DOMはUIの作成方法を完全に支配していますが、ボタン、リスト、水平/垂直グループなど、完全にキャンバスベースのUIコンポーネントの束を作成することには意味がありますか？
私は多くの欠点があることを確信していますが、そのような考えられる利点は何でしょうか？
1つは、一般的にキャンバスとの視覚的な統合がはるかに緊密になることです。
はいといいえ。
ページのUIを強調するという点では、JavaScriptが有効になっていない場合でもページのナビゲーションと操作が適切に機能することが理想的です。
キャンバスによってprettyifiedであるUI要素があってもかまいませんが、これらの要素には、Webクローラー（Googleなど）やスクリプトを無効にしているユーザーはアクセスできないことに注意してください。
番号：
キャンバスでテキスト編集を作り直そうとしないでください。 HTML Canvas Specにもセクションがあります Canvasでtext-editingコントロールを作成しようとしないでください
それを試みて失敗した長い歴史があります（Mozilla Bespinを調べてください）
私は多くの欠点があることを確信していますが、そのような考えられる利点は何でしょうか？
はい：
視覚化（テキストの説明以外にフォールバックがない）およびダイヤルのようなコントロール（input type="range"スライダーのような一部のHTMLにフォールバックする）は、Canvasで大幅に強化できます。
キャンバスコントロール、キャンバスダイアグラム、キャンバスチャートなどを検索すると、このようなものを提供する多くのライブラリが見つかります。これらの多くはアクセシビリティを犠牲にしてもたらされることをよく理解してください。
多分：
Canvasを使用してページに追加できるかなりの要素がたくさんあります。邪魔になったり、ページナビゲーションを変更したりせずに、本当に美しく見えるものもあります。おそらく、ウェブサイトのロゴは、手続き的に「成長」したり、輝いたり、あるいはより複雑になったりします。他の背景のアニメーション効果は本当に素晴らしいかもしれません。
何かのさまざまな部分（化学構造、生物、新車）を検査するためにナビゲートする図や分解図または分解図が必要なサイトなど、インタラクティブな画像もあります。作図やゲームなどの視覚的なインタラクティブメディアは、Canvasの最適な使用例です。
Zebra プロジェクトは、HTML5 canvas要素にレンダリングされる完全なコンポーネントセットを作成しました。これは、コンポーネントサンプラーのスクリーンショットです。私はフレームワークを使用していませんが、さまざまなブラウザーがUIコンポーネントをどれだけ適切にレンダリングできるかがわかるはずです。
コンポーネントを回転させ、ラインレンダリングの品質（アンチエイリアス）を確認します。これは、使用するブラウザーによって大きく異なります。この問題に関する詳細は次のとおりです。
別のプロジェクトは、Makepadです。これは、webGLワーカーベースのライブラリであり、ライブコードエディターです。 UIのすべての可視部分は、統合されたテキストレンダリングエンジンを介してレンダリングされる、画面上のすべてのテキストを含むWebGLでレンダリングされます。
まだプロジェクトの初期段階ですが、- ライブデモはこちら を試すことができます。 Makepadはオープンソースです。Gitリポジトリは github.com/makepad/makepad.github.io にあります。
200を超える要素がある場合は、CanvasをUIベースとして使用することをお勧めします。 DOM要素を使用するよりもはるかに高速にレンダリングできます。
IPhone Safariでは、300のアニメーションDOM要素が3fps（フレーム/秒）で実行され、非常に低速です。
キャンバスを使用する場合、300要素を超えるレンダリングが可能でありながら、30fpsを実現できます。これは、スムーズなアニメーションと遷移を意味します。私はこれを詳細にテストしたので、うまくいくことがわかります。
Canvasの欠点（他の人が述べたように）は、検索エンジンがコンテンツを表示できないことです。しかし、スパイダーリングされるべきではなく、モバイルで実行する必要のあるアプリを作成している場合は、Canvasが適しています。
過去4年間、ボタン、ダイヤル、スライダー、チェックボックス、ラジオボタン、カラーピッカー、ペイン、ウィンドウ、インジケーター、ウェイター、ステッパー、タブ、パッドなど、キャンバスのコンポーネントを構築してきました。参照 http://zimjs.com/components/ 作業例。
利点は次のとおりです。
- コンポーネントは、従来のHTML/CSSコンポーネントとは異なる方法でカスタマイズでき、より多くの種類のコンポーネントを作成できます。例については http://zimjs.com/docs.html を参照してください。
- インタラクティブな作品を作成するときに、コンポーネントをアプリやゲームに直接埋め込むことが重要になることがよくあります。これは、アプリのスケーリングを考慮に入れるときにHTMLコンポーネントをオーバーレイすることによって行うのは困難です。
- パネルのドラッグ、コンポーネントのアニメーション化、コンポーネントのスケーリング、キャンバスライブラリイベントの操作（ZIMとCreateJSはon（）メソッドを使用しますが、利点があります-キャンバスコンポーネントはこれを利用できます）の場合、より緊密な統合があります。
Canvasコンポーネントを使用するのが大好きです。これにより、コードの行が節約され、システムを切り替える必要がありません。ただ思い出させてください... CSSのフォーマットは基本的にコード内のオブジェクトリテラルと同じです。 CSSではなく、いつでもコンポーネントをコードでフォーマットしたいと思います。個人的には、1つのシステムで作業する方がはるかに簡単です。
インターフェースのスクリーンリーダーの結果の観点から-多くのキャンバスの作成は視覚障害者には適していません。指摘されているように、該当する場合は引き続き実行できます。
最後のコメント...consistencyは重要な設計原則ですが、variety人生のスパイスです。均質なインターフェースシステムに依存すべきではないと思います。成長、実験、探査の余地があるはずです。
私たちはこのようなことを試しましたが、ついに世界はまだ準備ができていないという考えを思いつきました）
次のことを覚えておく必要があります
- jsは常に有効にする必要があります。今日ではそれは大したことではないと考えることができますが、それでも言及する価値があります。
- html/cssは実際には伝統的であり、常に進化し続ける標準のスタックです。遅かれ早かれ、キャンバスレンダリングされたUIコンポーネントで繰り返されるコードを削減するための記述言語が必要になると感じます。そしてここには2つのオプションがあります-独自の何かを発明しようとすることです。 2番目の方法は、サードパーティの開発者を混乱させないようにhtml/cssを再実装することです。しかし、ちょっと待ってください、私たちはすでにhtml/cssエンジンを持っています）））
- イベント、したがって、ユーザーエクスペリエンス。ジョナスは正しい。 jsイベントモデルのサブセットでさえ再実装して、キャンバスレンダリングコンポーネントの開発をより快適にすることは困難です。いくつかの問題は解決できません。
だから、実際には面白い経験ですが、お勧めしません。
それは悪い考えのように思えます。ユーザーが期待する多くのアクセシビリティが失われます。フォーカスとタブ。または、それをすべて実装するのは大変な作業になります。
そのような場合は、HTML5とCSS3を使用する方がはるかに優れています。利用可能な多くのJavaScript GUIフレームワークがあります。 15 Javascript Web UI Libraries、Frameworks and Toolkits を参照してください。
これが私がこれを選択する理由です：
私の履歴書はすべてのブラウザで同じように表示されます。
Go（Google Go）プロジェクトでコードを再利用できます。私はSFMLを使用してピクセルを設定しているので、「賢い」ものを何も試さない限り、コードは簡単に転記できます。
それは良い習慣であり、車輪を再発明することは悪いことですが、誰かがこれを行う方法を知っている必要があります。