From mboxrd@z Thu Jan 1 00:00:00 1970 Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2001:558:fe16:19:96:114:154:165; helo=resqmta-po-06v.sys.comcast.net; envelope-from=eklhad@comcast.net; receiver= Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 87AC37A924 for ; Wed, 16 May 2018 08:19:08 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-06v.sys.comcast.net with ESMTP id IxDsf6Y9TqoFSIyCqfnZH3; Wed, 16 May 2018 15:19:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1526483948; bh=+neXGFFv3a1RZCa/0AW/tNRTRg8y6nEdD4CXf+5hRF4=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=VpHRgAUSlnsP0wjpfBijVgyN+KUY0+HczFTkk/xASbMspm02ALGNRDQiNcJObQeiS WpBA7DRBpWYJvAn5aJokcCFE9gP0AZuvgyMNi55oxr37pEryTfTZSPrWYuqsHFaAHM vc6/Y5wolpqkmMgdyfkGzobMSEj0HzfC13RcAy7PMH4ayLlYz2LYOSUabH+sgnT9xc TpXq6G2Z8RkiF8GoRhwbeav37vS+SGOuOp95+nlb0+HmIFRfKWuBTZQwv/RUPkFK4a y5l1XxOtxVS3hdCqqXoCUvmjKMUKQfl7vZXnDmLi4LiZOAkm6KuX2fenWCxLp1UXPf ML1603f2sm1iw== Received: from unknown ([IPv6:2601:408:c300:8f09:21e:4fff:fec2:a0f1]) by resomta-po-02v.sys.comcast.net with ESMTPA id IyCpfJyGEQ84OIyCqffJHq; Wed, 16 May 2018 15:19:08 +0000 To:edbrowse-dev@edbrowse.org From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.3 Subject: [edbrowse-dev] Changing classes in the middle of the stream Date: Wed, 16 May 2018 11:19:07 -0400 Message-ID: <20180416111907.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-500222 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNLWQw/+cumhSCYdgZ1hmkILbs3nk5CdQkYg5FQobBMiKE2ym2ku5eiEDoUzvdEOQ1C6Y7jt2dXkE4uLgebKqb/egTlmc1Hm68xBtldYs+D67dWQiROO +M05I1IJQstLRwadff0dt/s/7D1uXZy0L1oKPC0pKjYtd9XupVQXBypK+bJ8o3QRmYhLjnE7Q+X1Ktzn/Mn6u65lI34nY0Ly7JvN8Wnp215rbBk0w6JO1WGB This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-500222 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gets you wet and sometimes cold. (Nod to Fogelberg) I'm continuing down my acid trip, and I see that js removes, or = updates, node.class, and then expects the new css rules to apply. So a class starts out z, and we have the rule .z { visibility:hidden}, = so that paragraph is invisible, and then P is appended, className +=3D 'P', so class is now zP, and = that rule just doesn't apply, and there is a zP rule that sets a background color, so the paragraph = pops into view with a certain background color. As each test passes another P is appended, and new css rules take = effect, and new background colors. If your sighted friend runs the acid test in a regular browser I'm = guessing the colors will change as you pass through the tests. So where does that leave us? It's bad enough I check every node, every time, on every render, to see = if style.display has changed, if js has turned that section on or off, as happens with the rocket game, do we also, every node, every time, have to run getComputedStyle to = reevaluate all the css selectors and rules, remembering there could be = 5,000 selectors? Even if we did, maybe js specifically and directly set the display = value, as in the rocket game, so we don't want a new css calculation to = change that, and we might not even want a new css calculation, because the class has = changed, to change that value that was set by js directly. How do we know if display =3D box was set deliberately by js, or by a = css rule? It might matter if we're thinking of changing it because class changed = and we rerun css. But it could be worse. You could add or remove an attribute, and css could set rules based on = that attribute. [hello] { background:green} background is green on every node with the hello attribute set. So changing any attribute at any time could in theory change the entire = presentation of that node; and we almost don't care, background color, font size, face, = decorations, almost, except insofar as the node pops in and out of = existence, visible or not visible. I tried to sleep on this for inspiration. Last night I thought I would check for class changes, but not for = changes to every attribute under the sun. That would fix the acid tests. So set last$class, and as part of our visibility check on each node, = which we're already doing anyways, compare last$class and class, and if there is a change, clear out the = display attributes and rerun css on that node. That would make acid3 do what we want, and have almost no slowdown on = sites that don't change classes, but it's a pain in the ass, and not a = complete solution (as per other attributes changing), and this morning my strategy is "screw it!" Other sites, like the rocket game, or the baseball reference, hide and = show sections by diddling with style.display directly, they don't change the class name for Christ sake. Maybe only acid3 does that. I can't do a lot of work for something that only acid3 needs. This nuisance can be set aside by the hover command, which shows the = invisible sections, and there you have it. One other nuisance, I had to comment out one line because acid3 expects = nodes for the unrendered whitespace between html tags, tidy does not = and will not provide nodes for these, (so says Geoff), so they just = aren't seen by us, and that literally blew up acid test 0, so I commented out a line and = now I pass test[0]. My incremental approach is to have a copy of the base page that I run = locally, and I've stripped out all the tests except the first one, = which I now run, successfully, with my tweaks. fortunately the code uses tests.length, rather than 100, so it runs = just the tests I have and that's perfect. I'll bring them in one by one and on we go. Karl Dahlke --nextpart-eb-500222--