XHR attributes

[Ofer Ohel]

Hi, 

I'm a newbie to these types of forums so please forgive me and ignore this if it's an old idea, but here it goes.

Browsers should implement attributes for common ajax requests. For example:

<a xhr:href="myurl.com" xhr:callback="my.method" xhr:trigger="click" xhr:scope="{foo: 'bar'}">

Would:

 - send request on click

 - execute the callback with {foo: 'bar'} as its context

These attributes will work on any html element, but if the <a> tag has an href attribute and the xhr:trigger attribute equals to "click" then the default action will be prevented.

Basically what I'm proposing is to have the browser natively do what jquery, dojo, and extjs do. Browsers already have the ability to xhr, so implementing these attributes removes the need to use Javascript to select elements, attach events, and normalize xhr calls.

I think these four attributes should handle everything that's needed:

• xhr:href   => The request url
• xhr:callback => The name of the Javascript method to execute (doesn't have to exist when the attribute is parsed)
• xhr:trigger => The event that triggers the request (defaults to 'click')
• xhr:scope => The context that the callback will be called with (defaults to the element)

Any thoughts?

[Domenic Denicola]

This sounds like a great library waiting to be written; you should totally write it!

[Eli Perelman]

What are we gaining here?

Is it normalized XHR? Browsers will implement this differently according to their idiosyncrasies so it can't fix that. 

Is it automatic default action prevention? This seems to be a lot of overhead for needing to do preventDefault. 

Is it simplicity of XHR handling? If you take a look at all of the functionality provided by jQuery.ajax that would be either a lot of functionality to extend into the DOM or what little you do inject into the DOM not be feature rich. Not to mention a violation of separation of concerns between JavaScript logic and the presentation layer. 

Given these issues I would say -1. 

Eli Perelman 

[Jake Verbaten]

<a xhr:href="myurl.com" xhr:callback="my.method" xhr:trigger="click" xhr:scope="{foo: 'bar'}">

Wait what? More inline javascript in my HTML.

NO. doing it wrong -1

[Thomas Davis]

Agree with the lack of separation of concerns and I think it just adds more cross browser problems that we would have to worry about.

-1

Though build it as a javscript library for those who like this style of programming, also check out Knockout.js

[Filipi Zimermann]

Rails already implemented this idea on their way...

This article explains their solution...

http://www.alfajango.com/blog/rails-3-remote-links-and-forms/

I agree with the others.

It is work for a library.

No mo JS in the DOM.

-1

--
Filipi Zimermann
http://www.nextt.com.br/
Mobile: +55 (48) 8479-7900

Office:  +55 (48) 4052-9556

[scott gardner]

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.

Obviously browser do xhr differently, dojo, jQuery, etc handle this for us currently but if their was a standard for xhr requests via DOM attributes we as developers wouldn't care how the browser handles it, just that it accepts the attributes, makes and xhr request and calls our callback.

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.  A few years ago you had to use JS to accomplish any transformations. Well we as developers hated this because it was slow and the API changed with each library.  So we pushed for standardization and hence it was moved into CSS3 and the browsers were given the responsibility of building those features into their code. As developers we don't care how MS or Google make it happen just that our interface into those features are similar and the outcome is similar. 

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.

I like it +1

[Eli Perelman]

And if a user has JavaScript disabled?

That's why we have the mechanisms we currently have. For instance, take the form tag:

<form action="/resource/12345" method="post">

    <input type="hidden" value="cheese" />

</form>

This form contains all the data we need to make a request to the server: a URL, HTTP verb, and all of its data contained in form elements.

If a user doesn't have JavaScript enabled, this form just triggers a post to the server and we are sent on our merry way.

But if a user has JavaScript, we can progressively enhance their experience to avoid trigger a page load, by intercepting the form submission, serializing the form data as necessary, executing an XHR request, and preventing the default action. We can update our UIs once the request has completed.

There is nothing that this concept provides that HTML and JavaScript already provide to us, and it already works in a progressively enhanced environment.

Still -1.

Eli Perelman

[Scott González]

On Thu, Oct 27, 2011 at 7:43 PM, scott gardner <scott.p...@gmail.com> wrote:

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.

Perhaps you don't realize that making an ajax request is only six lines of code. Keep in mind that you have almost zero flexibility with the proposed API. You certainly don't need jQuery or dojo or any other library to help you write the following code:

var xhr = new XMLHttpRequest();
xhr.open( "GET", "sandbox-xhr.html", true );
xhr.send();
xhr.onreadystatechange = function() {
    if ( xhr.readyState === 4 ) {
        callback( xhr.responseText );
    }
};

Before you say, "but that doesn't work in every browser" remember that that is a request for a brand new feature that currently works in no browsers at all. Getting the standard API and any known bugs fixed in existing implementations will happen way sooner than a brand new API.
  

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.

How is <a xhr:callback="foo"> not at all like <a onclick="foo">?
 

as a point of reference how would this be different than browsers standardizing on CSS3 transformations.

Because transitions are purely style related.

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.

You don't need to wait for the page to fully load to add event listeners. You don't even need to wait for the DOM to be ready. This could (and should) easily be built using event delegation.

[scott gardner]

Good pt, so we modify the html syntax a bit and change the spec to state that if JS is off follow the href value.So the html markup could be something like

 &lt;a href="someurl.html" xhr:src="someurl.html" xhr:callback="myfunc" &gt;Link&lt;/a&gt;

It is progressive enhancement!

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.

[scott gardner]

and this allows code so the html markup would be

<a href="someurl.html" xhr:src="someurl.html" xhr:callback="myfunc">Link</a>

[Scott González]

On Thu, Oct 27, 2011 at 8:06 PM, scott gardner <scott.p...@gmail.com> wrote:

The whole point is to remove the reliance on libraries

Again, it's six lines, there's no reliance on libraries here.
 

and/or developers having to address the fact that IE and every other browser do xhr differently.  convenience is the justification.

Then you should be asking of the APIs to be fixed, not for new APIs to be built.

[scott gardner]

so I may have been off on the whole not like onclick, however that is a minor overstatement on my part.  The jist of the idea is convenience, and yes an xhr request can be boiled down to 6 lines of code and yes event bubbling doesn't require the dom ready or onload events to be set up.

However in both cases developers are being asked to write additional code to handle xhr. and if your having multiple elements on the page your Js logic for the event delegation gets a a bit longer and your 6 line xhr request needs additional code to handle the changes to the callback function and the src or href.  True its not gonna kill us to write it.. but if given the chance are you honestly saying that you want to write it?

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?

[Eli Perelman]

Totally agree with Scott. XHR is a feature of JavaScript and mixing HTML with the ability to execute JavaScript directly is a reason we don't use onclick anymore. The separation of concerns is still being violated.

Eli Perelman

2011/10/27 Scott González <scott.g...@gmail.com>

[Rick Waldron]

All of the previous concerns, with the addition that xhr:scope is a security concern

---

[Dave Methvin]

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?

 

If someone wanted to experiment with this they could build it in Javascript to prove its worth, there is no need to involve a standards body. jQuery Mobile already enhances pages like this without the need for specially defined attributes (it uses data- attributes) so perhaps that would be a good initial study. But it seems outside the standards arena until it's proven.

Just to keep us all focused, remember that there are already standards in progress for several important things. They don't have our input but are going to eventually be completed whether we say something or not. HTML forms and touch events seem like two good ones. Let's not spend time trying to reinvent things that already work, and make sure that the things that are coming work the way we want them to.

[Eli Perelman]

There is a difference between saving time and having modular, maintainable code. Sure this might save some time, but I prefer to have my applications architected where I can manage presentation in one area and functionality in another. We are not saying that this wouldn't be a time saver, just that a tradeoff exists between saving time and writing well-architected applications.

My two cents,

Eli Perelman

[Scott González]

On Thu, Oct 27, 2011 at 8:20 PM, scott gardner <scott.p...@gmail.com> wrote:

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.

[Rick Waldron]

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.

The fact is that this proposal is a regression across the board.

The argument that it will work in browsers that have JavaScript disabled is laughable at best, negligent at worst. What do you think is going to execute your callback? Evaluate your "JSON"? (which isn't valid JSON btw) The list can go on.

This thread has blown out signal to noise on this mailing list. Let's try to focus on realistic, progressive improvements.

[Yehuda Katz]

fwiw, I actually think the XHR API could be improved.

var xhr = new XMLHttpRequest("GET", "sandbox-xhr.html").send();

xhr.oncomplete = function() {

  callback(xhr.responseText);

}

Yehuda Katz
(ph) 718.877.1325

2011/10/27 Scott González <scott.g...@gmail.com>

[Jake Verbaten]

A lightweight barebones XHR mechanism is called XHR2. We already have that. We don't need hacks in HTML to do this.

 

I like it +1

[Alex Ivasyuv]

I think it's a bad idea to mixup markup & logic.

HTML - it's for semantic descibe data, and how it show works - it's a JS logic.

In your case, you returns to back away when developers used to inline for style and JS.

You HTML shoudn't know everything about JS, only JS should know about HTML.

[Ido Green]

+1 on that...