Closed billsaysthis closed 12 years ago
Hi,
I think there are a few ways this could go in:
In addition it probably would be nice to have above connected with the picker so that it alters alpha of the picker based on the given value and shows possible background (need some kind of checkers there) through.
Do you think any of these would work for your case? How would the checkbox work exactly?
I'm not clear how a slider would work with transparent; this would need to be in addition to the current controls, not in place of them since some users might want to enter a real color for the same field. What I thought about the checkbox is it would override the other (slider) based value if checked. Additionally/alternatively, the hex input field could allow the word transparent to be typed in.
I found this example of what a vertical slider would look like.
Essentially the checkbox would just replace the current vertical slider with alpha one, right?
I could make it possible to enter the alpha value as a part of the hex (ie. ff00ffdd where dd is alpha).
I think I see better now what you meant--the vertical slide would be percentage transparent? I was actually thinking the checkbox would product color: transparent rather than color:
I think I see better now what you meant--the vertical slide would be percentage transparent?
Yup. It would give the alpha as a percentage.
I was actually thinking the checkbox would product color: transparent rather than color: .
How do you define transparent in this case? 50% alpha?
I think this is very specific kind of functionality and likely doesn't belong to the core. I can, however, provide a sample implementation for this.
I'm not a 'color person' ;) I just know the business requirements I was given, so even the term alpha is something I don't really understand, except by implication of your linked example in this context.
Of course the design of your widget is your choice but to me this seems a fairly common use case, though having it configurable and false by default would also suit me. My problem with a sample implementation is it can get left behind if the plugin evolves whereas a feature you would more likely keep intact.
I'm not a 'color person' ;) I just know the business requirements I was given, so even the term alpha is something I don't really understand, except by implication of your linked example in this context.
Alright. Basically "alpha" or "opacity" refers to the opaqueness or rather blending factor of the color. This blending factor is used to mix given object (ie. some image) on top of some other. Usually the mix operation is performed using a linear interpolation (lerp = c1 * a + c2 * (1 - a)). As you can see from the formula "a" or "alpha" defines the contribution of both elements. There are many other possible operations of course but that's the basic idea of it.
Of course the design of your widget is your choice but to me this seems a fairly common use case, though having it configurable and false by default would also suit me. My problem with a sample implementation is it can get left behind if the plugin evolves whereas a feature you would more likely keep intact.
I guess what I'll do is to prepare the widget for alpha by writing a simple slider extra (something you can "plug in"). This is half of the work. In addition I'll think through the plugin API and see if I can make it so that functionality can be injected easily to the widget from the outside.
I think this would help with the maintenance issue you mentioned. Basically I would just need to make sure the plugin API stays somewhat stable. This way you could update the widget without breaking the code all the time.
Just to give you some idea of how it would work codewise, I guess it would look like something like this (pseudocodish):
// our custom "extra"
function alphaToggle(p, joe) {
var e = toggle();
e.ontoggle = function(state) {
joe.setAlpha(state? 0.5: 1);
}
}
// registration
colorjoe.registerExtra('alphaToggle', alphaToggle);
// let's use it
colorjoe.rgba('rgbaPicker', 'red', ['currentColor', 'alphaToggle']);
// now when we retrieve color, we get it with alpha set either to 1 (opaque)
// or 0.5 (halfway transparent)
The current API would have to change a little bit but not too much. Would this work for your case?
Not this would work exactly, why the 0.5 instead of 0? I don't think I was precise enough in my original statement, though, because this would be for the background color of an element, not the text color.
Not this would work exactly, why the 0.5 instead of 0? I don't think I was precise enough in my original statement, though, because this would be for the background color of an element, not the text color.
Okay. Whatever works for you. :)
I think I've got a clear idea of what to do next. Thanks for the convo. I'll close this ticket once I've added the hooks needed to the lib. :)
thanks!
Hi,
I added the needed bits today. Before invoking the picker, you'll need to register an "extra" that does the logic you are after. I think something like this should work (parts are pseudocode):
colorjoe.registerExtra('alphaToggle', function(p, joe) {
// instantiate your toggle now using your framework
var e = toggle();
e.onClick = function(e) {
joe.setAlpha(e.value? 1: 0);
}
});
colorjoe.rgb('someId', 'red', [
'currentColor',
'alphaToggle'
]);
I hope that helps!
Probably best as a checkbox but I don't want to over-specify. Use case is as follows: When color picker is part of a 'builder' screen (e.g., customize this theme) and all elements have default colors, some elements may need to be transparent in order to not interfere with other elements.