> Do we think that should be before or after the duktape investigations?
Implementing a complete DOM, with asynchronous events etc, is a big big deal; looking at duktape is much more tractible I would think. It's also orthogonal; you can work on that and I can continue to work on my side. > any attributes set on a tag's js object are reflected > in the edbrowse representation. I'm not sure of the direction here. I think if js sets any old variable foo=bar, that does not need to come back to our tree of nodes for any particular reason. However, if html sets <tag foo=bar> that should become part of our edbrowse representation, and then should be set as a member in the corresponding js object. The first part is already done. I gather the attributes as tidy provides them and put them in t->attributes. So we have access to them all. >From there you'd think it would be a piece of cake to just loop through them and call set_property_string(), and they're all in js. But there are a few subtlties as per the dom. There are exceptions. I've probably only run into a quarter of them. <span class=j> translates into classname = "j". <A href=url> doesn't create the string href = url, but rather instantiates a URL object and fills in all its components below. And so on. We can't mindlessly push all the attributes through to js, we have to know what the exceptions are. And yes, we need to be more automatic about creating js nodes parallel to our nodes. It's mostly hard coded right now, and that's not very good. We can move this toward automatic, but again, as above, there will be special cases. <input type=radio> isn't an input node at all, but an array of input nodes one for each radio button. Just an example. The more I look at DOM the more special cases and exceptions I find. So it will be some work for sure. But we're moving in the right direction. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
