From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by hurricane.the-brannons.com (Postfix) with ESMTP id 9F2BA77B58 for ; Sun, 2 Mar 2014 06:16:51 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id Ye6z1n0021ap0As54eFku5; Sun, 02 Mar 2014 14:15:44 +0000 Received: from eklhad ([107.5.36.150]) by omta22.westchester.pa.mail.comcast.net with comcast id YeFk1n0073EMmQj3ieFkGt; Sun, 02 Mar 2014 14:15:44 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Sun, 02 Mar 2014 09:15:44 -0500 Message-ID: <20140202091544.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393769744; bh=9yIlql8SaCcpYR432B33xigLPKQ3xxL7F1eZW8N0bSo=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=KLf5+Md5IO/n0vKKefoYQsRNQDwy/HXo7uFzns/7IoJYVHI+2D8IWLgpWTLYCToQP gpbE6JX+YtHtFD5WDxjpl4QnuAlLBGYX/X67rn87hdOJfgin0XtFbGKtPSi1D3sxbN 1OOr2QS26SzAM018X1ngEpX6FwUAj/6a6NPPt8CelSVnEt1NY1nRuWBZj/MgH7fHzt PUHkQn4Q1LkNlM6P84X1z0f0vsUkRS7ABeEydxEa7Otn4eyRnqc3RFTgVvOR2xlRFh nxb6T46mpLt+7HErNk5AP0cuhWzSTcEdxV6NbVAq6LSZjv+aW8W+yfgfWTHO+j2ZM+ WyAckzEnU0WZQ== Subject: [Edbrowse-dev] tag list X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 14:16:52 -0000 > 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 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

> > 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