> At some stage I really need to familiarise myself with the html code. Yes, but please ask if unsure. A question can sometimes replace days of reading code, especially my code, which isn't well commented.
> but why are we storing a list of pointers? Precisely so the structures don't move. Each tag can point, by a pointer, to its parent or children and those pointers will remain valid, even if c++ vector does a realloc on the list of pointers, which it will do as new tags are created. Chris and I went through this - I even started writing vector<struct htmlTag> code, but then I could see the structures were moving, and the parent and child links became invalid. > We also need to store a list of children in each tag, i.e. in the code: Yes, and javascript has set for us a partial standard; should we follow it? A form contains input elements, right? Well js standard says form contains a member named elements, which is an array of all the input tags, in order. Now suppose one of those inputs is a dropdown list, a select. Dom standard says that input tag contains a member named options. It is an array of objects, each object an option in the select list. So children seem to be held in an array that is owned by the parent. > Example of <body> <div> > > The body would have a list of two pointers to the two div tags, 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 called 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. 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 paragraph or whatever. 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. IDK > No need to do this rewrite at the moment, 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. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
