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
