This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is just a general comment that I would hope that interfaces such as those at http://www.w3.org/TR/dom/#dom-core would not be removed unless there was some critical reason to alter or remove support for them such as to harmonize conflicting browser implementations. In the spirit of what I thought was the reason behind the rejection of XHTML 2 in the first place, it makes sense to add features without breaking compatibility. Just because attribute nodes or such are not all the rage does not make it fair for the minority of applications that use them. I hope we can be tolerant and be forward-looking where we can allow posterity to see or use very old applications as time goes forward without needing a re-write. Unlike platforms such as browser extension APIs which seem to gleefully leave minor developers in the dust by frequently changing their APIs and forcing them to accommodate, I would hope that at least HTML would continue on in the relatively stable form it has. I also feel that it is important to keep the precedent now of avoiding breaking changes so that future implementers will not be tempted to refer to breaking changes now as "acceptable losses" and instead preserve a tradition of making the web continue to work for everyone. If there are optimization or memory benefits to removing the interfaces, perhaps an HTML equivalent to JavaScript's strict mode could be added (though the empty DOCTYPE would not be adequate to this purpose since apps have already been built relying on it while still using the older interfaces).
Brett, I’ve done a lot of front-end web development since the late 1990s, so I can empathize with your position. It’s no fun going back to re-write code that worked just fine until support for a feature in an API changed or went away. However, I hold the opposite opinion. In the past year, I’ve begun development on a new desktop application that’s an SVG-based drawing program for Windows Metro. Without boring everyone with the details, I’m bringing up a new implementation of the DOM 4 and SVG 2 specifications in “modern” C++ for this project. As I sat down to implement the DOM, I started with DOM 3 since that is the current official recommendation. As I went through the DOM 3 specification I was asking myself why there was so much superfluous functionality? The answer, as I see it, is fallout from the browser wars and front-end web development, being a new shiny thing, caused the DOM 3 specification to include what everybody wanted, but not necessarily what everyone really needed. When I looked at the drafts of the DOM 4 specification I thought, ‘Yes, this is the direction they needed to go!’ It’s been ten years plus since the DOM 3 recommendation and, in that time, front-end web development has had a chance to mature somewhat. Now that we have a better idea what everyone needs in the DOM, it’s a good time to refactor it down to a more concise, core functionality. This will stabilize the API for the long term. I can’t think of anything one can do in DOM 3 that can’t be accomplished in DOM 4. So, personally, I won’t miss any of the nuked features. That’s my two-cents worth.
Brett, most of the features listed there (though use https://dom.spec.whatwg.org/ as reference) were never implemented to begin with. Or were implemented in a broken manner. So what to keep and in what way is not as easy as you put it. If you want to have a generic discussion about this feel free to raise it on www-dom@w3.org. Until we have some actionable feedback I don't think bugs are the right place.