[buddypress-trac] [BuddyPress] #3611: Activity update UI doesn't really work with javascript disabled
buddypress-trac at lists.automattic.com
buddypress-trac at lists.automattic.com
Thu Oct 6 21:14:39 UTC 2011
#3611: Activity update UI doesn't really work with javascript disabled
--------------------------+-----------------------
Reporter: boonebgorges | Owner: DJPaul
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: 1.5.1
Component: Activity | Version: 1.5
Severity: normal | Resolution:
Keywords: has-patch |
--------------------------+-----------------------
Comment (by boonebgorges):
> I removed the "no-js" class in jQuery via a modified global.js
I tried that too, but it's no good. If you put the script outside of the
jq(document).ready function, then it fires before the <body> element is
available, so it does nothing. If you put it inside of the 'ready'
function, then you get the same flicker. The inline JS is not particularly
beautiful if you're viewing the source of the page, but at least it's
included by a function, and doesn't muck up the header.php template, which
more human beings will look at anyway.
> One thing that should be in the patch is to check if someone is already
using the "no-js" class. Use array_unique().
Good call.
> I'm still a fan of animating the textarea back up after the document is
ready. But, that's just me!
Ha ha. I find it to be distracting. It doesn't really add anything to the
user experience (where I think the downward animation does, because it
takes away the visual elements until they're actually needed), so ends up
being eye-candy only. But I'm no expert, and would happily be overruled if
everyone else thought the animate-down technique was best.
> 4.patch gives bp-default no-js support
I think it's the best thing about it :)
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3611#comment:10>
BuddyPress <http://buddypress.org/>
BuddyPress
More information about the buddypress-trac
mailing list