On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth <aba...@chromium.org> wrote:
> It seems like we need to draw the line somewhere. Otherwise, we'll > end up exposing the whole DOM via the WebKit API. Where do you think > the optimum cut-off is? > I think treating the DOM as an XML-ish object tree would be the most reasonable approach. This means: 1. The ability to walk the DOM hierarchy by following parent/child relationships. 2. The ability to get/set DOM attributes. 3. The ability to create/delete DOM objects at any level in the hierarchy. 4. The ability to set event listeners on DOM objects (perhaps using a v8::Function as the listener). Inputs would need to be sanity-checked by the API based on the underlying object context, but I don't think we need to provide separate API classes/methods for each possibility. > Adam > > > On Tue, Oct 20, 2009 at 1:55 PM, Marshall Greenblatt > <magreenbl...@gmail.com> wrote: > > Hi All, > > > > The Chromium WebKit API does not currently provide a wrapper for the > > WebCore::Document object associated with a WebCore::Frame. CEF > > (http://code.google.com/p/chromiumembedded), which also uses the WebKit > API, > > would like access to this object at the C++ level. Is there interest in > the > > broader Chromium community for having a Document wrapper as part of the > > WebKit API? > > > > Thanks, > > Marshall > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
