From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 808DF7863F for ; Fri, 28 Feb 2014 09:45:13 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id t61so796866wes.8 for ; Fri, 28 Feb 2014 09:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ijNtucTzD/8pm1PGZ/hHJfNZ01InZYHFxIDYxgDm/gU=; b=ThqQriSLB5LKihMvmcdwHcLfUuhkLoj7pathNvwEj2GILOEj8Y0Qx+kWrZx0xZVyWJ uWsf28nRSQMfbb4kNd/icf4LArjDT/C8hTgd2ArLfmiRLXgzW5dk0sNqB6v2fFhj1k44 qR/6rlHfmaLZPpFmchuG/f2728OCBAxZCWU5SRflcWlsfJjyotFLOtH6dRseS7Oll0nO iKCemfXFF9J/SX2rjV0zyR2cWG58Qi7eKUaf5sItxPqsSf6Wx6wQLfloTPNO2erNeA5Z UxRLC+/pijz6Ov891EakT9yOASOFizt0Rpq3n/SINdgR70F2Zz/fBJqu4JUsUssHvGNd h0bw== X-Received: by 10.180.89.225 with SMTP id br1mr3803052wib.38.1393609446141; Fri, 28 Feb 2014 09:44:06 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id t6sm8017862wix.4.2014.02.28.09.44.04 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 28 Feb 2014 09:44:04 -0800 (PST) Date: Fri, 28 Feb 2014 17:44:01 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140228174401.GD19851@toaster.adamthompson.me.uk> References: <20140128114309.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G6nVm6DDWH/FONJq" Content-Disposition: inline In-Reply-To: <20140128114309.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Render X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 17:45:14 -0000 --G6nVm6DDWH/FONJq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 28, 2014 at 11:43:09AM -0500, Karl Dahlke wrote: > Well this is thinking ahead to future versions of edbrowse, > with some of the anticipated redesign. > I'm thinking out lout if you will. >=20 > We want to build a tree of javascript objects, first built from html, > then perhaps modified by javascript functions, or even onclick or onchange > code as you interact with the web page. > Then a render function traverses this tree and builds the text buffer tha= t you read. > This render function is called after every javascript invokation, > because you never know what javascript might do. > Add new paragraphs, tables, build new option lists, etc. > This is where we are headed, > and I was almost tempted to start writing render.cpp, > which would not interfere at all with anything going on now, > just a separate file with a function not currently called, > but intended for use in the future. Yeah, I can see how this'd work. > I was going to copy html.cpp to render.cpp, > and create the same text buffer, but not from html tags, rather from the > tree of javascript objects. Hmmm, I wonder if we want to try and keep it away from javascript specifics= , i.e. develop a generic DOM structure which we can then plug into with js or what= ever. [snip] > So render.cpp is mostly a long string that is the render() function > in javascript, and I just pass it to the js engine for execution, > then the resulting document.write string is the text buffer. >=20 > Pretty slick, eh? How'd this work with forms, event handlers and all the associated machinary? >=20 > As time permits I may start to outline this javascript render function. > This requires some conventions about the object tree, > paragraph objects, text objects, etc; any enhancements > we need to make to dom, but all this has to be settled no matter > how we do it. > Render() will be a nontrivial, recursive javascript function, > but much cleaner and easier than the C counterpart would be. Hmmm, I can see the thought process here, and I was thinking along the same lines a couple of days ago. However, the more I think about it the more I think it's potentially not the best direction for edbrowse since it places a lot of dependancy on something beyond our control, i.e. the stability or otherwise of a js library. I also wonder if this'd work in terms of browsing a web page without js, or= one which defines its own render function. Before you ask, I'm fairly sure with the increasing amount of js-driven gui-style webpages, I could find at least a few pages with a render() call already. The kind of model I propose is one inwhich html parsing becomes the creatio= n of these generic objects, which are also created by javascript (but not stored= in the js universe apart from via wrappers), and then rendered using a render function called when the tree is updated (using an update function etc). I'm fairly sure this'd be possible, and probably simplify things. In addition there'd be no more rooting required in this system than in the = existing one (object properties go into a list, or hash map, and are heap rooted on creation etc). As I said, this needs more thought, but would also mean the failure case be= comes a function which goes through the tree destroying all the js data and then destroys the context. Cheers, Adam. --G6nVm6DDWH/FONJq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTEMrhAAoJELZ22lNQBzHOSIwIAI/I5F3YVwgjloEM4QTnFRR7 mXhhdlxTWa2wnOE9GCbcZ8hYaWb0mIfOh55J8Jc012HqU0O9j4t4XulSkdLZmfBV 4ro+M/9Cte5tS9g5IwtVIHp7QhFdO3BUNK0fuVyKXEUp3LautKwzspkL/q+TgjWh cPmz0fZg0YzyQjeNJ3W1tCikUFZytDu7/C4Wc5mtgtWtEM3ta1oimC5z9Wl9p336 f6V8jFSZGJoAXryPurH89llXg5TJfIPxQq1rsD3IA7Mh5OVIz8M2pq1ortLj7bDc SpCbx39Kl+2HTBCOBUoJ6aRnwUEFccdqTMJuTN+BSKnsO7YiIKJa4ZLzMnvHenE= =wWoW -----END PGP SIGNATURE----- --G6nVm6DDWH/FONJq--