-
Notifications
You must be signed in to change notification settings - Fork 83
Add support for AJAX content #125
Comments
@shogun70 thanks for the detailed suggestions! Here are some of my thoughts:
|
In HTML5, parser added scripts (which in this context means script tags added using document.write()) are the only scripts with a guaranteed execution order. Script elements added using DOM methods like Node.appendChild() offer no guarantees about the order in which things will run. Further, using document.write() to output scripts means that those scripts themselves (say, ad tags) can also call document.write() safely, without destroying the document. |
Hi @noahadams.
|
Hi @jansepar. I can see that my issue statement didn't provide a very good context for what I was suggesting. I'll do that now. I guess the main thing I'm trying to say is I don't like the Mobify API. The code does great stuff, but the API is all about capturing the landing page. This is all upside-down - capturing the landing-page is a small part of what Mobify should be. The Responsive DOM Preprocessing is the central thing. Capturing is important for now only because you can't fetch that landing-page with XMLHttpRequest. But in a It is also worth noting that even the landing-page can be fetched with XHR if it is cached. This could be another option given to the site author. |
@shogun70 - I think this is a great suggestion - it would be awesome to use Mobify.js' transformations with something like PJAX. I think the immediate next step is to try combining Mobify.js with something like jquery-pjax and see what glue code is required and if there are any blockers - eg. our use of |
Feature suggestion: Mobify only supports capturing the landing-page. However AJAX and PJAX (pushState + AJAX) loaded content could benefit from the same capability.
My proposed functionality for Mobify has the following:
HTMLParser
Looking forward, the HTMLParser will be part of the browsers XMLHttpRequest. In IE8 and below it would be nice to enable html5 elements. Also, in IE9 and below the mere creation of
<img src>
downloads the resource, so it would be necessary to escape@src
before parsing.DOMProcessor
I suppose this contains a bunch of optional convenience rules, and the capability for externally provided processing.
Glue
document.write
is a mistake. Mobify generates a DOM - just insert that into the window document. Scripts will need special handling, but that is potentially a win because it allows you to schedule their loading / execution. At least allow this to be controlled externally.<a href class="image">
. People who use this approach might still prefer mobify if it could do in-place DOM-processing (instead of capture-to-external-document-then-rewrite-page).The text was updated successfully, but these errors were encountered: