framework
framework copied to clipboard
lift
We have no vanilla JSArtifacts
Currently we only have JSArtifacts subclasses for JQuery, YUI, and
ExtCore. While we've been toiling away to provide the core of our JS
functionality in a library-agnostic “vanilla” setup, there's currently no
JSArtifacts implementation that can be used with that.
We'll want to tread somewhat carefully here, but this implementation can simply be modern-browser-only, which should make it fairly straightforward to implement.
For now, let's aim for the 3.1 cycle for this guy… We were hoping to have liftVanilla in a usable state by then in earlier discussions.
I'm working on some other issues here right now, but can I call dibs on this one please?
@Bhashit I have no issue with that, and I doubt Antonio will, but just check again whenever you're ready to actually start work. =)
@Shadowfiend I'm ready to start work on this, unless someone's already doing it.
Whoops, didn't reply here… I've got my hands full elsewhere, so go for it!
A bit too late than I would have liked, but I have just started work on this.
Had a few questions/observations about how we want to proceed with certain things.
Some of the functions that we need to implement are toggle, hide and show. When we hide an element and show it back, we'll need to keep track of its previous value of the style.display attribute. I mean, it's possible that the display style attrib was set to some non-default value. I'm thinking of keeping track of using an object hidden in a closure.
One more important thing I wanted to ask was: how complicated do we want to make this? I think this was more targeted at modern browsers, and getComputedStyle is pretty well supported. So, I was thinking of going with that.
What jQuery does additionally is to try and find the default value for display attrib by adding a temp element when it can't find a value normally. Do we want to add that?
One additional question: if we add a bunch of JS code, should it still be included the scala code?
Some of the functions that we need to implement are toggle, hide and show. When we hide an element and show it back, we'll need to keep track of its previous value of the style.display attribute. I mean, it's possible that the display style attrib was set to some non-default value. I'm thinking of keeping track of using an object hidden in a closure.
I would actually prefer we use the display attribute that comes with the DOM instead of rolling our own object that we close over and track. We may not be the only JavaScript on the page that's tinkering with how things display, and reading the DOM is the best way to make sure we're not stepping on the feet of other libraries.
One more important thing I wanted to ask was: how complicated do we want to make this? I think this was more targeted at modern browsers, and getComputedStyle is pretty well supported. So, I was thinking of going with that.
Glancing at the supported chart for getComputedStyle seems fine to me. Anyone who really needs to worry about browser capability can always flip on the jQuery module and pull in jQuery 1.x that still has support back to IE6.
What jQuery does additionally is to try and find the default value for display attrib by adding a temp element when it can't find a value normally. Do we want to add that?
Using getComputedStyle may mean we don't need to do this, unless I'm mistaken.
One additional question: if we add a bunch of JS code, should it still be included the scala code?
I don't understand this question so I don't know how to answer it. :)
The goal of liftVanilla was definitely to lean on modern browser implementations as much as possible.
Thanks @farmdawgnation @Shadowfiend.
I would actually prefer we use the display attribute that comes with the DOM
What I meant there was that we probably need to keep track of the last/previous value of the display attribute when we change it. For ex. if we hide a div which has been set to inline-block, we'll be setting display to none. When the user calls toggle or show again, we should probably make sure that the display attribute is set back to inline-block, instead of the regular block value. It's certainly likely that between the two calls, some other code changes that attribute. But that's how jQuery behaves. So I thought that might be the expected behavior from vanilla-js as well.
When the user calls toggle or show again, we should probably make sure that the display attribute is set back to inline-block, instead of the regular block value. It's certainly likely that between the two calls, some other code changes that attribute. But that's how jQuery behaves.
Ah I misunderstood what you were talking about.
Could we stick that in the DOM too under a special data- attribute? Perhaps data-liftjs-previous-display-value? That would avoid having to track a var in JS space and still permit other JS that's being written to change how we behave when we act on the object.
data-liftjs-previous-display-value sounds perfect. I thought about doing something like that, then thought that maybe we could get away without having to make that visible. But what you said makes more sense. The following part:
still permit other JS that's being written to change how we behave when we act on the object
Will go forward with that approach then.