jf test

Subscribe to All Access »

Subscribe to Print »

The first one has & escaped, the second one does not. So ok just wanted to make sure tidy is handling these two cases = properly, and it is. Happily, my parser also handles these cases properly. I must have run into this at some point. I'll continue testing. Assuming I uncover no serious problems, I think the next step is to enhance our edbrowse node, with enough = attributes to faithfully copy the information from a tidy node. We have some of the attributs but not enough. A blatent omission is a text string, because we never represented text nodes before. We'll need this, and child pointers, and a list of attribute value pairs, and other things. I'll post more on this later. Karl Dahlke --nextpart-eb-711431-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 5DA5C77D0D for ; Sun, 30 Aug 2015 04:14:39 -0700 (PDT) Received: by wicne3 with SMTP id ne3so51244620wic.0 for ; Sun, 30 Aug 2015 04:16:52 -0700 (PDT) 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=9oUSWD1rI88EoUtGgm89tUHUVEo59UDzP9ELQk6xC9M=; b=Tc+NbIqtxr8g46sdBgbAwtUQ0rsViFX1kIwJ4x9HyLPqGhzx1A9oTexRrqelrpqcVe Ql0hS3ycsf4mdUsU8lh8gNPpx0V2rmctpbIuu8el5RIyXUE82ID8o/3HPkYBBSoxJj2A mi4SbVmhyqw//laLigW9FmU4PVsR5CfqHmjadtcn8fd2gZCl3qahB+YuWGg4oKu6IXhh sd9enuYEd6P4FBTrNYJ6QH21cK7So80WHVY0JUCnPvEG73XpPeRowQBp1NZQncG/drBW LNPqa2VNB58+WxnFcYVqFELu6zY7wSu1k2iaGzz1sSnHJr9j2E8nwrDHumtkjy4E2EB1 fPTw== X-Received: by 10.194.120.198 with SMTP id le6mr21147347wjb.133.1440933412008; Sun, 30 Aug 2015 04:16:52 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by smtp.gmail.com with ESMTPSA id h6sm12738057wiy.3.2015.08.30.04.16.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Aug 2015 04:16:50 -0700 (PDT) Date: Sun, 30 Aug 2015 12:16:49 +0100 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20150830111649.GD17154@toaster.adamthompson.me.uk> References: <20150729060404.eklhad@comcast.net> <20150830100239.GC17154@toaster.adamthompson.me.uk> <20150730063111.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ylS2wUBXLOxYXZFQ" Content-Disposition: inline In-Reply-To: <20150730063111.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Edbrowse-dev] tidy debug tree, and a js script 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: Sun, 30 Aug 2015 11:14:39 -0000 --ylS2wUBXLOxYXZFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2015 at 06:31:11AM -0400, Karl Dahlke wrote: > > Any chance you could have a go at converting some of the parsing logic >=20 > Wow - I'm good but not that good. > It's a pretty big project. > I don't want to move too slowly, having done almost nothing on edbrowse > in the past 6 months, but I don't want to run recklessly fast either. > Need to pass designs by you guys before coding etc. > And there are still some big questions to answer, like is tidy5 > the right path, or perhaps libhubbub, which could be part > of a larger browser effort, larger than just parsing html. > netsurf-browser.org I looked into libhubbub before going down the tidy5 route, but it seems to have been sucked into netsurf fully now so I gave up on it. > I'm running another sanity check on tidy. > This generates an error because & is not escaped, > and yes it probably should be. > I suspect the error here is that we're missing the closing quote in this ex= ample actually. > It even converts © into the copyright symbol, > now part of the url. Not sure about that, but this isn't a correct attribute anyways and I've ne= ver seen this on the internet. > So ok, maybe I did a bad test because I'm not following spec > but the internet doesn't follow spec either, not all the time. > Look at the raw html from www.sciam.com > It contains these two lines, on the same home page. >=20 >

Subscribe to All Access »

Subscribe to Print »

>=20 > The first one has & escaped, the second one does not. > So ok just wanted to make sure tidy is handling these two cases properly, > and it is. > Happily, my parser also handles these cases properly. > I must have run into this at some point. Agreed about html not following spec; that's why I wanted to get away from a home grown parser. > I'll continue testing. Assuming I uncover no serious problems, > I think the next step is to enhance our edbrowse node, with enough attrib= utes > to faithfully copy the information from a tidy node. > We have some of the attributs but not enough. > A blatent omission is a text string, > because we never represented text nodes before. > We'll need this, and child pointers, > and a list of attribute value pairs, and other things. > I'll post more on this later. Yeah, I think we'll need to revise our tag nodes signifficantly eventually, but as a stop gap measure I was thinking to simply run through the tidy tree and copy what we can into our existing structure. It's far from perfect but we need to rewrite the DOM anyway at some stage. That's going to be a really large project requiring a large set of changes = to how our tag system works. Thus I don't see the point in enhancing our exist= ing tags too much, though if it naturally heads towards a functional DOM representation that's good with me. At least this way we get more html support and probably get rid of some par= sing issues into the bargain. Cheers, Adam. --ylS2wUBXLOxYXZFQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJV4uYhAAoJELZ22lNQBzHOFvAIAKqV/DrkQp6tHrTv8twmIMiJ Bw9srg2ahNKhEt6PrMf6LmjHMiLNi0WHqJIHNT80Z5fJeTG1O58/lfG0BJqHfWgH oCu9Q9yfyChWtQDx4izQpsQInQi5ZcOIF0WkluQRXoOEQ+rB6y0CgpTyziJ3dDFe UJOwup06Zw6DkQIfhqEoUnfVeMIbaxQ717rd8RzlFhcsR9i28dye/rkWpzWU1AF/ 4dYwFGZnmw/r/xIQAxLQltlCEwdHLxoibv3bjVqkkepHUsfydRPLLXLru4218bYj smVhAOwmfIq+2/h6t3ViZxf1FBCIg+DplWUTsC4uWy98tkoLa1BCvoQ0t7sP+VI= =UxNR -----END PGP SIGNATURE----- --ylS2wUBXLOxYXZFQ--