From: Karl Dahlke <eklhad@comcast.net>
To: Edbrowse-dev@lists.the-brannons.com
Subject: [Edbrowse-dev] tag list
Date: Sun, 02 Mar 2014 09:15:44 -0500 [thread overview]
Message-ID: <20140202091544.eklhad@comcast.net> (raw)
> 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
next reply other threads:[~2014-03-02 14:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-02 14:15 Karl Dahlke [this message]
2014-03-02 19:28 ` Adam Thompson
-- strict thread matches above, loose matches on Subject: below --
2014-03-01 19:24 Karl Dahlke
2014-03-02 13:47 ` Adam Thompson
2014-03-01 14:00 Karl Dahlke
2014-03-01 19:01 ` Adam Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140202091544.eklhad@comcast.net \
--to=eklhad@comcast.net \
--cc=Edbrowse-dev@lists.the-brannons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).