You, as the software provider or authorized by him, are closing a bug without fixing it, based on information from workarounds that the requester/users provided. My attached testcases provide such workarounds, and I can produce any number of them.
As I wrote before, it is an obvious fallacy that other use cases that bypass the bug (e.g. your suggestion to use the css() method), can be used as proof to invalidate the original case.
This is very disappointing because the issue is at the heart of a core jQuery competency - providing a more reliable and simplified cross-browser API.
The bug has been pinpointed:
jQuery actively creates flicker via its own DOM manipulation in the css() call via swap(). Therefore, flicker can only be avoided if the caller is lucky enough to anticipate and match the values that jQuery sets so that the browser ignores them instead of executing them.
Sure, we are able to create such a case specific lucky situation here and say: Where is the problem? That is what you are doing, and this is unprofessional, deceiving and distracting.
It is ridiculous to suggest that I use the method (css()) that causes the flicker - to work around the flicker.
Can't you see that you have gone full circle based on the variety of testcases?
I have now created multiple extremely simple, distinct testcases that produce the same behavior. Let me add one more, lifting the total of failing different cases to three:
This is standard, bare-bones, consistent, by the book jQuery API use.
GUI toolkits, including browsers, provide non-destructive methods to measure components before showing them. Why should jQuery be the exception?
I am suggesting that this issue is treated as what it is, a bug in the framework. More specifically, I am requesting that the aggresive call of the swap() method is replaced by defensive code.