> > > > The body would have a list of two pointers to the two div tags, >=20 > js already has an array of div tags. > It is called divs, I think. > I know it has n array of link tags called links, an array of image tags c= alled images, and so on. > What I don't know is whether this, in the standard, is a global array of = all images on the page, > or a local array of images in the current structure, > like elements in a form or options in a select. > We would want the latter. > More research is needed. I'm not sure, however for rendering we need the generic approach above. The other arrays can be generated from this as necessary. With some care this shouldn't be too bad performance-wise I think. > domlink() in jsdom.cpp is suppose to do all of this. > And it looks like it treats elements and options as a local list, > in the current structure, but images and links and heads and metas > and anchors as a global list under document. > I don't know if this is right. > If this is the standard perhaps we can do both, > document/images[] for all image tags on the page, > and local/images[] for the array of images that are inside the current pa= ragraph > or whatever. I'm not sure, I need to read the DOM spec at some stage to work out exactly= what's needed. Remember that there's a core DOM and then the html extensions to this. I think we need to get our core DOM working, then look at the html extensions (images[] etc) on top of this. At the moment, we've got a partial html DOM but not really the core underne= ath it so appendChild (core DOM I think) and friends are awkward to implement. If we fix the core DOM, then the html side of it, this will hopefully make rendering better, add support for appendChild and tag creation by JS, as well as probably removing special-case code. > Another aspect of this js standard is it is type specific. > Here is the list of elements in the form, here is the list > of images, here is the list of anchors, etc. > Maybe that's ok, but maybe we also need an array of all tags in order > within each construct. We definitely need an array of all children. Remember this isn't so much a js standard, more js provides an implementation of an interface to the DOM defined by th= e W3C. I think if we look at it this way (i.e. implement our DOM then the js interface) that's probably better. It also means that when Mozilla totally change SpiderMonkey again (which th= ey say they may do at any time) we have a working DOM which just needs new wra= pping. To take this to its logical extreme, I'd like to separate the html parsing and DOM creation from js, providing an api to this DOM which is capable enough to support all the stu= ff JS needs. We could then also write the rendering code using this DOM api as well. I wonder if there's an html parsing library we can use for some of this. > > No need to do this rewrite at the moment, >=20 > Absolutely agree. > I think we all agree here. > Let's get 3.5.1 stable and working with distributed libraries. > We're just talking, and thinking, and planning for the future, > and I think it is helpful. Yeah. I think future planning's a good idea, particularly when discussing the kind of changes above. One discussion we should probably have at some stage in this area is what systems, language standards etc we want to support. Personally, I'd kind of like to keep most of edbrowse in C, with interfaces to whatever we need in whatever language (c++ for SpiderMon= key js for example), however I know people seem to want to use c++ for various things. Cheers, Adam. --b2ktwntdbf0dPnbx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTE4ZDAAoJELZ22lNQBzHOKsAH/R98zRb9EpX1nskJptStOt4w e8l9NlsNNbG/FDN1xBLagAYgs02Y37h47uJPKlU0/riJ2bZQmPQ0bEpc5EBOMUjc 2X61iXDIP4e3eGLOGHR6ZQ4ET2MGbklmES0uasaYz5It89/ViIIUQXuimiGGXyWw 3EUrmFx8pDgqZqqC729cgHDGXjexeJE1aBBWw/jGf9wjCkVfqa6x1OOetcyO2q1k ckWx5sRiD65K/wQqqRZAK0lIBLU35RGu0Gl+uhtNcb1vN6p5TjKtfmsF9sqbRWt4 Ex65vWskPPtEp3jRdUhYWscmgCGoanKyyLtuv8MJO663J6xxOr/K4DDQcfW4aFc= =Qltr -----END PGP SIGNATURE----- --b2ktwntdbf0dPnbx--