You can target canvas with d3, but you loose much of the abstraction that makes d3 powerful. For example, look at all of the low-level canvas rendering code that is used. Not as powerful as visualizations driven by chaining .data().enter().append().attr() which can easily be re-shaped by swapping html tags and CSS attributes.
d3 really is a three-legged stool of HTML, JS and CSS. When targeting <canvas>, you loose both HTML and CSS and thus much of the power.
EDIT: I should clarify that I'm thinking of HTML in an abstract sense that also includes SVG. By hooking into the DOM, d3 gets a free scenegraph that makes it easy to modify the components of the visualization without writing low-level code.
Examples in the core library, all compatible with Canvas, include scales, layouts, geographic projections, time/color utilities, CSV/TSV loading, and behaviors (drag/zoom/etc). There's some built-in canvas rendering like d3.geo.path which can be provided a canvas context.
The only things you lose are selections and the convenient transitions that go along with selections. But you can use these to modify and transition the canvas elements themselves!
In most cases you also loose the ability to specify graphic components declaratively through .append() and .attr(). Instead, you must imperatively specify how to produce the drawing from the data by manipulating the canvas context.
I have use d3 to create composite graphics that included elements rendered to canvas and it certainly is powerful. But, I still believe that the sweet spot of the library requires being able to work with the DOM and CSS.
d3 really is a three-legged stool of HTML, JS and CSS. When targeting <canvas>, you loose both HTML and CSS and thus much of the power.
EDIT: I should clarify that I'm thinking of HTML in an abstract sense that also includes SVG. By hooking into the DOM, d3 gets a free scenegraph that makes it easy to modify the components of the visualization without writing low-level code.