I checked in some early code for the webappClient Effects library. This API is pretty heavily influenced by jQuery, so it should look familiar if you're a jQuery user:

elem.effect.show
elem.effect.show(500ms)

elem.effect.animate(["opacity":"0.0"], 100ms) |fx| {
  fx.animate(["opacity":"1.0"], 100ms)
}

I only have the basics working at the moment (show, hide, animate opacity). But I will be adding to this over time. Slide animations, and animating color values are probably the next things I'll implement.

You can see a demo by running the test suite under the testWeb pod:

testWeb\boot.fan

EDIT: The current code has only been tested in Safari 3.1 (Windows), FF3, and IE8. So things may definitely be broken on other browsers (especially older IE versions).

This looks good. I'd suggest instead of using maps (for places like animate), to use it blocks as you can achieve compile-time verification of the existence and spelling of CSS properties.

That might be nice, but I'm not sure that is something we want to maintain. But maybe.

Since CSS has been around for more than a decade and there are only 3 released versions, it might not too difficult to maintain. Also, it blocks are visually and conceptually more similar to the objects that jQuery uses:

$('#foo').animate(
    {
        opacity: 0.0
    },
    100
)

A Fan version could look quite similar:

root.S('#foo').animate(
    {
        opacity = 0.0
    },
    100ms
)

except achieve compile-time safety with respect to the existence and type of properties.

I do highly recommend incorporating a CSS query engine. If this is just for JS use, you could use an existing engine for now (such as jQuery's Sizzle).

Typesafe, pretty slots for standard CSS properties would also be nice, if it doesn't add much bulk. That bulk is a good question for code in web pages, though. And I haven't tried out Fan's JS compiler yet, so I'm not sure what to expect in that area.

Side note, I usually don't get excited about having too many effects. All those effect engines seem to be a bit overkill with rather less-than-impressive shrink/grow/whatever. I'd say to focus on things that really seem to have value. I agree, for example, that opacity (and other color) transitions are among those that seem useful and can look nice.

This looks good. I'd suggest instead of using maps (for places like animate), to use it blocks as you can achieve compile-time verification of the existence and spelling of CSS properties.

I think compile time checking of CSS has two sides - checking the names and checking the values. Checking the names is easy assuming you generate a structure with a field for every CSS property. Although checking values is harder unless we take some subset of FWT to use for color, fonts, insets, etc. Even then I am not sure you can really do CSS justice without free form string values. So I'm inclined to vote against trying to model CSS with some static API.

Although checking values is harder unless we take some subset of FWT to use for color, fonts, insets, etc.

I didn't mean quite that extensive -- I meant string versus number, etc.. If Fan had units then dimensions could have units.

In general, I think that places like this one are clear wins for the features of static typing. You throw away a lot of information by making everything strings. For one, you have to refer to charts, instead of letting the IDE do auto-complete.

Actually auto-complete would be a nice reason to statically type (at least the names).

I do highly recommend incorporating a CSS query engine.

Yep, that's on my list.

Side note, I usually don't get excited about having too many effects.

I agree, outside of show/hide/slide, fading, and color transitions, I don't think there will be much else out of the box.

In general, I think that places like this one are clear wins for the features of static typing. You throw away a lot of information by making everything strings.

I'll take a look at this. In general I don't think you can capture all the variations of CSS very well with static typing. But in our case, there will only be a subset of stuff you can really do with effects.

In general I don't think you can capture all the variations of CSS very well with static typing.

Here's an example of strong typing for CSS properties (only a sketch, most things are not implemented and only a few properties are shown):

class Color {
}

class URL {
}

class Dimension {
}

class Pixels : Dimension {
}

class Ems : Dimension {
}

class BackgroundProperties {
    Color color
    Bool repeatX
    Bool repeatY
    URL image
    Pixels[] position
}

class CSS {
    |BackgroundProperties|? background
    Decimal? opacity
    Dimension? fontSize

    URL url(Str urlString) { return URL(); }
    Color rgb(Int red, Int green, Int blue) { return Color(); }
    Dimension px(Int px) { return Pixels(); }
    Dimension em(Decimal em) { return Ems(); }
}

class Main {
    static Void animate(|CSS| css) {
    }

    static Void main() {
       animate {
          background = {
              color = rgb(1, 54, 34)
              image = url("background.png")
              position = [px(12), px(29)]
          }

          opacity = 1.2
          fontSize = em(2.1)
       }

    }
}

If designing this library, I personally would go as far as the above, because with a proper IDE, you'd get auto-complete on all the names, and the static typing would ensure that every property value made sense. Moreover, the above reads a lot better than maps of strings.

Though designing the above is absolutely more work, in my opinion it pays off in productivity gains (no bugs & no looking stuff up). However, I think you'd get a great deal of benefit by just typing the names & allowing strings for the values.

By the way, Brian or Andy, why doesn't Fan like the it-block assignment to background, above?

Moreover, the above reads a lot better than maps of strings.

I think if we went with strongly typed values, that I would try to pull key classes out of fwt into a reusable graphics API (color, font, dimensions, insets, etc).

By the way, Brian or Andy, why doesn't Fan like the it-block assignment to background, above?

Not today - you would need a type name there. Although I suppose you could potentially infer the type from the lhs of the assignment.

I think if we went with strongly typed values, that I would try to pull key classes out of fwt into a reusable graphics API (color, font, dimensions, insets, etc).

I like that idea in any case, because these things are independent of FWT.

Not today - you would need a type name there. Although I suppose you could potentially infer the type from the lhs of the assignment.

Why do I need a type since I'm assigning to a typed slot? I thought that this was part of the point of the new type inference?

Why do I need a type since I'm assigning to a typed slot? I thought that this was part of the point of the new type inference?

Currently inference only works on closures being passed as an argument to a method call.

Ah, OK, makes sense.

I think if we went with strongly typed values, that I would try to pull key classes out of fwt into a reusable graphics API (color, font, dimensions, insets, etc).

Maybe +1 from me, too. Could definitely be some value there. Would you have arbitrary shape descriptions, pen styles, gradients, and so on, too?

Where's the boundary between such a library and full vector graphics? Or might full vector graphics be good (instead of the three-part simple primitives then drawing then widgets)? They're available almost everywhere now.

Personally, as a side note, I do like the distinction between GTK and GDK, and I wish that line were clearer in AWT.

Anyway, no full answers. Just some thoughts.

WebappClient got dropped quite a time ago and Effect went down the pipe with it.

Was it conceptually wrong or just too incomplete to be supported? Is there a better place where setInterval is to be put (like relayout)?

Was it conceptually wrong or just too incomplete to be supported?

Incomplete and support cost was a big part of it. Another issue was we're seeing alot more of this handled in CSS3, so I was never comfortable with the design looking out several years.

Is there a better place where setInterval is to be put (like relayout)?

If it went somewhere it would go in dom pod. Tho its pretty trivial to do this with a native method and a closure. I would be open to standardizing it in the API.