<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi all,<div>I've brought the new selectmenu plugin into a fairly feature-complete and stable state. </div><div> </div><div>What is our process for deciding when a plugin should move from labs to the dev branch? Do we have one yet? :)</div><div> </div><div>I've updated the wiki with the latest specs, any features that still need to be developed (stackfix, collision detection), and updated the list of issues currently being discussed. <a href="http://wiki.jqueryui.com/Selectmenu">http://wiki.jqueryui.com/Selectmenu</a></div><div> </div><div>You can also try out the demos here: <span class="Apple-style-span" style="color: rgb(9, 9, 13); font-family: 'Segoe UI'; font-size: 11px; line-height: 13px; "><a href="http://jquery-ui.googlecode.com/svn/branches/labs/selectmenu/index.html" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 0px; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; text-decoration: underline !important; color: rgb(27, 124, 210); ">http://jquery-ui.googlecode.com/svn/branches/labs/selectmenu/index.html</a></span></div><div><font class="Apple-style-span" color="#09090D" face="'Segoe UI'" size="3"><span class="Apple-style-span" style="font-size: 11px; line-height: 13px;"> </span></font></div><div>Feedback is much appreciated! Thanks.</div>
Hi all, Over at Filament, we've worked out a new UI plugin and I just committed it into labs. It's called selectmenu, you can check it out here: http://jquery-ui.googlecode.com/svn/branches/labs/selectmenu/index.html The component is designed to replace the functionality of a native form select element, allowing for enhanced skinning and behavior. You call it on a select element, like this: $('select').selectmenu(); The original select element will remain in the page (whether visible or hidden), and the new selectmenu component will control it. This of course allows for easy form submission as if this plugin was never there. We've got a great deal of functionality already in place, such as: - keyboard accessibility (arrowing, selecting when both open and closed) - ARIA support - (tested on NVDA - seems to work well) - different menu types (popup vs. dropdown) - widget factory driven (incomplete, but it's a start) - full theming support - form label association (click label to focus) - formatting of options: ability to split option text into better formatted elements in the UI component. This feature could really use some feedback, especially on the technical implementation side. We've filled out the wiki page with more info and ideas: https://jqueryui.pbworks.com/Selectmenu We'd appreciate any feedback on the functionality and especially the code, which we realize can be improved to be in line with our coding practices. Also, we'll be posting a lab article on our site about this plugin in the near future. Thanks for checking it out. Hopefully this plugin can be reworked and shuffled into an upcoming release! -Scott
Before the new ThemeRoller launched, we had come up with some designs for making the gallery more community-driven with user-submitted themes, voting, rating, etc. I've updated the wiki page that describes how this could be implemented on the front end: http://wiki.jqueryui.com/ThemeRoller-gallery We'll need some php/sql help to make it happen of course. Is there any interest in making this happen in the near future? If there's a lot of interest, perhaps we could consider working on this in the sprint?
It seems the start event trigger for sortable has been moved to much later in the _mouseStart method in UI 1.7. As a result, when I cache my sortable list within the start callback, I get the sortable helper included in the set. This didn't used to happen in UI1.5, and since I need to cache my list's state when sorting begins, it breaks my application. I can work around it by using a regular mousedown event instead of the sortable start callback, so it's not a big deal. But I'm just wondering: is there a reason the trigger was moved to later in the _mouseStart method? Perhaps it was done to allow inclusion of more properties in the callback's ui hash? Thanks -Scott
I ported this over to docs this afternoon. I'm not sure how it'll be pulled into the new docs but here's the link: http://docs.jquery.com/UI/Getting_Started I assume images will be stripped out too but it should be alright without them...
When someone has time, could you explain the logic behind how the slider decides which orientation to use? I've had to fix our select-to-slider wrapper plugin to always set 'horizontal' as a default because it would flip to vertical even when there was plenty of room for a horizontal slider (~400px width). At a glance, it seems maybe the logic should be... if the number of slider values on the scale is greater than the pixel width, set to vertical. otherwise, set to horizontal. Otherwise, it seems vertical sliders will be occurring in many situations where horizontal is expected, since horizontal seems to me to be the primary case in most interfaces. Thoughts?
Is anyone able to fill out the last 4 method types (addClass,removeClass,toggleClass,switchClass), I got the others in there: http://jquery-ui.googlecode.com/svn/trunk/demos/effect_methods/ Even if you can get it working between classes, I might have time to get in there and trick out the styles. Thanks
Paul did some great work on the download builder and TR downloader over the weekend and now the zips generated by them are almost identical. The next step is to tie them together into the download builder. The logic for extracting images and writing the ui.theme.css file can easily be brought into the download builder's php. Then, the download builder simply needs one more form input for a theme URL and all ThemeRoller downloads would get pushed over to the download builder for configuration. How the download builder page would change: - We would add a "Theme" field to the right column. It would be a select menu with our standard theme gallery options (defaulting to "No Theme"). The select will be rebuilt with JS to look sorta like our theme switcher widget. When a themeable widget is selected and no theme is currently selected, the theme menu will be set to the first choice (Smoothness). - The logic for writing the ui.theme.css file and its images will need to be brought over from the ThemeRoller download.php. This should be pretty easy to integrate. - Ideally, if you click the link to go to ThemeRoller and design a custom theme, the builder could cookie your settings for when you return (except for chosen theme) How ThemeRoller will change: - When you click the download button, you'll be directed to the Download Builder. All fields except for effects will be selected and the theme menu will have an selected first option called "Custom Theme" which will contain a value of the passed theme url from ThemeRoller. - The small link to download a jquery ui 1.5 theme will be deleted! This will allow for a number of nice changes: - Our zip downloads will be consistent which will make them much less confusing for users. We'll only need one "how to" guide. - Our backend will be much simpler. - Users can choose to download just a theme, if they'd like, or include any widgets they want as well. I mocked up the scenarios and posted them to the wiki: Download builder with javascript disabled: https://jqueryui.pbwiki.com/f/download_v2_themeint_nojs.png Download builder default: https://jqueryui.pbwiki.com/f/download_v2_themeint_a.png Download builder theme menu open: https://jqueryui.pbwiki.com/f/download_v2_themeint_b.png Download builder custom theme populated from TR download: https://jqueryui.pbwiki.com/f/download_v2_themeint_c.png It would be great to get this underway as soon as possible. Thoughts?
We have a current limitation where ui.theme.css needs to precede our plugin CSS files. This is because our plugin CSS files contain certain styles that override style properties set in the framework classes in ui.theme.css. Since we've written most of our plugin CSS selectors as concisely as possible, we end up with a 1-to-1 specificity conflict between the styles and whatever comes last in the CSS ends up being applied. This could be done better. By prefacing each of our selectors with .ui-pluginname we can fix this conflict without introducing any new bugs. This will also keep our widget styles even more tightly scoped to a particular plugin, which is nice even despite our already-meaningful class names. If everyone agrees (and so far I think Richard agrees), I can make this change to all of our plugin CSS files and moving forward this should become our standard. This will allow for a multitude of advantages, including being able to pack all of our static CSS into one file and then attaching a separate theme stylesheet for the skin. It will also mean applying a new theme is as easy as appending it to the head, which greatly reduces the complexity of ThemeRoller, and more importantly the ThemeRoller switcher and developer bookmarklet. This will also be more consistent with how people think of themes, which are typically a layer above the structure of a widget, rather than a core dependency. So to repeat, every selector in a widget CSS file will be specific to the widget's container class. .ui-accordion-header { becomes .ui-accordion .ui-accordion-header { .ui-dialog-titlebar { becomes .ui-dialog .ui-dialog-titlebar { Despite the filesize addition caused by this change, we think it's a better approach. Agreed?
I've changed the image naming conventions for our CSS framework images so that they're easier to read and understand. Textures will now look like this: ui-bg_diagonals-small_40_db4865_40x40.png ( pattern: ui-bg_{texturename}_{textureopacity}_{texturecolor}_ {texturedims}.{ext} ) and icons will look like this: ui-icons_88a206_256x240.png ( pattern: ui-icons_{iconcolor}_{iconimagedims}.{ext} ) This makes sorting in directories much better as well. The change should be effective in ThemeRoller later today.
I was wondering... can google host the UI CSS framework files as they do for javascript library scripts? It would be great if we could have ui.core.css, and all the ui.plugin.css files hosted in a cacheable location just like our JS. Even the default ui.theme.css would be nice to have on there, but the plugin files would be especially nice. Perhaps they'd even host a few gallery themes... w/ images?? Just a thought. -Scott
I've updated the documentation pages for the jQuery UI CSS Framework, ThemeRoller about/how-to, and general theming best practices. http://docs.jquery.com/UI/Theming http://docs.jquery.com/UI/Theming/API http://docs.jquery.com/UI/Theming/Themeroller The UI/Theming page still needs some work, and it would be nice if everyone could give these a read and make changes or recommendations. I'm not sure if the order of priorities on the Theming page is accurate to our recommended best practices (I only wrote the part at the bottom with the theme switcher). Thanks! Sott
I noticed that on the ui demos, any custom CSS that comes with the demo page is getting stripped out in Safari. It doesn't seem to be happening in FF though. View the last two slider demos in safari to see what I mean
I wanted to bump this issue back up again in hopes someone on the dev list might have some ideas. ThemeRoller currently spits out png24 images for its icons and textures. The icons use alpha transparency and need to be converted to png8 so they look "less bad" in ie6. We're currently using phpThumb on top of GD to handle our image conversion, but phpThumb's "reduce color depth" filter doesn't retain image quality well so we can't use that for converting to png8. Does anyone know of any php scripts that could do this conversion for us? We have access to both GD and imagemagick. There's a trac ticket here: http://ui.jquery.com/bugs/ticket/3689 Thanks Scott
Seems most of the widgets have gotten most or all of the markup changes needed for the new framework, but tabs still looks untouched. Are we planning to have that widget ready for the release?