Well, to be clear, this section of the jQuery code probably isn't ready for this expansion yet - I'm going to be refactoring the attribute/css code and will be splitting apart (giving you access to the element, as well). I was planning on landing some of the custom attribute/css property hooks then as well. Currently I have this slated for 1.3.4. Obviously this doesn't help you right now, but just giving you a heads-up.
--John On Thu, Mar 5, 2009 at 2:41 PM, Daniel Friesen <[email protected]> wrote: > > Ok, I'm going to need some input on how to fix an issue I've run into > while coding that css extensibility. > > Currently the API for that sits in a jQuery.css.callbacks list, to > extend .css to support another obscure css type you'd use: > > jQuery.css.callbacks.push(function( style, name, value, force ) { > if( name != 'somePropName' ) return; // abort > > if ( value === undefined ) { // get > var realValue = jQuery.rawCSS( ???, name, force ); > ... do something ... > return realValue; // return the data should not be undefined > } else { // set > ... do stuff ... > return style.somePropName = value; > } > }); > > name is the property name, it should always be passed in the camelCase > format, no float or other normalization should be done other than > camelCasing it. > value is the value to set. If undefined a css get is being called, if > set to any other value a css set was called. > force is only passed for css get, it contains the value for force > which was passed to curCSS and should be passed on to rawCSS. > > > The issue here is style vs. elem; The callbacks are called in > both .attr and .curCSS, for setting or getting. The .attr only knows > about the style object because the element is not passed to it, > while .curCSS knows about the element passed. For that reason I stuck > with the lowest common denominator and passed the style object in the > api. > However, .rawCSS requires the elem and can't work with the style > object because it needs to do calculation sometimes and that requires > the element object. > > I have a few options on how to handle this issue, input on how to fix > it is welcome. > A) Pass elem during get, and style during set. > .attr (set) knows style tag only, .curCSS (get) knows elem. elem is > only needed for getting css so a style tag could be sent instead for > attr. > The disadvantage of this is that the api would become inconsistent, at > the same time it would also make it impossible to properly get other > values of the css, which is something that could potentially be > useful, like to support relative values ;) .css({top:"+=25px"});. > > B) Instead of force, pass a getStyle method to the API. > Originally instead of passing the force argument I originally had > moved the rawCSS code into a local closure and passed it to the api. > You'd use ( style, name, value, getStyle ); and call getStyle( name ); > to get the style. The elem and force arguments that the raw css stuff > needed were made available through the closure. > Like A) this method is both a little ugly, and still only works during > css getting so you can't get anything while setting. > > C) Fix the jQuery API so that when you are setting a css value you > actually know what element you are working on. > Right now the setting of a css value is done inside of jQuery.attr, if > a style is passed instead of a node it sets css values instead. > jQuery.attr is used in this way inside of jQuery.fn.attr > (jQuery.fn.css calls jQuery.fn.attr), jQuery.curCSS (only to get > opacity for IE's filter), and a bit in jQuery.fx; > The jQuery.attr function itself is actually quite separate in it's > code, there is almost no code at all common between working with a > elem attr or a style css, in fact the only common code before > jQuery.attr checks if it's working with an elem or a style and stops > sharing any code is checks for bad input, .support property > normalization, and a check to see if things are being set or got which > is stored in a set boolean. > As well everything calling jQuery.attr for style reasons other than > jQuery.fn.attr is purely for the purpose of style, there is nothing > dependent on what it was passed and they all know about their elem. As > for jQuery.fn.attr it's explicitly doing `jQuery.attr( type ? > elem.style : style, ... );` so it would be fairly trivial to force it > to use a different function for setting css instead of attributes. > The advantages here are that this actually cleans up a bit of > unnecessary style code in attribute setting, and attr setting code > isn't always being called in the backend to handle css setting, as > well this is the only option that allows you to get css values while > you are setting. > The disadvantage is that any plugin directly calling the lower level > jQuery.attr( style, name, value? ); method will not be compatible > anymore and will need to update to something like jQuery.setCSS( elem, > name, value? ); > > Input on what option is preferred would be appreciated. > -- > ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://nadir-seen- > fire.com] > -Nadir-Point & Wiki-Tools (http://nadir-point.com) (http://wiki- > tools.com) > -MonkeyScript (http://monkeyscript.org) > -Animepedia (http://anime.wikia.com) > -Narutopedia (http://naruto.wikia.com) > -Soul Eater Wiki (http://souleater.wikia.com) > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
