[edbrowse-dev] Changing classes in the middle of the stream

[Karl Dahlke <eklhad@comcast.net>]

[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]

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 += '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 = 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