sectiontags). I went with a class called
opensince jQuery has its toggleClass() function which makes it like flipping a bit. Plus I could style the steps in CSS with a default for all steps and then specialization with the
section.openselector for that one step that was currently open. This allowed me to have the UI-specific stuff in regards to what was (not) the currently open step be declared in a CSS file.
And then some people complained. They didn't like that the same background color was being used for steps that were upcoming and ones already completed. But as I said I didn't want to start keeping track of more UI stuff in the JS code.
Luckily CSS3 has some selectors that allow for context-dependence. Turns out I could style all steps following the current
section.openusing the selector
section.open ~ section. The tilde selects the next siblings. What that means is that my default
sectionwould encode the background color for visited steps. My
section.openwould override that default rule for the currently open step, and finally my
section.open ~ sectionrule would override the default for all the upcoming steps. And this is all done declaratively so I don't have to do any extra bookkeeping.
But this being the web, I ran into one incompatibility problem. Turns out that WebKit and Gecko (the renderer for Chrome/Safari and Firefox, respectively) do not update nodes affected by a sibling CSS selector the same way. In Firefox, when I went through all steps once, removed the
openclass for all
sectiontags and then explicitly added the class to the first step the CSS rules were reapplied as if I had loaded the page from the beginning. But in WebKit the
sectiontags that in no way had their state changed by a removal of the
openclass did not update properly. My guess is that Gecko keeps track of CSS rules that are dependent on classes and such so that when they change they re-apply the relevant selectors, which includes the sibling selector I'm using. In WebKit I bet for performance reasons they do not re-apply the sibling rules as classes update dynamically. It's a little odd because if I was reading the developer console info properly in Chrome it knows how it should restyle it based on what the CSS panel showed me, but the actual value it was using (and was returned when querying from JS the DOM tree) was the old value. Luckily I am able to trigger a recalculation of the CSS by simply toggling the
opentwice in a row:
$('section').toggleClass('open').toggleClass('open'). That doesn't change state, happens so fast the browser has no flashing, and gets the recalculation right.
Anyway, I am rather happy that CSS provided me with a solution that was stateless (for me, more or less) for UI styling even when there is context to depend upon.