couple gotchas with css

[mattdesl]

Cool library. 👍

Just skimming the css() function and noticed a couple pitfalls that you may want to mention in the docs.

• there is no vendor prefixing on css()
• case is not normalized; so element.css('backgroundColor') !== element.css('background-color')
• this also means css('zIndex', 0) is treated as pixels, css('z-index', 0) is treated as a number
• does not handle cssFloat edge case

[bendc]

Thanks a lot @mattdesl, great feedback :)

You're absolutely right about mentioning the case differences, will fix. I'm not sure to understand what's the cssFloat edge case though?

[xzyfer]

I believe this is what @mattdesl is referring to -

element.style.cssFloat = 'left'; // correct
element.style.float = 'left'; // incorrect

Note: If you're referring to this property from JavaScript as a member of the element.style object, you must spell it as cssFloat. [...] This is an exception to the rule that the name of the DOM member is the camel-case name of the dash-separated CSS name (and is due to the fact that "float" is a reserved word in JavaScript, as with the need to escape "class" as "className" and escape 's "for" as "htmlFor").

source - https://developer.mozilla.org/en-US/docs/Web/CSS/float

[bendc]

Oh ok yeah, sure. Well I guess this could just fall into the "just use CSS property names" restriction from @mattdesl's other comments. Some things do work, like element.css('backgroundColor', 'red') but I feel like giving just a simpler, more restrictive note about property names will be easier here.