Rename ":observe" to ":react"

[bob2517]

I had a sudden clarity on the observe event.

With a hover or click type event, this is what happens, for example:

body.menuOpen .menuItem:click {
...

When the items in the selector are in a certain state, and then there is a click on the last item in the selector, something happens, to it, or optionally other targets at the same time.

But with the observe event, this is what happens, for example:

body.menuOpen .menuItem:observe {
...

When the items in the selector reach a certain state, the last element in the selector reacts and actions happen on it, or optionally other targets at the same time. It will only react again, if the existing state goes away and later the same state matches again.

I don't think that the word "observe" correctly reflects what happens. I think it might be more appropriate to call it a "react" event, as that is more explanatory of what is happening. When written, you can quickly see which item is reacting, by looking at the last part of the selector that is right next to the :react. In this case below, the item reacting is ".menuItem".

Eg.

body.menuOpen .menuItem:react {
...

or in real-world terms:

sun.shining .flowers:react {
  add-class: .openPetals;
}

sun:not(.shining) .flowers:react {
  remove-class: .openPetals;
}

or

.letterOnDoorstep .bobIsByTheDoor bob:react {
  @if $timeLeft {
    open: closest($letter);
  } @else {
    move: $letter onto $table;
  }
}

Thoughts?

It's a 2 second fix in the core to make the change, and it's not a big deal for anyone to switch from :observe to :react in their config if I change this.

[bob2517]

I'll give it a few hours for anyone to comment before I just make the change anyway, lol.

[dragontheory]

I like it!

I like it alot!

Unless I'm interpreting it incorrectly, this says, add class .openPetals to .flowers when the sun element(no dot?) has a class of .shining.

sun.shining .flowers:react {
  add-class: .openPetals;
}

Since this is "Active CSS", would it be safe to assume that when .shining is removed from the sun element, the .openPetals class will automatically be removed from .flowers as well?

[bob2517]

Unless I'm interpreting it incorrectly, this says, add class .openPetals to .flowers when the sun element(no dot?) has a class of .shining.

Indeed, that is so.

Since this is "Active CSS", would it be safe to assume that when .shining is removed from the sun element, the .openPetals class will automatically be removed from .flowers as well?

Well, no. We can't accurately predict the reverse actions, especially if there are ajax calls and that sort of this in the first event. It cannot sensibly be done. Reverse actions can only be predicted in limited scenarios - we may need flexibility in the reverse action. For example if there was an ajax call followed by something happening elsewhere in the DOM - it would get messy trying to predict the reverse of that, or even to work out if the reverse action was actually wanted. There may be variables we need to increment on the negative, but NOT decrement on the positive. It's not possible to predict accurately what the desired behaviour is.

The reverse needs to be explicitly set up. So:

sun:not(.shining) .flowers:react {
  remove-class: .openPetals;
  $nighttime++;
}

[dragontheory]

it would get messy trying to predict the reverse of that, or even to work out if the reverse action was actually wanted.

True. There are good sensible reasons why CSS can't do what ACSS can.

[bob2517]

Closing - don't think the change is needed particularly now, looking at it afresh. Plus I don't want it getting confused with the framework of the same name.