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

> 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. 

The DOM is an API. It is actually more than that in that it is a robust data model built upon the definitions of W3C Schema and various access requirements in the Level 3 and Level 4 specifications. Without a doubt the most important component of the DOM is its API, though. Like any API there are only 3 things that matter: convenience, performance, and integrity.  I would say enhancements that speak to the spirit and nature of the technology and sufficiently achieve all of the primary design targets are sufficiently worthy of evaluation based purely upon the technical merits of the technology proposed.

I was recently reading that the patent for the telephone was offered for sell to Western Union. They were not interested and considered the technology a mere electronic toy with no potential. A fledgling noname company called AT&T raised capital to purchase the telephone patent.  The problem is that they did not evaluate the technology on its technical merits want the potential for disruption would allow. Instead, they were convinced a defensible position of their standing technology presented a sufficient cause to evaluate the future of their business according to the user market at present.

>  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.

querySelector is sloooow. It requires a separate parsing scheme to translate a string into acceptable DOM arguments that are then accessed in the way the DOM is normally walked using the standard methods. An access means that more closely resembles the standard DOM methods offers superior potential for optimization.

To say that no technology should be considered if alternate to the popular querySelector method is a halting conservative position for a group tasked with maintaining and improving upon an important technology. There are access means that querySelector does not solve for, and still require walking the tree.

> 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;

There are many ways to solve this problem without a new method, of which all are less convenient and some of which are less secure.

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

The code you provided is hardly trivial though.

querySelector became popular because of convenience. People could not be bothered to learn to walk the DOM. The method I propose is also a convenience method. It just happens to be more convenient than querySelector and more inline with the standard DOM conventions.

> Their order doesn't matter (they're explicitly unordered, in fact), they can't contain further structure (just text)

Most node types do not contain further structure, so this is hardly a distinguishing characteristic. In this case though, it is wrong. Attributes appear to only be a name value pair and are accessed as such, however attributes are described and constricted by property definitions. Therefore attributes are data structures unto themselves, even if more primitive than element nodes.

http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#cAttribute_Declarations

If we were only talking about HTML and ignored both forms and accessibility generally then I would say you are less wrong on this point.  The DOM has wider use cases than either HTML or XML.

The order of attributes is only irrelevant to their immediate peers on the same containing element, but their order is otherwise very relevant. Attributes immediately describe the element on which they reside and then describe descendent nodes unless challenged in the lexical scope model as walk down the scope chain. As such the order of attributes, among other attributes not on the same element, is very relevant.

> 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

That is not accurate. The W3C DOM Level 2 specification is based immediately upon types in the XML Schema specification and differs only as necessary to absorb certain qualities from DOM Level 1 and provide some additional backwards compatibility. Years ago I used to spend a lot of time in the W3C Schema mailing list when I was writing my own markup language. XML Schema and W3C DOM fall under the same architectural committees and used to intentionally publish spec updates in pretty close proximity.

Attribute nodes are an intentional type because of how attributes may be defined by schema or by namespace. To eliminate attributes as a type means that attributes cannot be defined apart from the elements on which they reside. This invalidates design considerations of these technologies and interferes with the scope model and document extensibility.

> 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.

I will neither agree nor disagree with your opinion. I will only say that the technology is already defined and supported by the DOM. Before the example becomes invalid this technology must sacrifice some backwards compatibility.

> If you want more text nodes, you just walk the DOM.

You certainly could, but its less convenient. If not for convenience why would anybody use the querySelector method?

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