I'm not sure this is such a bad idea. wouldn't we as developers want browser to implement functions that we rely on everyday rather than having to include some library like jquery or dojo etc. An argument can be made that adding arbitrary attributes to DOM nodes is poor, but it is widely accepted and complies with current and HTML5 standards to use namespace attributes.
Adding attributes which look like JS is merely a consequence of taking something like xhr out of the Javascript realm and placing it into DOM. To the argument that separation of logic and presentation is necessary, this proposal doesn't cross that line at all. no where in those attributes is logic performed and they are non presentation attributes meaning they don't impact the UI of the element, it is completely NOT like adding an onclick or style attribute to your element.
as a point of reference how would this be different than browsers standardizing on CSS3 transformations.
Moving a lightweight barebones XHR mechanism into the browser would allow a) developers to not use a library in some cases b) users to click a link without having to wait for page load for some event listener to be added.
The whole point is to remove the reliance on libraries
and/or developers having to address the fact that IE and every other browser do xhr differently. convenience is the justification.
Based on the replies I'm gathering that those opposing the idea would never make use of it nor have come across a use case where it would have saved you some time?
True its not gonna kill us to write it.. but if given the chance are you honestly saying that you want to write it?
Yes, I'd rather choose the option that doesn't involve creating global variables for callbacks and sticking JSON inside
attributes. I'd also choose the option that gives me an error handler, the ability to choose between a GET and a POST, the ability to send headers, etc.
I like it +1