Response title
This is preview!
Move this topic
Button planning
in Developing jQuery UI
•
2 years ago
Please take a look at these two:
http://jquery-ui.googlecode.com/svn/branches/dev/tests/visual/button/default.html
http://jquery-ui.googlecode.com/svn/branches/dev/ui/jquery.ui.button.js
The approach so far was to keep each task seperate: push button,
toggle button (based on checkbox), toggle-set (based on radio). So far
toggleButton is applied to a checkbox, while radioButton is applied to
some element, and its child-radio-inputs will then be converted to a
button set.
Its certainly possible to merge all these into a single button widget,
but that would probably get quite messy in the long run.
Jörn
Replies(22)
Re: Button planning
2 years ago
Looking really good! Can you make the bold, italic, underline toggles
a grouped set -- buttons visually connected like a radio set? Is that
supported?
Todd Parker
todd@filamentgroup.com
a grouped set -- buttons visually connected like a radio set? Is that
supported?
Todd Parker
todd@filamentgroup.com
Leave a comment on guest's reply
Re: Button planning
2 years ago
Not yet, will add that. Will need to figure out a good way to select groups...
Jörn
Leave a comment on joern.zaefferer's reply
Leave a comment on rdworth's reply
Re: Button planning
2 years ago
Hello, there is a missing "self." in http://jquery-ui.googlecode.com/svn/trunk/ui/jquery.ui.sortable.js
@@ -1009,7 +1009,7 @@
helper: self.helper,
placeholder: self.placeholder || $([]),
position: self.position,
- originalPosition: originalPosition,
+ originalPosition: self.originalPosition,
offset: self.positionAbs,
item: self.currentItem,
sender: inst ? inst.element : null
Thanks for the excellent work, have a great day!
-will
Leave a comment on google3's reply
Re: Button planning
2 years ago
Mouseover a button (gets hover state)<div>mousedown (gets active state)</div><div>mouseout while mousedown (loses hover and active state)</div><div>mouseover while mousedown (gets hover state)<div>
</div><div>I think the buttons should regain the active state.</div>
</div>
</div><div>I think the buttons should regain the active state.</div>
</div>
Leave a comment on scott.gonzalez's reply
Re: Button planning
2 years ago
<html><body bgcolor="#FFFFFF"><div>We just got this comment on how to improve icons in buttons from our original button article with CDs framework...</div><div>
</div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><span>You have just received a comment for the following weblog:</span>
<span>Lab</span>
<span></span>
<span>The title of the entry is:</span>
<span>Styling Buttons and Toolbars with the jQuery UI CSS Framework</span>
<span></span>
<span>Located at: </span>
<span><a href="http://www.filamentgroup.com/lab/styling_buttons_and_toolbars_with_the_jquery_ui_css_framework/" x-apple-data-detectors="true"><a href="http://www.filamentgroup.com/lab/styling_buttons_and_toolbars_with_the_jquery_ui_css_framework/">http://www.filamentgroup.com/lab/styling_buttons_and_toolbars_with_the_jquery_ui_css_framework/</a></a></span>
<span></span>
<span>Posted by: Joelson</span>
<span>Email: <a href="mailto:lopesjoelson@gmail.com" x-apple-data-detectors="true"><a href="mailto:lopesjoelson@gmail.com">lopesjoelson@gmail.com</a></a></span>
<span>URL: <a href="http://www.rentcars.com.br/" x-apple-data-detectors="true"><a href="http://www.rentcars.com.br">http://www.rentcars.com.br</a></a></span>
<span>Location: </span>
<span></span>
<span>For icons in the button (Mozilla FireFox, Chrome and Internet Explorer), try this:</span>
<span></span>
<span>in css, change:</span>
<span>.fg-button .ui-icon { position: absolute; top: 50%; margin-top: -8px; left: 50%; margin-left: -8px; }</span>
<span></span>
<span>to:</span>
<span>.fg-button .ui-icon { }</span>
<span></span>
<span>in your button, write:</span>
<span><button class="fg-button ui-state-default ui-corner-all"><span class="ui-icon ui-icon-alert"></span>Example</button></span>
<span></span>
<span>type='submit' in button will be necessary for some forms to IE...</span></span>
Todd Parker<div><a href="mailto:todd@filamentgroup.com">todd@filamentgroup.com</a></div></div><div>
On Sep 26, 2009, at 12:49 PM, "Richard D. Worth" <<a href="mailto:rdworth@gmail.com">rdworth@gmail.com</a>> wrote:
</div><div></div><blockquote type="cite"><div><div>
</div><div><span class="Apple-style-span" style="font-size: 15px; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "><span>You have just received a comment for the following weblog:</span>
<span>Lab</span>
<span></span>
<span>The title of the entry is:</span>
<span>Styling Buttons and Toolbars with the jQuery UI CSS Framework</span>
<span></span>
<span>Located at: </span>
<span><a href="http://www.filamentgroup.com/lab/styling_buttons_and_toolbars_with_the_jquery_ui_css_framework/" x-apple-data-detectors="true"><a href="http://www.filamentgroup.com/lab/styling_buttons_and_toolbars_with_the_jquery_ui_css_framework/">http://www.filamentgroup.com/lab/styling_buttons_and_toolbars_with_the_jquery_ui_css_framework/</a></a></span>
<span></span>
<span>Posted by: Joelson</span>
<span>Email: <a href="mailto:lopesjoelson@gmail.com" x-apple-data-detectors="true"><a href="mailto:lopesjoelson@gmail.com">lopesjoelson@gmail.com</a></a></span>
<span>URL: <a href="http://www.rentcars.com.br/" x-apple-data-detectors="true"><a href="http://www.rentcars.com.br">http://www.rentcars.com.br</a></a></span>
<span>Location: </span>
<span></span>
<span>For icons in the button (Mozilla FireFox, Chrome and Internet Explorer), try this:</span>
<span></span>
<span>in css, change:</span>
<span>.fg-button .ui-icon { position: absolute; top: 50%; margin-top: -8px; left: 50%; margin-left: -8px; }</span>
<span></span>
<span>to:</span>
<span>.fg-button .ui-icon { }</span>
<span></span>
<span>in your button, write:</span>
<span><button class="fg-button ui-state-default ui-corner-all"><span class="ui-icon ui-icon-alert"></span>Example</button></span>
<span></span>
<span>type='submit' in button will be necessary for some forms to IE...</span></span>
Todd Parker<div><a href="mailto:todd@filamentgroup.com">todd@filamentgroup.com</a></div></div><div>
On Sep 26, 2009, at 12:49 PM, "Richard D. Worth" <<a href="mailto:rdworth@gmail.com">rdworth@gmail.com</a>> wrote:
</div><div></div><blockquote type="cite"><div><div>
Leave a comment on guest's reply
Leave a comment on cloudream's reply
Re: Button planning
2 years ago
Secondary buttons never look disabled. This problem comes from our CSS framework because .ui-priority-secondary has an opacity of 0.7 and is defined after .ui-state-disabled. Just changing the order we define the rules in should fix the problem, but I'm not sure if there will be other cases where this problem might show up.
Leave a comment on scott.gonzalez's reply
Re: Button planning
2 years ago
Sounds like we should flip those rules because disabled can be stacked
with other classes. Disabled should be the last widget/state rule in
fact. Scott J - do you forsee any issues with this?
Todd Parker
todd@filamentgroup.com
with other classes. Disabled should be the last widget/state rule in
fact. Scott J - do you forsee any issues with this?
Todd Parker
todd@filamentgroup.com
Leave a comment on guest's reply
Re: Button planning
2 years ago
Hi
Perhaps i'm misendurstanding but i'm a little surprised to see a
totally new button plugin that seem to be rewrite from scratch with
all the work already done in the wiki about that particular plugin.
My opinion on this is that it would be preferable to finalise the
actual plugin instead of rewrite all the stuff from scratch. Many
points (notably the look&feel) have been discussed/solved in the past
so i'm not sure to understand the reason to take over with something
totally new...?
Aside that my opinion is that it'll be more friendly to have a single
plugin for all button types instead of one plugin for each type.
All of this is only my humble opinions,
nice day to all
Leave a comment on guest's reply
Re: Button planning
2 years ago
The core team decided at the latest jQuery meeting to try and fast
track some of the more common plugins (button, menu, etc.) but with
the overall approach of designing the most streamlined and minimal
implementation that others could extend, re-use and re-mix. Looking at
the button page, there were more than 10 script options and we wanted
to dramatically simplify this to make testing and maintenance easier.
We also felt that we could embrace progressive enhancement to a
greater extent to allow the actual HTML markup to drive what were
originally options.
For example, instead of needing an option for a toggle-style button,
we should really use a checkbox in the foundation markup and then have
the script enhance it into a button that toggles it's state. If the
checkbox's checked attribute is "checked" in the markup, it can be set
to active when the plugin initializes. Instead of a disabled plugin
option, we check for the disabled attribute on a button or checkbox
and disable the button to match the markup.
One big advantage of this approach is that the html markup is not only
highly descriptive (which simplifies scripting options), it is also
100% usable if JS isn't present. For example, a set of divs styles to
look like a single-select toggle set of buttons (like a button toggle
for viewing by list or grid for example) which is un-usable without
scripts, we can have 2 radiobuttons that more closely represent this
interaction in HTML, then transform it into the button toggles when
button() is called on it.
We appreciate the time you've spent on this to date and do want you to
help us, especially on working out the styling trickery. We've hope
you agree that it's a better direction, even if it means that some of
your work won't be used. Whether this is pulled into a single plugin
or multiple is still TBD (I think).
_t
todd.parker .: . filament group inc.
102 south street #3 boston, ma 02111
email + todd@filamentgroup.com
phone + 617.482.7120
fax + 617.687.0212
web + filamentgroup.com
Leave a comment on guest's reply
Re: Button planning
2 years ago
Hi Todd,
Thank's for your response!
Concerning decision made i agree with most of what you explain in your
previous mail.
Perhaps it should be nice to leave a note on the wiki to let users
know that the plugin is changing direction.
I'm won't discussed the choice made, just was surprised as i didn't
know about them and seeing a totally new plugin coming from apparently
nowhere was quite confusing.
Now concerning the implementation IMHO I think that ui.button should
be a sort of widget factory for all sort of buttons.
so calling $('#selector').button() should render propely toggleButton
or buttonSet following the markup meaning.
This would make the plugin more user friendly with less plugin name to know.
This can in fact call different underlying more specific plugins like
toggleButtons etc... which hold the details of the specific
implementation.
No problem to help at all and no problem too if previous work isn't
reused if it doesn't reflect what we want to get in the end.
Thank's again for your explanation that i was missing.
regards,
jonathan
Leave a comment on guest's reply
Re: Button planning
2 years ago
Jörn, the buttons look great, nice work. :)
I'll take a look at the CSS later today. It'd be ideal if we could use something like in-line block for positioning the icon spans so that we don't have to use floats, which impact how the rest of the layout is set up. We also need to make some adjustments so that icons vertically align to the button's center, not to the text baseline, and buttons with and without icons are the same height.
I'll post an update later today/tomorrow.
- Maggie
I'll take a look at the CSS later today. It'd be ideal if we could use something like in-line block for positioning the icon spans so that we don't have to use floats, which impact how the rest of the layout is set up. We also need to make some adjustments so that icons vertically align to the button's center, not to the text baseline, and buttons with and without icons are the same height.
I'll post an update later today/tomorrow.
- Maggie
Leave a comment on guest's reply
Re: Button planning
2 years ago
I can throw together some static markup examples, based on the
generated markup. That should make it easier to adjust the CSS stuff.
Jörn
Leave a comment on joern.zaefferer's reply
Leave a comment on guest's reply
Re: Button planning
2 years ago
The only reliable solution I found for this was to bind a mouseup
event to the document (see the latest commit). Ideas to improve that
are very welcome.
Jörn
2009/9/27 Scott González <scott.gonzalez@gmail.com>:
Leave a comment on joern.zaefferer's reply
Re: Button planning
2 years ago
Commited in revision 3312. Feel free to remove a few of those
duplicates - I wasn't sure which variations are actually significant.
Jörn
Leave a comment on joern.zaefferer's reply
Re: Button planning
2 years ago
.ui-icon has display:block, so without an display:inline-block, I
don't see how this is supposed to work.
For now I'll assume Maggie will take care of that when fixing the
current styles. Though if we use inline-block, we either need to add a
workaround for FF2, or drop support for it.
Jörn
Leave a comment on joern.zaefferer's reply
Re: Button planning
2 years ago
Thats a valid concern and definitely something we need to work on.
I've started with seperate methods in order to work out the actual
requirements for each case:
- a selection of button-like (button, input-type-submit, a) elements
to transform into a push button
- a selection of checkboxes-with-labels to transform into toggle buttons
- a selection of radiobuttons-with-labels to transform into a radio-button-set
- a selection of button-like or checkboxes-with-labels to transform
into a button-set
For the button set a common parent element is required (for CSS
inheritance), unless we add the necessary ui-button-set class to each
element in the set.
For the radio set each button has to be aware of the others, to
deactive the others when activating one button. This requires that the
widget is applied to a common parent, otherwise the widget-API would
be applied to each individual radio-button (unacceptable overhead
involving cross-widget "communication").
We want to allow very flexible markup (not even a form should be
required), so always requiring each radio-button to be a direct child
of the widget-element wouldn't work.
One possible approach, using only a single button-widget, could look like this:
- check if self.element is a button-like element, if so, apply default button
- otherwise, check if self.element has any :radio children, if so,
apply the current radioButton code and make those children a set
- otherwise, check if self.element has any :checkbox children, if so,
apply the current toggleButton code and make those children a set
- otherwise, check if self.element has any button-like children, if
so, make each a button and make those children a set
While this could then be applied to individual elements directly or
various parent elements, it couldn't handle a form-element that
contains buttons, radios and checkboxes (only one of the conditions
would match).
Ideas?
Jörn
Leave a comment on joern.zaefferer's reply
Re: Button planning
2 years ago
On Mon, Sep 28, 2009 at 12:48 PM, Jörn Zaefferer <span dir="ltr"><<a href="mailto:joern.zaefferer@googlemail.com">joern.zaefferer@googlemail.com</a>></span> wrote:
Leave a comment on scott.gonzalez's reply
Re: Button planning
2 years ago
> For the radio set each button has to be aware of the others, to
> deactive the others when activating one button. This requires that the
> widget is applied to a common parent, otherwise the widget-API would
> be applied to each individual radio-button (unacceptable overhead
> involving cross-widget "communication").
>
> We want to allow very flexible markup (not even a form should be
> required), so always requiring each radio-button to be a direct child
> of the widget-element wouldn't work.
What about to make a singleton (multiton in fact) widget that handle
all radio elements with same name attribute when initialised on any of
them.
(not sure i'm clear)
> One possible approach, using only a single button-widget, could look like this:
>
> - check if self.element is a button-like element, if so, apply default button
This one should be the default if none of the following conditions are met.
> - otherwise, check if self.element has any :radio children, if so,
> apply the current radioButton code and make those children a set
Or like said above, check if self.element is a radio and then lookup
for other radio with same name attribute and make them a set
> - otherwise, check if self.element has any :checkbox children, if so,
> apply the current toggleButton code and make those children a set
or if self.element is a checkbox make it a single toggle button
> - otherwise, check if self.element has any button-like children, if
> so, make each a button and make those children a set
Perhaps we can keep an extra widget for button-set or simply make it
some css rules to render elements differently by overriding children
buttons style.
This will allow to put a container element with class ui-buttonset in
the orignial markup and so to allow a good rendering even when no
javascript is used.
> While this could then be applied to individual elements directly or
> various parent elements, it couldn't handle a form-element that
> contains buttons, radios and checkboxes (only one of the conditions
> would match).
>
> Ideas?
Leave a comment on guest's reply
Re: Button planning
1 year ago
> For example, instead of needing an option for a toggle-style button,
> we should really use a checkbox in the foundation markup and then have
> the script enhance it into a button that toggles it's state
I have issues with the button widget automatically deciding to be a toggle wether it is a checkbox or a button. Not in every situation is the best markup a checkbox.
Say for example you would like to compound a button with a panel widget to create some kind of drop down panel: currently you have to rewrite a custom button widget to make it togglable so you can open your panel with one click and click again if you want to hide it or use a checkbox in the markup. But imho, it just doesn't make sense to use a checkbox in this particular situation.
I like being able to build complex custom widgets with simple building block widgets but I don't feel the actual button widget fit this usecase.
> we should really use a checkbox in the foundation markup and then have
> the script enhance it into a button that toggles it's state
I have issues with the button widget automatically deciding to be a toggle wether it is a checkbox or a button. Not in every situation is the best markup a checkbox.
Say for example you would like to compound a button with a panel widget to create some kind of drop down panel: currently you have to rewrite a custom button widget to make it togglable so you can open your panel with one click and click again if you want to hide it or use a checkbox in the markup. But imho, it just doesn't make sense to use a checkbox in this particular situation.
I like being able to build complex custom widgets with simple building block widgets but I don't feel the actual button widget fit this usecase.
Leave a comment on nicolas.blackburn.ca's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to joern.zaefferer's discussion
{"z2656090":[14737000000545899,14737000000545905,14737000000545929],"z-1":[14737000000545891,14737000000545901,14737000000545907,14737000000545909,14737000000545911,14737000000545913,14737000000545915,14737000000545919,14737000000545931],"z2600866":[14737000000545889,14737000000545893,14737000000545917,14737000000545921,14737000000545923,14737000000545925,14737000000545927],"z5988782":[14737000002220258],"z63268":[14737000000545903],"z2655461":[14737000000545895],"z2951946":[14737000000545897]}
Statistics
- 22 Replies
- 2654 Views
- 0 Followers
