From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 05DD67863C for ; Fri, 28 Feb 2014 14:05:31 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id l18so1087030wgh.9 for ; Fri, 28 Feb 2014 14:04:25 -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=Aig43jODIOWC07L5VQzlgrFtf3jWNaeXZ2G5OB1SY4g=; b=sq2pP2kwY4VWhMdgetcREUL1FGkqrhqG5xE/f+V6MeL0Kk6gdbluA6vu4HJanwO9u5 iZW4dzD7l/kF0MEisaKZZfByhOjrKxDOcmwZDEwlVEdDe9n1mF6JPX1nxzkB8hetj5YL VMp0Az/JNPH/snHbqFPqR6lO5Gthe+2YkeHQ76/gIjrb9U4QqFQFe3C832sJ6R4DHysu /MQ3Sf+F8p4Af4XwtFn6ASXlka4O//C7oIYJ9f3vHIwyEc6jgKvTBKZx9ngUTeNzUyoT s9GOXGfez4Mc8W0hiO27FlNC014lWKRnwTJk6/4SIWSD0oUBW2RIAFDTsb61/EcJlywN Jb5w== X-Received: by 10.180.98.199 with SMTP id ek7mr4618310wib.21.1393625063621; Fri, 28 Feb 2014 14:04:23 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id hy8sm7514366wjb.2.2014.02.28.14.04.21 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 28 Feb 2014 14:04:22 -0800 (PST) Date: Fri, 28 Feb 2014 22:04:19 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20140228220419.GG19851@toaster.adamthompson.me.uk> References: <20140128150135.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2xeD/fx0+7k8I/QN" Content-Disposition: inline In-Reply-To: <20140128150135.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 22:05:32 -0000 --2xeD/fx0+7k8I/QN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 28, 2014 at 03:01:35PM -0500, Karl Dahlke wrote: > > Hmmm, I wonder if we want to try and keep it away from javascript speci= fics, >=20 > I don't think you can, really, we always have to support javascript, > in whatever its form and syntax and semantics, we're always in there, > in the heart of it, > so why not write render in the language that we know we have to support, > stepping through all the objects that we know we have to have > corresponding tags for. > I don't see the advantage of transmuting all this to another tree in anot= her > home-grown language and then transmuting it back as necessary > to work with javascript. I wasn't thinking in terms of a home-grown language exactly, more an expanded concept of our existing html tags. > Also the tree is mostly made for us already. > The form object contains an element array. > This array holds the input tags. > Each input tag has a value and checked field and default, > and if it is a select, it has an array of options, > and each option has a checked field and value, and so on, > all that tree structure is there in javascript, > and has to be there or we aren't doing our job, > so render can just trace it as a javascript function. > The only thing we need to add is a text object. > If there is nothing on the web page but hello world, > no tags, no nothing, > we would have to invent a

paragraph tag or some such > to hold the text. We're basically going to have to parse the page, wrap things in new tags then hope they don't break the existing html if any. > So yes some tweaking on our part, > but I do think much of the tree is already built in js and has to be so > and will always be so, so why not live in that world > when translating the tree back into a text buffer to browse. Primarily because I know of no way of protecting this js render function fr= om being zapped by an unfortunately crafted page. At the moment if js does stupid things and breaks the js dom that's not nic= e=20 if it completely destroys our method for rendering the buffer that's not only difficult to debug but also means you end up with an empty page. > > How'd this work with forms, event handlers and all the associated machi= nery? >=20 > I mentioned that forms already build a fairly substantial tree > of javascript objects for us. > It's all in place today. > And so do tables, with rows under tables and elements under rows, > and so on. > I think I implemented tables rows and cells as a js tree. > I was supppose to. > Anyways, an event handler is a function under a tag, > which becomes a js function under the corresponding object for that tag. > Just another leaf on the tree. > Nothing special here, just another member of that object. > And I already do this today for onsubmit onreset onchange onclick. > So again the js tree is already there. > We have to traverse it, and it's easier to traverse in js itself > then in any other outside language such as C. I agree that this is the easiest option, but I'm still unsure how robust this'll be and also how this plugs into the existing machinary. For example how will the i and g commands work? > > it places a lot of dependancy on something > > beyond our control, i.e. the stability or otherwise of a js library. >=20 > Well I'd be writing render() in javascript itself, not dependent on any l= ibrary. > As long as there is a call to > executeJavascriptCode(const char *code) > then we're ok. >=20 > The language of js, i mean for loops and if statements etc, isn't going t= o change. > The objects in the js tree might change, but probably expand in a backwar= d compatible way, > and guess what, we have to support all those changes anyways. > From html to objects and the semantics of those objects, > from start to end. > And render would have to support the new objects and tags, whatever lang= uage it is written in. > So it would be easiest if it was written in js where the tree lives. > I'm thinking so anyways. I guess I'm not saying that theoretically this isn't a nice idea, but I'm really worried how reliable this'll be and how it'll cope with the insanity that one sees on the web. In addition, what happens to our ability to render the buffer when js blows up mid-execution, before we can render things and the context goes away? Also, how are you going to make this function called every time js does any= thing? Cheers, Adam. --2xeD/fx0+7k8I/QN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTEQfjAAoJELZ22lNQBzHO+I8H/i2fLdmjyRD0Ry+OAsTkIbE+ 0y5CXP7NP+QQAUbz7GDTHZqwLSyZvV28MW3GRJLviClZeIv4VYbUyTAXAm3cM6NO hTgVUFJJ28PnTqDaH3z5Ht3Gm3bPUmfcN5fqOAFCnP3HqNRi2SubZtdH3Q/Mr3dW lU8DReNpOo4BtuSDWg7Y/A56+bKjpM6wUazVHCZXHcgDDTjLpdYfZcVgcWYDwBfh EvQ8JWFc0uxr3E79NHinjRDj1aVYLznhZvacxYryF0IYj5/K0+G0qm+8P5l2NWPB x6CAYTAt8Md6I2WgHREzO4VycXyGXk0Y9N4tpDQBTgbzUzRifM/iyY4sINXoBxY= =frUF -----END PGP SIGNATURE----- --2xeD/fx0+7k8I/QN--