I don't have much problem with using a nightly at work. For now I'll
probably just use some plain css for setting borderRadius on tooltips
till I can get a nice method of using .css;
Feel free to give me a poke when you've refactored that section of the
code, I'd be happy to setup the extensible css when it'd done. I'll
probably do something a bit cleaner too.
jQuery.css.addHook(function( name, value, force ) {
if( !name.match( /^border-((top|bottom)-(left|right))?-radius$/ ) )
return;
if( value === undefined) {
if( name === "borderRadius" ) {
...
} else {
return jQuery.rawCSS( this, name, force );
}
} else {
if( name === "borderRadius" ) {
...
} else {
value = ...;
return elem.style[ name ] = value;
}
}
});
I've actually been debating camelCase vs. dashed-form. The camelCase can
be good to make setting easy. But dashed form is much easier to handle
when dealing with vendor extensions. It's /^-jq-/ vs. /^Jq[A-Z]/; There
might also be some merit to making rawCSS also support setting
`jQuery.rawCss( name, value, force );` to make dealing with names and
.support .prop transformations transparent. I did consider using the
return value, however that would limit what you can set, and my work
with borderRadius is a good testcase on how far some of the more complex
use cases can go, even just trying to make things compatible.
http://test.4query.org/borderRadius.js
Not even complete, and you can see all the code for handling different
versions of border radius (Instead of border-top-left-radius FF uses
-moz-border-radius-topleft), and whether or not the browser has
irregular curves support (nicely handled with feature detection so if FF
implements it, it won't degrade).
~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)
John Resig wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
