Re: [dom] Consider new method: getNodesByType (#37)

> I would say they are all edge cases merely because the means and availability do not exist natively or conveniently.

This is a *very* difficult argument to make convincingly; there are *tons* of things that one could *imagine* would be more popular if they were easier to do, but that doesn't mean we should make them all easier.  We have a finite amount of coding effort to spend, and large APIs are harder to learn and use.  One has to have a pretty remarkably strong case, generally showing that people are working around the lack in some hacky ways, to justify adding this kind of surface.

That said, this *isn't* one of these cases.  It's not hard to iterate over nodes; people used to do it all the time.  These days people almost never do it, because querySelector() solves nearly all of the use-cases.  That suggests that (a) we *can* tell if people need some particular type of node-querying functionality, because they'll be doing a lot of manual iteration if so, and (b) because there isn't much of that going on, it must not be that common, and thus probably not worth adding new API surface.

> Comments can store any format and size of text data, so therefore it could store JSON formatted data for any use case.

This is already doable in any number of ways: putting it in a `<script type="something/custom">` and parsing the textContent out later; putting it in a normal `<script>` and just directly assigning the JSON blob to a variable; putting the JSON blob in an attribute on some element; etc.  It doesn't immediately appear that we have much need for an additional method of achieving this, particularly if we have to add more API surface to make it convenient.

> One example is immediately gathering all id attributes from a page for discerning possible duplicate values.

This and your `src` example are both trivially doable today with `querySelector()`, as I indicated above:

```js
var ids = [].slice.call(document.querySelectorAll("[id]"))
    .map(function(el){return [el.getAttribute("id"), el];});
```

> Why? It seems perfectly valid for attributes to be DOM nodes as children of elements in much the same way that text are DOM nodes as children of elements. What makes attributes less worthy of node consideration than textual content?

Their order doesn't matter (they're explicitly unordered, in fact), they can't contain further structure (just text), they don't have any intrinsic relationship between each other (unlike text/elements which are siblings), they don't live in an element's `.childNodes` list (comments/text/elements do).  In practice they're just a String=>String dict hanging off an element.

The only reason they're Nodes at all is a mistaken attempt by early XML/SGML folk to make the distinction between an attribute and a child element containing text less apparent, as many vocabularies make a more-or-less arbitrary choice between the two for simple data.  This blurring makes no sense in HTML, where attributes and content are mostly strongly delineated.

> More important still is that attribute names are subject to namespace inheritance apart from the containing element. Therefore attribute name definitions are subject to lexical scope in exactly the same manner as element names and independently so.

XML Namespaces are a terrible solution to the composing-languages problem to begin with, and namespaced attributes are a hack compounded on top of that.  This does not reflect well on them.

> You are still limited to a single node's text in this manner.

Yes?  Your example was complaining about having to use `.innerHTML` to get at the text; `.textContent` is the correct way to do the same thing.

(And note, `.textContent` gives you the text of this element *and its descendants*, joined in tree order.)

> Although it is possible to get broader text nodes by walking up the DOM tree the means of access is still limited and less immediate. Limits upon means of access produces second and third order consequences into software design, readability, and stylistic considerations that makes code easier to share and understand.

If you want more text nodes, you just walk the DOM.  As I said at the beginning of this comment, DOM-walking used to be *very* common; when we introduced `querySelector()` it dropped off significantly.  If there was still a lot of interest in getting text nodes specifically (or any other type) it would show up in current DOM-walking usage, but it doesn't.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/37#issuecomment-106610746