Opened 13 years ago
Closed 7 months ago
#18909 closed enhancement (wontfix)
Bundled jQuery UI should have CSS
Reported by: | helen | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.3 |
Component: | External Libraries | Keywords: | needs-patch close |
Focuses: | ui | Cc: |
Description
Now that all of jQuery UI is in core, matching CSS should also be included for use in the admin in both color schemes.
Related: #17952
Attachments (3)
Change History (99)
#3
@
13 years ago
There's no reason why a custom theme couldn't be theme-rollered rather than just going with an existing scheme - that way, there could be one for the gray and blue back-end styles if necessary.
#4
@
13 years ago
- Cc kpayne@… added
Here's a first attempt at a WP themed jQuery UI - http://x.co/aI5y
Some of the controls don't match up (e.g. active buttons are the same as active tabs / accordion bars) but the other pieces seem close. Please tweak.
#5
@
13 years ago
- Owner set to helenyhou
- Status changed from new to assigned
I'm currently testing gray and blue themes within the admin itself. Will post when tested.
Thought: Themeroller uses images for background gradients (and flat ones too, but I'm removing those). Better to change to CSS3 gradients with fallback as in the existing admin CSS?
#6
@
13 years ago
Screenshots of demo page:
- Gray (fresh): http://cl.ly/2U0S2F3N2f3324000q3z
- Blue (classic): http://cl.ly/143p1W3M3z3T1A2u0X3j
#7
follow-up:
↓ 8
@
13 years ago
@helenyhou, these look good!
What are your thoughts about blue button controls? Just use the a standard input with class="button-primary"
instead of a jQuery UI button?
#8
in reply to:
↑ 7
@
13 years ago
Replying to kurtpayne:
What are your thoughts about blue button controls? Just use the a standard input with
class="button-primary"
instead of a jQuery UI button?
Yeah, if somebody wants a blue button, they should use what's already provided. My thought here is really just to provide some basics for jQuery UI bits that match the admin and hopefully give developers a way to use elements that blend in for a more uniform experience for the user.
azaozz and I talked briefly about what maybe-should go in wp-admin.css
, what maybe-should go into colors-*.css
, and whether it'd be better for these styles to be available but not enqueued by default. Have to think on it some more and how that would work with the color schemes. And make the CSS as light as possible, of course.
#11
follow-up:
↓ 14
@
13 years ago
- Keywords ui-feedback dev-feedback added
The screen shots are looking great.
A concern would be that when ui updates, the theme would have to be re-rolled (wouldn't it?) and whatever changes you've made updated also.
I'd rather keep the maintenance upstream by just including the "Smoothness" (for fresh) and "Cupertino" (for classic) Themes in their default state, and not merge them into wp's css. Should be way easier for maintenance.
"Smoothness" and "Cupertino" seem really close to the admin themes as is...
I think it'd be nice to eventually move the core ui elements into these themes (but probably not right a way as that'd be much refactoring for little benefit I suppose).
Just some thoughts
#12
@
13 years ago
Or even Redmond for Classic on PCs... Enqueue the style based on OS's, lol (I kid, I kid).
#14
in reply to:
↑ 11
@
13 years ago
- Owner helenyhou deleted
Replying to WraithKenny:
A concern would be that when ui updates, the theme would have to be re-rolled (wouldn't it?) and whatever changes you've made updated also.
That's a good point. I haven't seen jQuery UI updates that are really drastic, but it would be some maintenance to keep track of any changes. Splitting the stylesheets out into structure and then color variants a la the WP admin sheets seems like it should help keep it a light task, perhaps not much more than grabbing the latest. I did in fact start from a base of Smoothness, which works out well with the default gray scheme, but not so much with blue. Would love to use images for the icons only, though, which UI doesn't, not even for flat backgrounds (ugh).
Any thoughts on "CSS Scope" so that core/themes/plugins can avoid conflicts?
I've been thinking that I want to see if the idea in #18380 about admin colors (which I really like) gets revisited and go from there, especially regarding the split of colors. Since by default everything is classes, it should be easy to override as needed. I didn't notice any core conflicts with my demo plugin the last time I looked, which I should dig back up and post here.
Overall, what I notice is that there seems to be some expectation that the ability to enqueue UI bits means that they will "just work" when used, which is not really the case with jQuery UI. Given the things and inconsistencies that often happen when devs have free reign (theme options come to mind), it still seems like a good idea to have kind of base included in core.
Maybe a dumb question, but is it possible to have a JS enqueue also enqueue CSS somehow?
#16
follow-up:
↓ 18
@
13 years ago
I don't think JS can enqueue CSS, though someone might have a crazy workaround.
What I meant with "CSS Scope" is the jquery ui themeroller download allows you to prefix a class or id to the css theme, which limits the ui theme to a selector, so that you can have more than one ui theme in operation at a time. I'd figure ".wp-ui" or something on core elements, so that plugins/themes can use ".myplugin-ui" on their container elements with a different color scheme. If "classic" color scheme gets pushed out to a core plugin, perhaps this scoping would help with that also.
#17
@
13 years ago
I didn't think so, but worth asking.
I'm not sure I can think of a reason to prefix anything to the theme, but maybe you're thinking of something I'm not. If it's left generic, then it would be easily overridden using specificity, either by somebody using the scope piece in Themeroller or within their own CSS.
If the aim is consistency and ease-of-use, there's no real reason to scope whatever might be included with core, and it would only be loaded in the admin anyway. I did mention earlier that it might be better if any CSS was just enqueuable and not necessarily included in the great big admin stylesheet, but then it wouldn't really just work.
I imagine any color schemes would just override with the cascade order like blue does now, so again, no real reason to scope in, especially since structure should stay the same. The only thing would be that color schemes wanting to be thorough would need some more work, but with using gradients and such it shouldn't be very heavy.
#18
in reply to:
↑ 16
@
13 years ago
Replying to WraithKenny:
(...) jquery ui themeroller download allows you to prefix a class or id to the css theme, (...). I'd figure ".wp-ui" or something on core elements, so that plugins/themes can use ".myplugin-ui" on their container elements with a different color scheme(...)
IMHO Prefixes wouldn't be a good idea as this could lock jQuery plugins out, that rely on the basic approach.
If you share a link to your theme proposals, then others can start working from there. The jQuery UI Themeroller appends all definitions to the uri string in realtime. Example here - Yea, it's not the best and only half finished. This would also avoid the need for screenshots.
#19
@
13 years ago
I don't have a link to my Themeroller starting point anymore, but I put up a plugin on Github that has both gray and blue schemes included on a demo page in the admin: https://github.com/helenhousandi/wp-admin-jquery-ui
#20
follow-ups:
↓ 21
↓ 22
@
13 years ago
helenyhou, the themeroller links still there! They are on line 53 of the css files
#21
in reply to:
↑ 20
@
13 years ago
Replying to kurtpayne:
helenyhou, the themeroller links still there!
Ha, yep, saw that when I finally went in to start making the gradients in CSS3 instead of images (will put that up on Github soon). These have been sitting for a while. Thanks :)
#22
in reply to:
↑ 20
;
follow-up:
↓ 23
@
13 years ago
Replying to kurtpayne:
helenyhou, the themeroller links still there!
Puh, kool! :)
Btw, two things: Please take a look at the Drop shadow definition of my link which fully imitates the WP overlay (if I'm not lead wrong). And there's also a FireFox bookmarklet for Themeroller available. Should help speed things up.
#23
in reply to:
↑ 22
;
follow-up:
↓ 24
@
13 years ago
Replying to F J Kaiser:
Please take a look at the Drop shadow definition of my link which fully imitates the WP overlay
I've updated it on Github to have both CSS3 gradients and a matched overlay and box shadow. Also, the blue progress bar from media upload.
#24
in reply to:
↑ 23
;
follow-up:
↓ 25
@
13 years ago
Replying to helenyhou:
I've updated it on Github to have both CSS3 gradients and a matched overlay and box shadow. Also, the blue progress bar from media upload.
Could you please leave a link to your current status in the readme.md file @github? This way, I could fork your work, click the link, make some progress and send you a pull request.
Currently I don't know how I could contribute to your repo without starting from scratch. Another thing that would be nice, would be a "simple stupid" screenshot (from for e.g. MS Paint) to illustrate what's missing and needs to be touched next.
#25
in reply to:
↑ 24
;
follow-up:
↓ 26
@
13 years ago
Replying to F J Kaiser:
Could you please leave a link to your current status in the readme.md file @github?
Not quite sure what you mean by status?
Currently I don't know how I could contribute to your repo without starting from scratch.
Why is that?
Another thing that would be nice, would be a "simple stupid" screenshot (from for e.g. MS Paint) to illustrate what's missing and needs to be touched next.
I can add screenshots, but that's why it's in plugin form - so you just have to install it and you'll see everything, including the interactive states.
#26
in reply to:
↑ 25
;
follow-up:
↓ 28
@
13 years ago
Replying to helenyhou:
Not quite sure what you mean by status?
Just a link from the URl bar. Like shown above. So I can click the link (alias status/progress) and continue working. Then I update the link in my fork, add a pull request and the next one can continue working right in the Theme roller from the last update.
Currently I don't know how I could contribute to your repo without starting from scratch.
Why is that?
Because of the written above: No link to the theme roller with all the styles that defined the download package, no contribution possibility. The Theme roller adds all styles dynamically to the url, so sharing the url, makes it possible to work together.
#28
in reply to:
↑ 26
;
follow-up:
↓ 29
@
13 years ago
Replying to F J Kaiser:
No link to the theme roller with all the styles that defined the download package, no contribution possibility. The Theme roller adds all styles dynamically to the url, so sharing the url, makes it possible to work together.
Actually, what I've done deviates pretty far from what Themeroller provides, so giving the link to where I started with Themeroller would not be very helpful but rather more of a setback. I'm still confused as to why you can't fork from the Github repo itself? After all, that's why I put it there and not right here on Trac.
#29
in reply to:
↑ 28
;
follow-up:
↓ 30
@
13 years ago
Replying to helenyhou:
Actually, what I've done deviates pretty far from what Themeroller provides, so giving the link to where I started with Themeroller would not be very helpful but rather more of a setback. I'm still confused as to why you can't fork from the Github repo itself? After all, that's why I put it there and not right here on Trac.
I understand that not everything can be done via the Theme Roller. But at last it's the base and somewhere you've stopped there, downloaded the files and pushed them to Github. If I'd now find something that should be changed and could be done in the theme roller app, I'd have to do it by hand without a link, which is much more effort and a lot of search/replace.
#30
in reply to:
↑ 29
;
follow-up:
↓ 31
@
13 years ago
Replying to F J Kaiser:
But at last it's the base and somewhere you've stopped there, downloaded the files and pushed them to Github. If I'd now find something that should be changed and could be done in the theme roller app, I'd have to do it by hand without a link, which is much more effort and a lot of search/replace.
And then either you or somebody else would have to merge in whatever those changes were into what's on Github, or else it really is just starting over, not collaborating on what I've put out there (which is fine - I don't think you absolutely have to use what I've started on). I modified the files quite a bit between downloading from Themeroller and what you see on Github now.
I'm still confused as to why there's such a focus on Themeroller as an end point rather than a starting point. You can make the changes you want in the CSS itself, because that's all Themeroller does. If you really really want the link to where I started, it's in the stylesheets, as kurtpayne pointed out.
#31
in reply to:
↑ 30
;
follow-up:
↓ 32
@
13 years ago
Replying to helenyhou:
I'm still confused as to why there's such a focus on Themeroller as an end point rather than a starting point. You can make the changes you want in the CSS itself, because that's all Themeroller does.
Yes: A starting point. But if you need to go back and change for e.g. the border radius, then it's a pain, doing that in the plain css files. Copy/pasting the uri and editing it via theme roller (that changes all radius within a second) is simply much faster.
If you really really want the link to where I started, it's in the stylesheets, as kurtpayne pointed out.
Overread that. Thanks.
#32
in reply to:
↑ 31
@
13 years ago
Replying to F J Kaiser:
Copy/pasting the uri and editing it via theme roller (that changes all radius within a second) is simply much faster.
I'd think that merging the changes together with another altered sheet would be much slower than a simple search-and-replace.
#34
@
13 years ago
To follow the development so far, these are the steps taken to date:
The original base for the CSS was "Smoothness" http://jqueryui.com/themeroller/
"Smoothness" was altered using ThemeRoller to arrive at the initial commit for github (See CSS source for the url link which shows this ThemeRoller configuration)
"CSS3 gradients instead of images, blue gradient for progress bar" https://github.com/helenhousandi/wp-admin-jquery-ui/commit/ea08c09bbca3f73be325e67b879659a78dd7f882
"Better matched overlay and drop shadow (per F J Kaiser)" https://github.com/helenhousandi/wp-admin-jquery-ui/commit/7c3c4de3e3de97aeb6be37e9274fdccaadf60ec4
You should now be all caught up.
#35
follow-up:
↓ 37
@
13 years ago
I think that in the event of a major WP admin refresh, or a major jQuery-UI update, retracing (redoing) the steps above might be better then forking the current state of the theme and back-applying compatibility for the (possibly cryptic or even drastic) wp-admin or jquery-ui changes.
It comes down to whether its easier redoing the two github commits or search/replacing whatever changes occur in wp-admin or jquery-ui (which really depends on how significant those changes are). With major changes the former is better; minor changes, the latter is better.
#36
@
13 years ago
- Cc ciantic@… added
- Version changed from 3.3 to 3.3.1
Edit: Most important is not the CSS files, it is the enqueue handle name. If you guys can come up consistent and single enqueue handle name then admin can re-register classic or fresh or whatever as that.
Also if plugin developers had a single handle this cross-plugin multiple theme problem would not even exist! As everyone would try to register their jquery ui themes with same handle, thus only one theme would be included.
Okay people decide colors later.
Bundle one theme (at the moment colors doesn't matter!) and call it the WP jQuery UI theme e.g. jquery-ui-wptheme
, then advice every plugin developer to use it like this:
wp_enqueue_style("jquery-ui-wptheme")
Make great warning for plugin developers so they won't add their own themes anymore, no matter what, I don't want to deal with admin pages with multiple jquery themes loaded.
Then, make a patch, and commit, provide it in WP 3.3.2.
And voila! Cross-plugin compatibility solved. Then everyone can just stop bundling separate themes that doesn't work together in the admin.
After this glorious moment, start to ponder the colors. And commit these later, there is no reason to wait for colors to shape until bundling any theme! Current behavior is broken, as separate plugins may provide different themes.
#37
in reply to:
↑ 35
@
13 years ago
Replying to WraithKenny:
My basic opinion is this: Themeroller can create a good base to start from, but it's not a finished product, especially given all of the background colors as images.
I would think that the stylesheet could just be tinkered with unless jQuery UI completely changes the way they do things (unlikely) or the admin is drastically visually altered (even more unlikely, given the recent refresh). In either of those cases, then yes, perhaps it would be easier to start with Themeroller than from scratch, but I'm still opposed to the idea that we should just be using a GUI-produced package that only sort of matches. Besides, if you look at the sheet for Smoothness vs. what I've got so far, I think you will find minimal changes.
Replying to ciantic:
If this is included at some point (it has not been given a green light by any means, it's just a proposal), it will certainly be registered with a name that makes sense, but I don't see what the point of any of this is without CSS that makes jQuery UI appear to be native to the WordPress admin. Also, there is no way it would be in 3.3.2 if such a thing comes to exist, as it is neither security nor maintenance but an enhancement.
I have some other thoughts about admin colors that might affect where this goes. I'm leaning toward having one included file (fresh/gray), registered but not enqueued anywhere.
#38
@
13 years ago
I'd really like to see this in 3.4. It was a fantastic step in 3.3 to package the UI core elements, so the next step would no doubt be to do the same with the UI css.
As is right now, it still provokes many issues. In our Custom Metaboxes script on github (https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress) one of the options is a datepicker. We were able to include the datepicker packaged in core with the most recent version, but the CSS has still been an issue.
Originally I packed a strip down version of the ui CSS that I had generated from the UI website, however no matter how much we tried it conflicted with WP core CSS for jquery UI modals and other core CSS elements. The only solution, which wasn't a great one, was to prefix all the CSS and then use jQuery to wrap a div around the datepicker.
Issues like this wouldn't be a problem if the CSS was available in core for plugins and scripts to call, so I'd definitely love to see that happen.
#39
@
13 years ago
Helen, indeed, I looked at your edits and agree they are a great improvement, and don't appear too hard to maintain.
+1 to getting the gray theme included (registered, not enqueued) into the 3.4-alpha at this point for testing. (I personally see this as a bug fix.)
#40
@
13 years ago
There certainly seems to be enough interest here to keep these colors sync'd/maintained as future changes occur. Can we get a summary, patches, and screenshots?
#42
@
13 years ago
- Keywords has-patch added; needs-patch removed
- Version changed from 3.3.1 to 3.3
Going with just gray for the moment.
Screenshot: http://cl.ly/0H0f173a2C400G3g0Y14
Patch: 18909.diff (didn't svn add the images), files in jquery-ui-icons.zip should go in wp-includes/images
Summary:
- Started with a Themeroller base. Images reduced to icons only, all other gradients done with CSS3.
- Registered with handle
wp-jquery-ui
, not enqueued anywhere by default. - Known conflict: UI dialog, e.g. TinyMCE linking.
#43
@
13 years ago
For as far as I know most plugins just use the jQuery ui-icon-circle-triangle
arrows to navigate and such and therefore leaving the rest of the icons as is.
As this is often the case, should we perhaps use the WordPress default /wp-admin/images/arrows.png
instead of the jQuery ones?
Besides that I'd definitely go for using Georgia, "Times New Roman", "Bitstream Charter", Times,serif
in most cases
#45
@
13 years ago
Thanks to @helenyhou for pointing me to this ticket. I completely missed it and opened #20035 just for tabs. To replicate the tabs used for categories etc all you need is the right HTML/classes and the small 18909.2.diff which adds ui-tabs-selected
to the styles where wp-tab-active
currently is. Then just do something like this:
<script> jQuery(function($) { $( '.tabbed-content' ).tabs(); }); </script> <div class="tabbed-content"> <ul class="wp-tab-bar"> <li class="ui-tabs-selected"><a href="#tabs-one">One</a></li> <li><a href="#tabs-two">Two</a></li> <li><a href="#tabs-three">Three</a></li> </ul> <div id="tabs-one" class="wp-tab-panel ui-tabs-hide"> Tab One Content </div> <div id="tabs-two" class="wp-tab-panel ui-tabs-hide"> Tab Two Content </div> <div id="tabs-three" class="wp-tab-panel ui-tabs-hide"> Tab Three Content </div> </div>
Of course that assumes you've already done wp_enqueue_script( 'jquery-ui-tabs' );
#48
follow-up:
↓ 49
@
12 years ago
- Cc kontakt@… added
I agree with ciantic - I think most important is to have any styles at all in core instead of having all plugins define their own styles and it would be great to have this be part of WordPress 3.4 if that is still possible.
If the suggested style can't be completed in time then I would suggest adding one of the default jQuery UI styles as that's still better than each plugin doing their own thing.
Would be great with a status update on this - what's the next step? What needs to be done to make this happen? What help is there a need for?
#49
in reply to:
↑ 48
@
12 years ago
Replying to voxpelli:
Would be great with a status update on this - what's the next step? What needs to be done to make this happen? What help is there a need for?
Way too late for 3.4, but this needs testing on various screens (I know of at least one conflict), blue counterpart (initial CSS is done over on Github, but needs to be included in a patch), and I think that perhaps the UI tabs look should be more like what's currently used in core for tabs in places like the category metabox. Basically, more eyes on how it looks and interacts than just me :)
#50
follow-up:
↓ 51
@
12 years ago
This is a fantastic idea to get include for jQuery UI styles. I noticed that on your sample Plugin Helen that there is no example for the autocomplete widget. Is this going to be supported in the included styles?
#52
@
12 years ago
I have been looking at the source for the autocomplete demos here, which I found really useful: http://jqueryui.com/demos/autocomplete/.
Thanks for the tip, I'm now using core styles for the autocomplete widget. Have a slight issue with the top border though when the results box is wider than the input box in ticket #20584. I've left a comment on that ticket.
#54
follow-up:
↓ 56
@
12 years ago
I was playing around with removing all the duplicated code because with this css code there are then three places where the ui dialog css are defined. I cloned the Github stuff to my own one https://github.com/markoheijnen/wp-admin-jquery-ui.
With that the TineMCE linking looks like http://cl.ly/0r3P3g1M2F1R240y1b2R. Will need to check later if there are issue with removing the stuff from editor-buttons and wp-jquery-ui-dialog.
Also what I noticed is that the ui-widget-overlay has a darker opacity now. Not sure if that was intended.
#55
@
12 years ago
- Milestone changed from Awaiting Review to Future Release
About the UI tabs. I'm not sure if it should change that much. I was playing on GIT with making a wp layer over the UI Tabs.
I do wonder if we should remove the default UI style for the link color so it falls back to the admin theme link color.
#56
in reply to:
↑ 54
@
12 years ago
- Component changed from General to UI
Replying to markoheijnen:
Will need to check later if there are issue with removing the stuff from editor-buttons and wp-jquery-ui-dialog.
I don't think we can remove the styles from the main stylesheet for the dialog - a bundled jQuery UI stylesheet would be registered but not enqueued, so styles that are needed for Core functionality likely need to stay where they are. Additionally, they are made to match the TinyMCE dialog style. I'd personally love to also see some changes to the TinyMCE dialog style, actually, so not saying that that style is necessarily the one to follow.
Also what I noticed is that the ui-widget-overlay has a darker opacity now. Not sure if that was intended.
Probably not. :)
About the UI tabs. I'm not sure if it should change that much.
I'm thinking that they should match the look of the tabs in, say, the category metabox (more compact) by default, and perhaps we can add a class for "large" or some such for the type you find on the themes screens and other places.
I do wonder if we should remove the default UI style for the link color so it falls back to the admin theme link color.
Makes sense. I pushed some small updates to the repo.
#57
follow-up:
↓ 59
@
12 years ago
Uhm, just noticed I apparently changed the milestone of this ticket. Probably we should mark it for 3.5 ;)
I can understand that we can't remove that styling from the editor style. I did it in my repo to test the styling. You still can copy the specific styling to the editor style after all the styling has been done in the plugin.
I do wonder why not enqueue the jQuery UI stylesheet on the editor screen. Having the jQuery UI styling in multiple files is also something that isn't really wanted. You can see it now with the issue with the TinyMCE linking box. It's a decision in do we want to keep the page load low or easy to maintain the CSS code.
#59
in reply to:
↑ 57
;
follow-up:
↓ 62
@
12 years ago
IRC discussion: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-ui&day=2012-06-19&sort=asc#m44828
Replying to markoheijnen:
I do wonder why not enqueue the jQuery UI stylesheet on the editor screen. Having the jQuery UI styling in multiple files is also something that isn't really wanted.
I wonder that myself, but seeing as most of the admin stylesheets were combined not long ago, I don't think we'd split one out again and then enqueue it everywhere. If we were to put it into the main stylesheets, the maintenance would still be difficult and perhaps more so than having just a few elements with more specific selectors defined in other places, as colors are in one place and structure in another. It seems that future maintenance is a (the?) sticking point here, but still think it's worth pursuing.
#60
follow-up:
↓ 61
@
12 years ago
I've forked this on GitHub (https://github.com/stephenh1988/wp-admin-jquery-ui). I have given links the #21759b ('WordPress blue') colour, and for hover #d54e21 ('WordPress orange'). The same for the links. I think this matches (for instance) the category metabox well: I've tried to match the WordPress schema of blue-link, organge-hover.
I've included screenshots in the Git repository. Let me know if its worth a pull request :).
From reading the IRC discussion it seems the main issue is that since admin doesn't use jquery-ui styling a jquery-ui stylesheet would, in effect, be maintained independently and without a core example with which to test bugs/patches against. As helenyhou points out - her plug-in could be the basis for that. But would there be plans for core to start using the jquery-ui styles?
In any case, it seems to me it would be easier (not necessarily easy :) ) to include the jquery-ui stylesheet as part of the admin stylesheet (which would presumably means splitting up colour-specific and structure-specific parts of the jquery ui stylesheet) - rather than having multiple files.
(On a side note, wp_add_inline_style
will prove very useful to developers wanting to add some extra styling for unofficial jQuery-UI plugin's that require it).
#61
in reply to:
↑ 60
@
12 years ago
Replying to stephenh1988:
But would there be plans for core to start using the jquery-ui styles?
Well, core does use some jQuery UI components with styling. Autocomplete was just added in 3.4, for instance. Bloat is really my only concern when it comes to rolling all of jQuery UI styling into the main stylesheets. Maintenance is going to be a little funky no matter what, especially since it's not like we're using a Themeroller theme wholesale to begin with.
As for your fork on GitHub - feel free to make pull requests and we can discuss. Briefly: I think we should steer away from orange icons and avoid adding yet another set, and I'd rather see removal of the specified colors in those instances and allow the cascade to take care of it instead.
#62
in reply to:
↑ 59
@
12 years ago
Replying to helenyhou:
I wonder that myself, but seeing as most of the admin stylesheets were combined not long ago, I don't think we'd split one out again and then enqueue it everywhere. If we were to put it into the main stylesheets, the maintenance would still be difficult and perhaps more so than having just a few elements with more specific selectors defined in other places, as colors are in one place and structure in another. It seems that future maintenance is a (the?) sticking point here, but still think it's worth pursuing.
So if I understand it right "wp-jquery-ui-dialog" has been combined into "editor-buttons"? So that is the reason why it is duplicated now for some kind of backwards compatibility?
The reason why I removed the dialog code from "editor-buttons" in my fork is to test it out how it looks without it. And I do like how it looks now. That said I'm not a designer ;) You can always duplicate it back to "editor-buttons" but thats kind of ugly but I can understand why.
Btw. I also removed the link color of ".ui-state-default a, .ui-state-default a:link, .ui-state-default a:visited". That the same what stephenh1988 does. Didn't do it for hover since WordPress already overrides that.
#69
@
12 years ago
- Component changed from UI to External Libraries
- Keywords ui-focus added; ui-feedback removed
#70
@
12 years ago
- Cc lol@… added
I've got a vested interest in this along with others, if there's anything we can do to get this to land in 3.7 just let us know.
#71
@
12 years ago
Probably makes the most sense to work on this within MP6 right now. Needs styles including ones that are already used in core, a testing page (think something that we could use as a style guide), best way to handle registration/enqueuing, and a plan for maintenance (including whether or not the styles should be scoped, as some of the styles we already use are).
#77
@
11 years ago
- Cc msykes@… added
it would certainly save a ton of headaches for plugin (and theme) devs to have some sort of standardized jQuery UI CSS inclusion framework for both admin AND public side of things (maybe the public side should be in a new ticket).
That way, whatever version of WP is being used you know it has a matching set of library/CSS files. 3.6 is a good example of how problems would be avoided, with the updates to the ui libraries I had to update the lightness stylesheet used in my plugins. Then there's the common problem of clashes with other plugins/themes enqueueing their styles too.
From a plugin developer's point of view:
if you're using the jQuery UI bundled with WP, then it doesn't really matter who loads a jQuery UI CSS theme as long as one is loaded (preferably only once!)
On the admin area, that'd be fairly 'simple', you just make sure the theme admin uses is enqueued and let the styling take over, even better because all ui elements are consistent with the dashboard style.
On the front-end, it'd probably be desirable to provide some sort of way to choose your theme. Maybe some sort of way to expose a 'theme choice' of pre-rolled themes for the front-end if any plugin chooses to make use of it.
That would be ideal :)
This ticket was mentioned in IRC in #wordpress-ui by helen. View the logs.
11 years ago
#84
@
11 years ago
X-Team recently released jQuery UI Datepicker styles for all of the default color schemes today. What about including them in core?
#85
follow-up:
↓ 86
@
10 years ago
Over the past few years there have been some fairly solid patches and suggestions.
What do we need to move this forward. Years later it is still a pain in the ass for plugins.
#86
in reply to:
↑ 85
@
10 years ago
- Keywords needs-patch added; has-patch removed
Replying to jaredatch:
Over the past few years there have been some fairly solid patches and suggestions.
What do we need to move this forward.
- Needs to match the current admin and be complete across all enqueuable jQuery UI components - what's in my old GitHub repo is now outdated, and just the datepicker isn't enough. I don't see any patches or other stylesheets out there that meet this requirement, which is the most important one. I've seen one or two that come close visually, but are not quite right.
- Needs to at least take into account people who are currently enqueueing their own styles or the old
wp-jquery-ui-dialog
stylesheet - likely we need to use a scoping class or similar, but that does introduce complexity for developers to implement. - Needs to take color schemes and generation into account. It's possible it might be fine to just put jQuery UI rules into the color scheme files and have them load all the time, but be aware of cascade problems.
- A comprehensive test page so that this can be tested well, now and in the future. There is one that comes with jQuery UI, but it's not comprehensive.
- At least some acknowledgment of what it means to maintain this moving forward.
Also note that Iris (the color picker) and revisions both use jQuery UI slider, and several other places in the admin use other components, like sortable and autocomplete.
Patches can iterate - a first patch doesn't need to address all of this at once by any means. But I don't want anybody to feel like they didn't see something coming. There's a lot going on, and backcompat is an important consideration, even in CSS. I don't mind causing some visual breakage, but only if we do our due diligence.
I have a feeling avryl might be into running with this - pinged her for good measure :)
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
#89
@
9 years ago
There is a stylesheet for the jQuery UI datepicker that matches the style and colors of the WP Admin: https://github.com/xwp/wp-jquery-ui-datepicker-skins/tree/master/css
You need to include the basic css from jQuery UI to make it work but it looks pretty nice:
This ticket was mentioned in Slack in #core-fields by sc0ttkclark. View the logs.
9 years ago
#92
@
5 years ago
It's an old topic, but I will add my two cents here.
Using wp_enqueue_script anyone can load i.e. ui-widget, ui-accordion, ui-autocomplete, ui-button, ui-datepicker and many other "jquery-ui" stuff. However, their .css equivalents listed here are not available to be loaded natively using wp_enqueue_style.
That's what I think, is a mistake, because if you suppose that people "like" any jquery-ui function to use, then you should anticipate, that they probably also like how that function works (i mean the styling too). So, most( i think about 80%) of us (plugin or theme developers) probably agree to use their styling how we see those functions at jQuery-UI website. So, WP should have the default styling available to be loaded natively, without the need that we incorporated manual .css files in our plugins and themes to just use ui-tooltip
, ui-tabs
or many nice ui
stuff that is commonly used by most of plugin or theme developers.
Otherwise I don't this it's perfect point that UI .js
files are included in core, but ui .css
styling is not included (and it's just few KB's in size), because plugin devs are still required to add the files manually in their plugins (if they want to use i.e.ui-tooltip.css
, ui-tabs.css
or whatever). Most of us, I think, would have accepted to use the default ui-styling, so, would have been nice, if they were available in CORE to be loaded natively with wp_enqueue_style
.
#93
@
2 years ago
- Keywords close added
I'm not convinced that this is something that would benefit the majority of users in 2022, or that its in demand enough (8+ years without any contributors feeling strongly enough to work on it).
I think this ship has sailed, and most plugins or themes needing jQuery UI are likely just loading their own. Marking with a close
suggestion, but leaving open for a bit to allow for anyone that strongly disagrees to weigh in.
#94
@
2 years ago
Of course, leaving the issue open for 11 years, the ship would have sailed and would have eventually sunk already. it was needed years ago, when it was time for it. (however, if WP still retains the same jQuery bundles, then it will be still needed as much as people use jQuery)
This ticket was mentioned in Slack in #core by jorbin. View the logs.
7 months ago
#96
@
7 months ago
- Milestone Future Release deleted
- Resolution set to wontfix
- Status changed from assigned to closed
Based on Helen's Comment, @desrosj more recent suggestion, and the upcoming changes to the WordPress Admin I am closing this ticket. While this would have been a great improvement years ago, WordPress has evolved.
I would say that, from all the themes in the gallery, the "Smoothness" theme works best with the WP admin.