This convention is familiar to me, as it was used by Smalltalk. You might get a value with banner height and change it with banner height: 100. Knowing it was a smalltalk convention is enough to expect me to like it, since I have an distant but abiding love for that language. But even the best things have flaws, and I can't hide my dislike for this coding style.
My principal objection is that the act of retrieving data is fundamentally different to that of setting a value, so the names should be more clearly different.
Another reason is the confusion between a setter and a getter that takes an argument. If I see $("#banner").css('height') the general expectation is that it's setting a css property to 'height'. It's only my knowledge of the jQuery API that tells me that css('height') gets the value of the height, which I would update with css('height', 100).
I'm not proposing that Java's ugly getHeight() / setHeight(100) convention is better. I think using a bare value for the getter is usually the best way. My preference is to make any setter clearly stand out.
In general I like to do this through different syntax, so the property setting syntax of C# and Ruby scores best here. In these languages you can get a value with banner.height and change it with banner.height = 100.
1: Technically it isn't an overload, as 'height' and 'height:' are different names (due to the colon). But it certainly feels like it.