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

>  It's a bit of repetition, but this is also a pretty rare case, so that's usually okay.

At this time all the examples I presented are extremely rare use cases. I would say they are all edge cases merely because the means and availability do not exist natively or conveniently. This is like saying cell phones should would never become popular because at one point they were rare and expensive like every other emerging technology.

> What's your use-case for getting comments from the DOM more easily?

Comments can store any format and size of text data, so therefore it could store JSON formatted data for any use case. It could also conveniently store dynamically constructed configuration data from a page server for use in third party services, which benefits analytics, testing, and evaluation services.

> Your example use-case for attributes

One example is immediately gathering all `id` attributes from a page for discerning possible duplicate values. Duplicate `id` attribute values represents functional limitations and accessibility barriers in HTML, particularly in the presence of forms and in page navigation.

Another example is to immediately gather all `src` attributes to determine if there are errant requests, duplicates, various domains, request quantity, and so forth.

> As well, the fact that attributes are nodes is a legacy mistake that we want to forget as much as possible.

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? I would argue they are perhaps more worthy of node consideration in that they store parse-able data that describes both the immediate element and possibly children/descendents in that element.

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.

> If you want all the text in an element, the best way is to use el.textContent

You are still limited to a single node's text in this manner. 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.


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