-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: File Uploading Notifications (fixes #7883) #880
Conversation
@@ -1,9 +1,15 @@ | |||
<div class="ss-uploadfield-item ss-uploadfield-addfile field"> | |||
|
|||
<h3> | |||
<h3 class="has-tool-tip"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Inconsistent spelling, class is called "tooltip" without a dash elsewhere
Looks much nicer this way, thanks Naomi! I'm happy to merge the changes, apart from the tooltip. I don't see the value in making this a CSS3 solution, rather than using a JS library, for a number of reasons:
So, given that we'll want to use tooltips consistently throughout the whole UI (for headlines, form elements, etc), |
Sounds good to me. I wasn't really sure where I'd put any javascript for the tooltip, so stuck to css. Re: upgrading to the latest jQuery, what sort of things should be tested when we do that? Are you planning on doing that yourself, or could I do it? |
I've started the upgrade (to an earlier beta release) here: https://github.com/chillu/sapphire/tree/jquery-1.9 and https://github.com/chillu/silverstripe-cms/tree/jqueryui-1.9 It'll probably require an upgrade to jQuery 1.8 as well, so we'll need to pretty much retest the whole UI. Tabs will be one main focus, and running the entwine tests against 1.8. |
Updated to remove tooltips. I repositioned the file details to below the upload area for now, as it'll be easier to move it from there once tooltips have been implemented. I also included a few lines of styling to stop it looking too ugly. That can be removed once we have the ability to use js tooltips. |
Is this ok to pull now? |
@@ -101,5 +101,92 @@ | |||
*:first-child &{ zoom:1;} | |||
} | |||
|
|||
//**---------------------------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are all those mixins still required now that we've removed the tooltip code?
They look fairly general purpose, but also need documentation to explain
what they're actually doing - its a bit much complexity to add "just in case".
Does anything speak against removing them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, we probably don't need them. They are general purpose, but if we have no need for css animation, then we don't need them here. More complex animations we'd probably have to use javascript for anyway, as a lot of the actions are already javascript*.
I'd be tempted to leave the duration mixin in there, and remove the more complex animation keyframe stuff (and delay, as the use case isn't as general purpose). The duration mixin lets you do simple ui stuff like transition hover changes easily. It might be worth using this effect on our button hover? It might not be worth it though. I can remove them all for now if that's easier?
(* I think it would be nice to animate the expanding and shrinking of panels, particularly the preview as the change is a little jarring.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say remove it all until we have an implemented use case somewhere.
Good point about the performance on panel animation,
I think Hamish has some JS-related optimizations there,
so we'll see how jarring they still are first.
On 1/11/2012, at 12:00 AM, Naomi Guyer notifications@github.com wrote:
In admin/scss/_mixins.scss:
@@ -101,5 +101,92 @@
*:first-child &{ zoom:1;}
}+//*----------------------------------------------------
Good point, we probably don't need them. They are general purpose, but if we have no need for css animation, then we don't need them here. More complex animations we'd probably have to use javascript for anyway, as a lot of the actions are already javascript.I'd be tempted to leave the duration mixin in there, and remove the more complex animation keyframe stuff (and delay, as the use case isn't as general purpose). The duration mixin lets you do simple ui stuff like transition hover changes easily. It might be worth using this effect on our button hover? It might not be worth it though. I can remove them all for now if that's easier?
(* I think it would be nice to animate the expanding and shrinking of panels, particularly the preview as the change is a little jarring.)
—
Reply to this email directly or view it on GitHub.
Put "File upload complete" and "back to folder" together. Turned 'File upload' into a message, and updated the message styles. Moved allowed file types into the area where users are uploading files. This is a temporary fix until js tooltips are implemented, at which point, these details will be shown when clicking a question mark beside "Choose files". Added small animation effect to files when opening iframe to edit. Now slides down, rather than just appearing open Linked to silverstripe/silverstripe-cms#223
I have removed the animation/effects mixins. :) |
Tested in IE7 and Chrome, merged! |
BUG: File Uploading Notifications (fixes #7883)
Linked to silverstripe/silverstripe-cms#223