[whatwg] At Inclusion (a declarative way to "Ajaxise" a website)

Mon Jun 18 13:51:50 PDT 2012

Le 18/06/2012 01:55, Peter Beverloo a écrit :
> On Sun, Jun 17, 2012 at 10:32 AM, Florent FAYOLLE 
> <florent.fayolle69 at gmail.com <mailto:florent.fayolle69 at gmail.com>> wrote:
>
>     Hello,
>
>     I have written a proposal that introduces a new way to include
>     remote contents into the document (in other (bad) word, to
>     "Ajaxise" it) using a declarative way.
>     This proposal is named At Inclusion, and can be read here :
>     http://fflorent.github.com/At-Inclusion-Proposal/
>
>     To rapidly sum up, At Inclusion is a part of the URL that
>     describes pairs. Each pair is composed of :
>      - the ID of the target element (the element that gets the remote
>     content);
>      - the URL leading to the content to include.
>
>     and the At Inclusion has this form :
>     @TARGET_ID1=URL1,TARGET_ID2=URL2...
>
>     For example, let's suppose we have this main document (located at
>     http://myserver/mypage.html) :
>     <html>
>     <head>...</head>
>     <body>
>            ...
>     <a href="@myTarget=/myaddition.html">click me</a>
>            ...
>     <div id="myTarget"><p>default content here</p></div>
>            ...
>     </body>
>     </html>
>
>     and the content to include in myTarget (located at /myaddition.html) :
>     <p>hello world</p>
>
>     By clicking on the link, the HTML code of #myTarget will be
>     replaced with this one :
>     <div id="myTarget"><p>hello world</p></div>
>     and the new location of the page will be :
>     http://myserver/mypage.html@myTarget=/myaddition.html
>
>     Feedbacks welcome.
>
>     Thanks,
>     Florent
>
>
> Without having read your proposal in detail, it seems like seamless 
> iframes in combination with <a target> should address the majority of 
> your use-case:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless
>
> There is no way to map a parameter from the request URL to the 
> iframe's source without JavaScript, however, but personally I don't 
> think there is a necessity for a non-JavaScript way of doing that.
>
> Peter
That seems to cover a part of the use-case, indeed.
However, using Javascript instead of a declarative way to update the 
URL, I think, have a major drawback: ensuring the indexation is not 
trivial. For Iframes, I read that Google even recommend to avoid to use 
it: 
http://support.google.com/webmasters/bin/answer.py?hl=en&query=iframe&answer=72746#4

Thanks for having taken a look.