Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why isn't it better to redefine insertBefore of an already inserted element to being state-preserving? If I want to kill state, I can do a remove first.


This would break the WEB. JS DOM bindings are a backwards-compatible public API.


I reject that claim as-is. In what situations would it break? Standards evolve. Changes to cookies, iframes, newly required HTTP headers all "broke" the web. Not to mention Flash deprecation. But somehow we survived.

Sure, this would theoretically be a backwards incompatible change. But if no one is using insertBefore without really meaning moveBefore, it's not a concern in practice.


You're both denying it would break, and saying it's okay for it to break, which are contradictory arguments.


Putting it your way, I'm saying it might break short-term, but long-term it would be fine.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: