- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 19 May 2011 16:16:51 -0400 (EDT)
- To: Julian Reschke <julian.reschke@gmx.de>
- cc: ashok.malhotra@oracle.com, Karl Dubost <karld@opera.com>, Syd Lawrence <sydlawrence@googlemail.com>, Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org" <www-tag@w3.org>
On Thu, 19 May 2011, Julian Reschke wrote:
> On 2011-05-19 20:06, ashok malhotra wrote:
>> Yes, you need JS to create the URIs to identify the state. However, once
>> the URI
>> is created it can be sent to and will work with browsers that do not
>> support JS.
>> In addition, the newly created URIs can be tracked by Google search
>> engines and
>> web crawlers.
>> All the best, Ashok
>
> Hm, no.
>
> When the state is encoded in the fragment, then a non-JS-enabled browser will
> not be able to process that part.
It depends on that "state encoded in the fragment mean"
https://code.google.com/web/ajaxcrawling/docs/specification.html
Defines a mapping between URIs with fragments starting with #! and
equivalent URI using '?' and _escaped_fragment_. Allowing UAs that are not
JS-aware to crawl them, but they must know in that case that all fragments
starting with #! have another equivalent.
So non-JS aware and non 'ajaxcrawling' aware UAs are still left behind.
It means that if you want to create a fragment syntax for your new media
type application/vnd.foobar, then you must know in advance that starting
with '!' will collide with ajaxcrawling definition.
If #! is transformed, then it will be done before knowing the media type
of the fragment URI. Once again, the same issue as with RDF on the
fragment semantic if the URI is dereferenced or not.
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Thursday, 19 May 2011 20:16:59 UTC