Opened 13 years ago
Closed 13 years ago
#3611 closed defect (bug) (fixed)
Activity update UI doesn't really work with javascript disabled
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 1.5.1 | Priority: | normal |
| Severity: | normal | Version: | 1.5 |
| Component: | Activity | Keywords: | has-patch |
| Cc: |
Description
Instead of hiding the post button by default, we should probably do it with JS (or put a visible button in <noscript> tags maybe).
Attachments (4)
Change History (16)
#4
@
13 years ago
Forgot to mention that we should probably think carefully about backpat too - I don't think that either of the proposed patches would affect existing themes very much (aside from the fact that bp-template-pack type themes simply wouldn't get the enhancement), but we should think about it. If the changes are considerable enough, this is probably puntable (though I am a firm believer in the idea that if it doesn't degrade gracefully, it's broken)
#5
@
13 years ago
If we're thinking of backpat, Paul's patch would deploy on BP Template Pack and child themes (provided that child theme authors haven't touched those textareas or the JS of course).
3611-3.patch proposes animating the textarea back up, thus removing the flicker.
The patch also moves the "Post Update" button a little to left, since it isn't properly aligned in IE, Firefox and Opera (though it works in Chrome).
Disregard the overflow stuff; I was testing on an older version of Opera.
#6
@
13 years ago
I think Boone's patch is best so far; good point about the DOM loaded event and flickering. What about the way wp-admin deals with this? Check out WP admin-header.php line 104ish (the no-js line). We can just double up the CSS to avoid inserting more JS.
#7
@
13 years ago
I think that the WP solution will be a handy thing to have around more generally: set this body class in one place, and solve the rest of the issues with CSS. Going to work on a patch.
#8
@
13 years ago
3611-4.patch implements the wp-admin technique of setting the body class to 'no-js' by default, and swapping it out with 'js' as soon as the body element has begun to render. IMO this is a nice way of handling noscript more generally - this new body_class trick will give us something to work with in the future.
If others are in agreement, the only question is whether it's OK to implement this in a maintenance release. Adding a new body class *could* introduce style conflicts, especially if people are loading wp-admin styles on the front end for some reason. Thoughts?
#9
@
13 years ago
I've done something similar to 4.patch in a child theme, though I removed the "no-js" class in jQuery via a modified global.js.
In principle, 4.patch is the same as 2.patch. On the positive side, 4.patch gives bp-default no-js support; the con to both is inline JS.
One thing that should be in the patch is to check if someone is already using the "no-js" class. Use array_unique().
I'm still a fan of animating the textarea back up after the document is ready. But, that's just me!
#10
@
13 years ago
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 :)
#11
@
13 years ago
I removed the "no-js" class in jQuery via a modified global.js
For my needs, which was not related to this issue, it was sufficient.
---
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.
The functionality is to remove the flicker ;) I understand what you mean though.
So, the trade-off here is that we get a little flicker, when the page is rendering but before $(document).ready() is fired, where the button shows.
We could work around it in a couple different ways. One is to output the necessary js directly after the form is rendered. See 3611-2.patch. It's done with a hook, so we don't have to clutter up the templates.
A similar approach is to hide it by default with CSS, and then to output some inline CSS to show it, wrapped in <noscript> tags.
Neither is really beautiful, or has quite the elegance of Paul's solution, but it does *look* a bit better. Thoughts?