Dave Methvin wrote:
>>>> I ran into a number of times where I needed to grab a
>>>> series of css values and set them all onto another,
>>>>
>
>
>>> This functionality overlaps with what you were proposing in #4295
>>>
>
>
>> That bug has nothing to do with the caller interpreting complex
>> shorthands.
>>
>
> I agree; I was looking at the functionality you wanted in your
> original statement--grabbing a series of css values.
>
Really it's just mapping a 'margin' call to individual marginTop
marginRight marginBottom marginLeft calls and joining them together. The
reason being because browsers do not handle calls to the shorthands
consistently but they do handle the individuals correctly. Calling
'margin' in half the standard browsers will return an empty string
(which will unset stuff instead of setting it right) if the style is set
in the stylesheet instead of directly on the style tag.
>> I see no reason to require people to use
>> $(node).css(['marginTop', 'marginRight', 'marginBottom', 'marginLeft']);
>> when it's perfectly valid (and more likely) for them to try using
>> $(node).css('margin');
>>
>
> With .css("margin") (or "border" or "padding") it seems like there is
> only one thing a caller could reasonably do without parsing it--pass
> it back to .css("margin", value) to be set. Are there a lot of
> situations where that is needed?
>
> I can see useful cases for .css(["prop1", "prop2"]) but not many for
> css("shorthandProperty"). If you have the former, the amount of code
> you need to write inside your own app will probably be less than if
> you had the latter and tried to parse out the individual properties.
>
Passing it back to .css to reset, passing it to .css to copy styles,
saving it in a database, displaying it. Using it in an animation. Any
reason you want to use a css property get (quite frankly, a good
majority of css properties include units or whatever so I don't see many
other uses for most properties where you wouldn't parse things).
Quite frankly, my reason for wanting a fix for 'margin' and the like is
simple. Unless someone specifically wants a single edge of the margin,
they will not use marginEdge, they will use margin, and if they use that
they will run into this browser inconsistent bug. Even worse because
this is an inconsistency between browsers they will likely develop with
one output in mind and likely lead to things breaking in others. The fix
has the side effect of smoothing things over and making all browsers
give the same output so jQuery users don't have to sweat the issues with
compatibility between browsers (just like why .bind abstracts between
the different ways browsers bind events).
While some bits of these two functionalities overlap I don't believe
these overlap in code nor overall purpose enough to really be considered
overlapping. They both have their own purpose so I don't see any reason
to compare one to the other in deciding what to implement (apples vs.
oranges).
One is a browser inconsistency fix. The other is an enhancement to make
programming simpler. To be honest they are also implemented in two
different ways. The fix is a piece in jQuery.css and the enhancement is
likely a change to jQuery.fn.css or jQuery.fn.attr;
There was a "performance" and "code size" note brought up in the replies
to the bug. But I don't see how these are real concerns. The code is
only run if you are actually using these properties (if you're not then
code never gets past the conditionals and just continues like usual).
The only real point might be the movement of some of the code into a
closure or a new jQuery.rawCSS method. I recommend the use of the
.rawCSS method over the closure method, it should perform better (heck,
in some use cases it could be considered a performance enhancement for
plugins) and it has nice re-usability case. In fact that same change has
a use case in another little project, making .css extensible so that
plugins could add support for some obscure css properties like
borderRadius or transform. (That project is pending on John's .curCSS
.attr code refactor.)
Heck, if the tiny change in code for that fix is so much of a concern it
could honestly be implemented in a plugin using that .css extensibility
enhancement when complete. We could have multiple levels of
compatibility enhancement plugins people can use with jQuery; CSS
Compatibility level 1: Fixes to browser incompatibilities in standard
css properties like margin; CSS Compatibility level 2: Fixes to support
css properties in w3 draft like borderRadius and transform in as many
browsers as can handle it (^_^ Heck, we could include animation ability)
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
