- From: Mike Samuel <mikesamuel@gmail.com>
- Date: Wed, 10 Mar 2010 10:15:53 -0800
Hmm. It occurs to me that many libraries -- at least jQuery and prototype have their own layers in between their users and the DOM. When I cooked up this scheme, I didn't know how likely proxies and ephemeron tables were to make it into ES Harmony, but I think Andreas Gal just implemented (both? or just ephemerons) in a tracemonkey nightly. Those are all you need to do a really efficient interposition layer, so libraries are probably not going to stop doing that. So I think the non-document.write portion can be implemented entirely in the library interposition layer. document.write can be wrapped. But the wrapper would still need to know the insertion-mode. If the insertion mode were exposed, or at least some context were given -- enough to know whether the next char if not something that changed the current token, would be interpreted as * inside a tag * outside a tag in a comment / application instruction / doctype * outside a tag in a PCDATA/RCDATA/CDATA context and ideally in what kind of containing tag * outside a tag in a CDATA section. So maybe some kind of (DOMString|null) document.getInsertionMode(). 2010/3/10 Boris Zbarsky <bzbarsky at mit.edu>: > On 3/10/10 12:45 PM, Mike Samuel wrote: >>> >>> FWIW, in Gecko currently, the stringification happens a few abstraction >>> layers away from the parser, so implementing your suggestion would involve >>> punching holes in those abstractions. >> >> Ah, so there's a layer that sits between the XPCOM object and the JS >> Host object that knows a DOMString is expected, and does the JS foo >> necessary to convert to a string? > > That's correct. ?The C++ object just implements a method as declared in the > DOM IDL; there is a glue layer responsible for coercing the arguments > actually given to the types declared in the IDL. ?This isn't just the case > in Gecko; Webkit+JSC has similar behavior. ?I'd assume that Webkit+V8 does > as well, though I haven't looked at the code. > > -Boris >
Received on Wednesday, 10 March 2010 10:15:53 UTC