Deprecate some DOM methods?

[mbostock]

Proposed: we deprecate the following methods in favor of the html or svg tagged template literal.

• DOM.canvas
• DOM.element
• DOM.input
• DOM.range
• DOM.select
• DOM.svg
• DOM.text

None of these methods are especially helpful, so I think it’s pretty much always more idiomatic to use literal HTML. By deprecating, I mean these methods would continue to be supported in the standard library, but we would remove their documentation from the README, or at least relegate them to a deprecated section.

(That leaves DOM.context2d, DOM.download, DOM.uid, for those keeping score.)

[tmcw]

👍 I think DOM.svg and DOM.range still get a lot of usage, even in new notebooks that we've been writing, but - sure, these are non-essential.

[jashkenas]

I'm moderately fond of those methods because I have a general aversion to string interpolation where it can be avoided — so that

DOM.canvas(width, 500)

...feels a little better than

html`<canvas width="${width}" height="500"></canvas>`

... but I certainly see your point.

Yes, we should deprecate them by removing the documentation — but it seems like there's no harm in leaving the actual methods around.

[mbostock]

You can shorten it slightly…

html`<canvas width=${width} height=500>`

[danburzo]

Could we salvage the attributes part of DOM.element, maybe as DOM.attr?
It has some useful logic around namespaces that would provide benefits over doing setAttribute / setAttributeNS manually on DOM elements that were previously created — not a big deal, and maybe too jQuery-esque?

Edit: I put it here for personal usage

[mbostock]

DOM.svg came up as an unnecessary impediment to adapting D3 examples to vanilla JavaScript. Other than require, DOM.svg is the only stdlib method used by most of the D3 examples. And it’s trivial to replace

d3.select(DOM.svg(width, height))

with

d3.create("svg").attr("viewBox", [0, 0, width, height])

which is (sufficiently) equivalent.

This, to me, is strong evidence that we should make the standard library as small as possible.

[mootari]

I believe DOM.element is still relevant, as it facilitates attribute composition and escaping. Some of the issues with template strings are outlined here: https://observablehq.com/@mootari/attribute-escaping-in-template-strings

That being said, personally I could survive on html alone if text nodes in attribute values were properly handled.

[mbostock]

Yes, I want to switch our html tagged template literal implementation to use hyperscript #94 or something else (such as htm), so that it can escape by default and also support event listeners and other important things. I still think DOM.element and friends should go, though. But we’ll need to implement standard library versioning as the change to html will not be backwards-compatible.