I've been closely following ControlJS from its creation. I really like
the approach that it takes to async loading, but after doing a lot of
testing I found that the document.write wrapping was kind of a crap
shoot (especially when it comes to pesky little things like
advertisements).
I have started development on a library that takes the same approach
to enabling asynchronous pre-caching and synchronous execution of
scripts as ControlJS (in fact, it started as a fork), while also being
almost 100% document.write compatible.
The library attempts to buffer document.write calls and parse them as
closely to the way that a browser parses the original document as
possible, creating and inserting all new nodes using post-load-safe
DOM tree insertion methods. Using this technique, the library can
correctly load many obscure scenarios that the span + innerHTML
technique doesn't accomodate well for.
It's kind of a behemoth right now, but I'm working on slimming it
down. Anyway, I wanted to put the word out there about this, and I'd
love to get some feedback from any of you on what you think and / or
how it could be improved!
I haven't tried it out, but it looks like you're trying to parse input as it arrives and create DOM nodes immediately, right? Sounds very cool, I hope you can make it work. My lib waits for completion for the most part, but there is a class of script (that use DOM and document.write for some reason) that is tough to work with. Your approach looks promising. Have you looked at John Resig's HTML parser? http://ejohn.org/blog/pure-javascript-html-parser/
That might be able to cut down your code size a bit.
On Fri, Apr 8, 2011 at 2:11 PM, cdata <aar...@gmail.com> wrote: > Hello Steve and everyone else,
> I've been closely following ControlJS from its creation. I really like > the approach that it takes to async loading, but after doing a lot of > testing I found that the document.write wrapping was kind of a crap > shoot (especially when it comes to pesky little things like > advertisements).
> I have started development on a library that takes the same approach > to enabling asynchronous pre-caching and synchronous execution of > scripts as ControlJS (in fact, it started as a fork), while also being > almost 100% document.write compatible.
> The library attempts to buffer document.write calls and parse them as > closely to the way that a browser parses the original document as > possible, creating and inserting all new nodes using post-load-safe > DOM tree insertion methods. Using this technique, the library can > correctly load many obscure scenarios that the span + innerHTML > technique doesn't accomodate well for.
> It's kind of a behemoth right now, but I'm working on slimming it > down. Anyway, I wanted to put the word out there about this, and I'd > love to get some feedback from any of you on what you think and / or > how it could be improved!
> I haven't tried it out, but it looks like you're trying to parse input > as it arrives and create DOM nodes immediately, right? Sounds very > cool, I hope you can make it work. My lib waits for completion for the > most part, but there is a class of script (that use DOM and > document.write for some reason) that is tough to work with. Your > approach looks promising. Have you looked at John Resig's HTML parser? > http://ejohn.org/blog/pure-javascript-html-parser/
> That might be able to cut down your code size a bit.
> Cheers, > Noah
> On Fri, Apr 8, 2011 at 2:11 PM, cdata<aar...@gmail.com> wrote: >> Hello Steve and everyone else,
>> I've been closely following ControlJS from its creation. I really like >> the approach that it takes to async loading, but after doing a lot of >> testing I found that the document.write wrapping was kind of a crap >> shoot (especially when it comes to pesky little things like >> advertisements).
>> I have started development on a library that takes the same approach >> to enabling asynchronous pre-caching and synchronous execution of >> scripts as ControlJS (in fact, it started as a fork), while also being >> almost 100% document.write compatible.
>> The library attempts to buffer document.write calls and parse them as >> closely to the way that a browser parses the original document as >> possible, creating and inserting all new nodes using post-load-safe >> DOM tree insertion methods. Using this technique, the library can >> correctly load many obscure scenarios that the span + innerHTML >> technique doesn't accomodate well for.
>> It's kind of a behemoth right now, but I'm working on slimming it >> down. Anyway, I wanted to put the word out there about this, and I'd >> love to get some feedback from any of you on what you think and / or >> how it could be improved!
On Fri, Apr 8, 2011 at 3:53 PM, Steve Souders <st...@souders.org> wrote: > It's great to see these projects. I think parsing & applying the > document.write DOM in real time is key.
>> I haven't tried it out, but it looks like you're trying to parse input >> as it arrives and create DOM nodes immediately, right? Sounds very >> cool, I hope you can make it work. My lib waits for completion for the >> most part, but there is a class of script (that use DOM and >> document.write for some reason) that is tough to work with. Your >> approach looks promising. Have you looked at John Resig's HTML parser? >> http://ejohn.org/blog/pure-javascript-html-parser/
>> That might be able to cut down your code size a bit.
>> Cheers, >> Noah
>> On Fri, Apr 8, 2011 at 2:11 PM, cdata<aar...@gmail.com> wrote:
>>> Hello Steve and everyone else,
>>> I've been closely following ControlJS from its creation. I really like >>> the approach that it takes to async loading, but after doing a lot of >>> testing I found that the document.write wrapping was kind of a crap >>> shoot (especially when it comes to pesky little things like >>> advertisements).
>>> I have started development on a library that takes the same approach >>> to enabling asynchronous pre-caching and synchronous execution of >>> scripts as ControlJS (in fact, it started as a fork), while also being >>> almost 100% document.write compatible.
>>> The library attempts to buffer document.write calls and parse them as >>> closely to the way that a browser parses the original document as >>> possible, creating and inserting all new nodes using post-load-safe >>> DOM tree insertion methods. Using this technique, the library can >>> correctly load many obscure scenarios that the span + innerHTML >>> technique doesn't accomodate well for.
>>> It's kind of a behemoth right now, but I'm working on slimming it >>> down. Anyway, I wanted to put the word out there about this, and I'd >>> love to get some feedback from any of you on what you think and / or >>> how it could be improved!
I still like the FRAG tag idea. One of the arguments against it is that HTML5 iframes can do much the same thing. And we've seen Google AdSense use iframes to get asynchronous document.write to work. More work and not perfect, but it is possible.
> I haven't tried it out, but it looks like you're trying to > parse input > as it arrives and create DOM nodes immediately, right? Sounds very > cool, I hope you can make it work. My lib waits for completion > for the > most part, but there is a class of script (that use DOM and > document.write for some reason) that is tough to work with. Your > approach looks promising. Have you looked at John Resig's HTML > parser? > http://ejohn.org/blog/pure-javascript-html-parser/
> That might be able to cut down your code size a bit.
> Cheers, > Noah
> On Fri, Apr 8, 2011 at 2:11 PM, cdata<aar...@gmail.com > <mailto:aar...@gmail.com>> wrote:
> Hello Steve and everyone else,
> I've been closely following ControlJS from its creation. I > really like > the approach that it takes to async loading, but after > doing a lot of > testing I found that the document.write wrapping was kind > of a crap > shoot (especially when it comes to pesky little things like > advertisements).
> I have started development on a library that takes the > same approach > to enabling asynchronous pre-caching and synchronous > execution of > scripts as ControlJS (in fact, it started as a fork), > while also being > almost 100% document.write compatible.
> The library attempts to buffer document.write calls and > parse them as > closely to the way that a browser parses the original > document as > possible, creating and inserting all new nodes using > post-load-safe > DOM tree insertion methods. Using this technique, the > library can > correctly load many obscure scenarios that the span + > innerHTML > technique doesn't accomodate well for.
> It's kind of a behemoth right now, but I'm working on > slimming it > down. Anyway, I wanted to put the word out there about > this, and I'd > love to get some feedback from any of you on what you > think and / or > how it could be improved!
Actually, the parser we're using _was_ inspired by John Resig's
parser, but is not the same. The project for it is located here:
https://github.com/jtwb/node-htmlparser
Sadly our solution doesn't share the same compact size that
writeCapture has, so that's probably one of the first places for us to
start optimizing.
In general, there seem to be a lot of really tricksy document.write
scenarios out there. We've tried to start building tests for them
(available in the Domiante repo), and would definitely welcome
contributions!
Chris
On Apr 8, 1:11 pm, Steve Souders <st...@souders.org> wrote:
> I still like the FRAG tag idea. One of the arguments against it is that
> HTML5 iframes can do much the same thing. And we've seen Google AdSense
> use iframes to get asynchronous document.write to work. More work and
> not perfect, but it is possible.
> -Steve
> On 4/8/2011 1:06 PM, Dave Artz wrote:
> > Steve, whatever happened to the <frag> tag? :)
> > Seems like a lot of bulk to work around document.write, how are
> > browser manufacturers reacting to this problem?
> > On Fri, Apr 8, 2011 at 3:53 PM, Steve Souders <st...@souders.org
> > <mailto:st...@souders.org>> wrote:
> > It's great to see these projects. I think parsing & applying the
> > document.write DOM in real time is key.
> > I haven't tried it out, but it looks like you're trying to
> > parse input
> > as it arrives and create DOM nodes immediately, right? Sounds very
> > cool, I hope you can make it work. My lib waits for completion
> > for the
> > most part, but there is a class of script (that use DOM and
> > document.write for some reason) that is tough to work with. Your
> > approach looks promising. Have you looked at John Resig's HTML
> > parser?
> > http://ejohn.org/blog/pure-javascript-html-parser/
> > That might be able to cut down your code size a bit.
> > Cheers,
> > Noah
> > On Fri, Apr 8, 2011 at 2:11 PM, cdata<aar...@gmail.com
> > <mailto:aar...@gmail.com>> wrote:
> > Hello Steve and everyone else,
> > I've been closely following ControlJS from its creation. I
> > really like
> > the approach that it takes to async loading, but after
> > doing a lot of
> > testing I found that the document.write wrapping was kind
> > of a crap
> > shoot (especially when it comes to pesky little things like
> > advertisements).
> > I have started development on a library that takes the
> > same approach
> > to enabling asynchronous pre-caching and synchronous
> > execution of
> > scripts as ControlJS (in fact, it started as a fork),
> > while also being
> > almost 100% document.write compatible.
> > The library attempts to buffer document.write calls and
> > parse them as
> > closely to the way that a browser parses the original
> > document as
> > possible, creating and inserting all new nodes using
> > post-load-safe
> > DOM tree insertion methods. Using this technique, the
> > library can
> > correctly load many obscure scenarios that the span +
> > innerHTML
> > technique doesn't accomodate well for.
> > It's kind of a behemoth right now, but I'm working on
> > slimming it
> > down. Anyway, I wanted to put the word out there about
> > this, and I'd
> > love to get some feedback from any of you on what you
> > think and / or
> > how it could be improved!
