From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 10460783A6 for ; Tue, 15 Sep 2015 18:52:54 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-07v.sys.comcast.net with comcast id HdvP1r0032Bo0NV01dvkNE; Wed, 16 Sep 2015 01:55:44 +0000 Received: from eklhad ([IPv6:2601:405:4002:b0a:21e:4fff:fec2:a0f1]) by resomta-ch2-05v.sys.comcast.net with comcast id Hdvj1r00L0GArqr01dvj5h; Wed, 16 Sep 2015 01:55:44 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20150814171732.eklhad@comcast.net> <20150915232100.GI29720@toaster.adamthompson.me.uk> User-Agent: edbrowse/3.5.4.2+ Date: Tue, 15 Sep 2015 21:55:43 -0400 Message-ID: <20150815215543.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=q20140121; t=1442368544; bh=GB9GmDBeIiQwF+5IZOgQ+VXraZlS5vnXghipi1l5cdw=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=p14ghjRF2Mti3DLsAOoczmyFc2jl6rNYa6vNEDIE5DHYg52AmM9PU+1JPgpcngnln 1m88naR73o74hnxLriioRs2wVSQZy+46BRN2HcK5675i3kYIjHpg8HllGM8NA0V44R cxLX5IVXKWSqoa5JYZ8/8+UFgenRi6ONNvFUKWwCDLa30ax9RAYdNeoHCufK9u6zD8 yP8duPpTOKe+T2ROiQMqugzfukNSDz5C+YADBHgnn5l2U9JSB2x6ZnRoxCN6rnlLBZ jVibUFq42XwetVEvSz3BQne+Xq1wydoYO3scPvBTHkzlwryTxW5kx9onUqEHZUhD11 Nea9fJVqbBvRA== Subject: [Edbrowse-dev] rerender X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:52:54 -0000 > 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 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. translates into classname = "j". 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. 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