-
Notifications
You must be signed in to change notification settings - Fork 46
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
Deal with comment nodes #18
Comments
this is not a library, it's a polyfill which aim is to bring standards as meant / documented in browsers that don't support one or more features. Accordingly, if there are methods that should be on Comments too, I will follow your hint or find a better solution, but if this is not documented or meant like that, you should complain with WHATWG and not with this polyfill. Which one is this case? |
https://dom.spec.whatwg.org/#interface-childnode
You implemented only for Element, but in spec there are also DocumentType and CharacterData |
Closest parent interface for all of them is Node. If you want to live with spec, you must test before/after/replaceWith/remove props in any of DocumentType/Element/CharacterData interfaces and polyfill them in all of them. Otherwise document, fragment and comment nodes are abandoned... |
I don't think anything can possibly happen if I append to a |
I think the most effective way is to add all of these methods explicitly to Node prototype without any check. If there will be remove/prepend any other method in Comment, Element, Document, DocumentFragment prototype, the same named method in Node prototype will be overwritten by upper prototype. |
OK, this might sound like a silly question: if you think all dom4 needed was to just use Node instead of Element or HTMLElement, why didn't you just PR that? I am all in to make this poly work at its best so don't take my question wrong, I am trying to understand if you are aware of some side effect that might be caused by such change. Thanks |
Sorry, I`m a little bit messy, last commit 85b6232 shows what I mean: we put all methods in Node proto. |
OK I am traveling these days but I've given a spin to the logic and read more details about those interfaces. TL;DR I don't think using Moreover, stuff like Accordingly, I think the current way I am moving forward is to fix explicitly before|after|replace|remove in This will de-facto pollute Would this work for you? |
P.S. you can see the test with comment ( very basic one ) in the test page If you can verify it works with your target browsers I might just flag and push to npm and cdn. Thank You |
I'm new to gh-pages, but l'll try to setup new test at http://qiv.github.io/dom4/test |
My last change fallbacks to Node but it uses spec-compliant constructors/prototypes to bring in those methods. Does this work? |
It seem like everything is fine. |
Why only Element prototype is used when polyfilling dom4 methods? I have library where comment nodes are used. remove/append and other sugar stuff is not available for them. Now i just swap Node and Element
ElementPrototype = (window.Node || window.Element || window.HTMLElement).prototype
I understand that these methods are written just in Element proto in spec, but it is inconvenient for document nodes that does not implement Element prototype...
The text was updated successfully, but these errors were encountered: