-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add DOM - core, events, ranges, tree walker etc #2007
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm feeling pretty positively toward this so far. I'm inclined toward lumping more stuff into the DOM feature itself (Node, Element, and maybe querySelector), which I've noted in a few places. But this is a good outline of what to do with a LOT of keys.
Implemented the DOM rollup approach, and review feedback integrated. Edit: Er, and subsequent files updated also. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since Dietrich is on holiday, I'm going to take this one over, since I think this is quite close to landing. Leaving some notes for myself.
OK, I've tidied this up a bit and I think it's ready for another reviewer. Some notes on key changes I made from what Dietrich originally did:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! Just one thing that I wouldn't have put in the DOM kitchen sink.
See #1380 for discussion on DOM as a standalone feature, ranges, etc:
Looking at the spec-generated DOM draft, some thoughts and questions:
addEventListener
,passive: true
,CustomEvent
,EventTarget.dispatchEvent
and moreDocument
,DocumentFragment
andDocumentType
are proposed features in Add document, document fragment, document type #1983MutationObserver
seems standalone and Caniuse treats it that way tooNode
andElement
keys together have so many "use it 10,000 times per day" APIs, could be a standalone feature probablyHTMLCollection
,NamedNodeMap
,NodeList
, NodeIterator` - if we go big-dom-feature, could leave them all in there, for now at leastAttr
,Comment
,CharacterData
,Text
etc, some of which will align w/ their HTML spec counterparts - these each seem like standalone features of the webAside from the list-ish bits, there's not much left for a standalone DOM feature if we do the above... and those might actually be ok living in
Document
.