[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/>

More information about the buddypress-trac mailing list