I am trying to use clamp for a font-size in my Less file. I set it to be font-size: clamp(3.429rem, -1.870rem + 6.493vw, 9.143rem);.
When I build my styles however, I end up with CSS looking like font-size: clamp(3.429rem, 4.623rem, 9.143rem);. Less is evaluating the addition instead of passing over the whole clamp expression into CSS. I find this odd since there is no view width at build time.
How do I get Less to simply pass the clamp expression into the CSS file without evaluating?
How is it possible to render a rectangle with the background color of selections in GTK+3. I cannot find any API to do that:
static gboolean draw_callback (GtkWidget *widget, cairo_t *cr, gpointer data)
{
auto state=reinterpret_cast<State*>(data);
auto width = gtk_widget_get_allocated_width (widget);
auto height = gtk_widget_get_allocated_height (widget);
auto context = gtk_widget_get_style_context (widget);
gtk_render_background(context,cr,0,0,width,height);
cairo_rectangle(cr,0,height*(1.0 - state->max),width,height*(state->max - state->min));
cairo_set_source_rgb(cr, 0.05,0.6,0.15); //What color should be used here?
cairo_fill (cr);
cairo_set_source_rgb(cr,0.01,0.3,0.07); //And here
auto mid=height*(1.0 - 0.5*(state->min + state->max));
cairo_move_to(cr,0, mid);
cairo_line_to(cr,width,mid);
cairo_stroke(cr);
return FALSE;
}
Use gtk_render_frame() and gtk_render_background(), and set up the GtkStyleContext you obtain from the GtkWidget instance with the CSS state you want to replicate.
If you want to adhere to the theme, then you cannot draw yourself; and CSS does not have "colors": each CSS state can have multiple layers that include images, gradients, and complex blend modes.
Well, here is my hack:
ColorRGBA get_ambient_color(GtkWidget* widget)
{
auto surface=cairo_image_surface_create(CAIRO_FORMAT_ARGB32,4,4);
auto cr=cairo_create(surface);
while(widge!=NULL)
{
auto context=gtk_widget_get_style_context(widget));
gtk_render_background(context,cr,0,0,1,1);
cairo_surface_flush(surface);
auto content=cairo_image_surface_get_data(surface);
if(content[3]==255)
{
auto ret=ColorRGBA{content[2]/255.0f,content[1]/255.0f,content[0]/255.0f,content[3]/255.0f};
cairo_destroy(cr);
cairo_surface_destroy(surface);
return ret;
}
// Surface is not opaque yet. Continue to parent container.
widget_handle=gtk_widget_get_parent(GTK_WIDGET(widget_handle));
}
cairo_destroy(cr);
cairo_surface_destroy(surface);
return ColorRGBA{1.0f,1.0f,1.0f,1.0f};
}
It seams that I have failed to convince people, why you need the ambient colour, so here are two use-cases:
Determine if we are using a dark/light theme. For some applications, this is sufficient. Querying the state only works if the theme supports dark/light modes. This proves the actual result.
Use as input colour for simulating global illumination. The shading of widgets should be affected by the ambient, hence the name. Another good name would be get_average_background. Themers: please don't use gradients with high contrast.
Case 1: A plot
Now you say that the colour of cursors and function graphs should be themable. That is simply not possible: The user of this plot widget can add as many curves and cursors as he wishes, and the easiest way to differentiate them is to use distinct colours.
What about curve and cursor lightness? If the background is dark, then the curve should be light and vice versa. And what background should be chosen? Ideally, something close the the background of the parent widget, but if the theme is regular, white for light, and black for dark would work. Do you notice that the curves are darker in the second figure?
Case 2: A checkbox that looks like a metallic toggle switch button
With the following technique, I have created a switch that looks exactly as if it were rendered through the Cycles path tracer. This is implemented in Gtk+2, but the algorithm is the same.
The two input images
The code
GtkAllocation alloc;
gtk_widget_get_allocation(widget,&alloc);
auto width=alloc.width;
auto context=CairoContext( gdk_cairo_create(gtk_widget_get_window(widget)) );
auto w_in=cairo_image_surface_get_width(light);
auto h_in=cairo_image_surface_get_height(light);
// Render direct lighting
auto surf_temp=CairoSurface( cairo_image_surface_create(CAIRO_FORMAT_ARGB32,w_in,h_in) );
auto context_temp=CairoContext( cairo_create(surf_temp) );
cairo_set_source_surface(context_temp,light,0,0);
cairo_set_operator(context_temp,CAIRO_OPERATOR_OVER);
cairo_paint(context_temp);
//Render ambient reflections
auto surf_temp_2=CairoSurface( cairo_image_surface_create(CAIRO_FORMAT_ARGB32,w_in,h_in) );
auto context_temp_2=CairoContext( cairo_create(surf_temp_2) );
cairo_set_source_surface(context_temp_2,background,0,0);
cairo_set_operator(context_temp_2,CAIRO_OPERATOR_OVER);
cairo_paint(context_temp_2);
cairo_set_operator(context_temp_2,CAIRO_OPERATOR_MULTIPLY);
//Multiply reflections with the background color
cairo_set_source_rgb(context_temp_2, color_bg.r, color_bg.g, color_bg.b);
cairo_rectangle(context_temp_2, 0, 0, w_in, h_in);
cairo_mask_surface(context_temp_2,surf_temp,0,0);
//Add the results
cairo_set_source_surface(context_temp,surf_temp_2,0,0);
cairo_set_operator(context_temp,CAIRO_OPERATOR_ADD);
cairo_mask_surface(context_temp,surf_temp,0,0);
//Scale and move things into place
auto s=static_cast<double>(width)/static_cast<double>(w_in);
cairo_translate(context,alloc.x,alloc.y);
cairo_scale(context,s,s);
cairo_set_source_surface(context,surf_temp,0,0);
cairo_set_operator(context,CAIRO_OPERATOR_OVER);
cairo_paint(context);
Thoughts
The first example boils down to a light/dark query which is currently missing. Maybe querying colours is not required for this to work, but then there has to be an API controlling the shape and blending mode when rendering the background. For example, to render the ambient reflection, I use multiply rather than over. Also, gtk_render_background appears to be a no-op, since GtkDrawingArea has zero opacity (that's why I needed the loop). To be useful, it must use the background as it appears on screen, not the background of the current widget.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What is advantage of using LESS variables for changing properties like;
#Margin-10: 10px;
#Margin-12: 12px;
#Margin-19: 19px;
#Margin-110: 110px;
#Margin-189: 189px;
#Margin-115: 115px;
#Margin-150: 150px;
.................and so on.
And creating those variables which will not be alter in future.
#PullLeft: left;
#PullRight: right;
I am re-factoring the LESS in my application which has too many CSS properties which are using variables for above scenarios. Is there any advantage of using variables in this case?
I think we may have a hammer in the house with those variables. Having them named so specifically is problematic both because it doesn't really work with semantic concepts of layouts AND because if you were to change some of them, total chaos would soon ensue. Just imagine:
#margin-189: 27px;
#margin-115: 46px;
I had trouble typing that even as an example. I feel something like the shower scene from The Crying Game.
No, these variables are an example of when your only tool is a hammer, all you see are nails.
More correct might be something more semantically flavored, like:
#container-margin-left: 36px;
#panel-margin-left: 20px;
Those at least speak to how your site will be styled AND if the values were to change, it would not result in an immediate maintenance trainwreck.
Its highly discouraged to use the name of variable same as value. The purpose of using variables is that if there is a change required then modification is minimal. e.g you have declared a variable #Container-width: 100px and you are using it in 10 files. So if you want to change its value to 200px then you would simple have to change value nothing more.
There are two disadvantages of using variables names as you suggest:
If you want to change the variable #Margin-10 value to say 15 e.g #Margin-10: 15 it would look odd.
If you are declaring variables for each value then there is no benefit of declaring it as variable because you have to modify it on several places (which is not fulfilling the purpose of variables)
Now coming to the variable name #PullRight or #PullLeft. Again there is no benefit of using such names, as the values (left, right, top , bottom) are limited not variable. So I would suggest that you don't create variables but use values as it is.
Create variable names on the basis of their functionality. Use noun and verbs.
It's the same as using variables in any language. You can simply change them whenever you want.
Now you can think - they will never change, but in future you may want to make some changes. You may even move some CSS to another project where you decide to make some changes. Using variables you will do it it a minute.
Another example. Let's assume you have the following code in CSS:
#page {
width: 800px;
}
#content {
width: 600px;
}
#sidebar {
width: 200px;
}
now you decide to change #page width to 780px
SO you change it:
#page {
width: 780px;
}
#content {
width: 600px;
}
#sidebar {
width: 200px;
}
and now you have a problem - you need to look in the whole file what's wrong (in real file it won't be so easy as in example above).
Using variables you could have:
#page-width: 800px
#content-width: 600px;
#sidebar-width: #page-width - #content-width;
so without a problem you can change the value or make small modification in those 3 lines.
However in the example from question I think it hasn't been done as it should. If you define:
#Margin-10: 10px;
#Margin-12: 12px;
#Margin-19: 19px;
you expect that Margin-10 is 10 unit margin but you can decide to change the value for let's say 11 and you can have:
#Margin-10: 11px;
#Margin-12: 15px;
#Margin-19: 24px;
It will make you completely mess, because in fact even if you look at this file, you now don't know what is Margin-10 variable and what's its purpose. It has even other value than its name suggests so you don't really know what to expect and you again need to look at whole CSS source.
So variables are useful but they should have names that you can easily remember and know what's their purpose. You should never connect variable name with variable value because value can change and you will get useless name.
However it's also possible in above example that someone defined those margins even not to change their values but to change their units, for example for using em:
#Margin-10: 10em;
#Margin-12: 12em;
#Margin-19: 19em;
However I still think it's not the best solution because it's limiting re-usage this file
I'm using a sublime text 2 plugin less2css to compile my less files into css files. The issue I'm having is that the plugin won't compile my mixin which is used to dynamically create header font size. I've tested the mixin with the online less compiler which winless offers, and it seems to work fine.
Is this just a bug with the plugin, or am I doing something completely wrong in my mixin?
Mixin:
#fontSize: 24px;
.calcFontSize(#index) when (#index > 0) {
(~'h#{index}') {
font-size: #fontSize - #index * 3;
}
.calcFontSize(#index - 1);
}
.calcFontSize(0) {}
.calcFontSize(6);
The issue seems to occur on this line: (~'h#{index}') {. Changing this to an h1 (or any other header element) works fine.
Your code (and WINLESS too, I believe, which is why it works there) is using older syntax for LESS CSS. Your code compiles fine at http://less2css.org/ when set to LESS 1.3.0-1.3.3, but there was a syntax change for LESS 1.4+ (no interpolation needed). So if your Sublime has upgraded the LESS to 1.4+, then that would explain why your code does not work.
If this is in fact the issue, then you just need to change the syntax of your line like so:
h#{index} {
font-size: #fontSize - #index * 3;
}
Which you can see works on http://less2css.org/ for the 1.4+ versions of LESS.
In XAML, you can define a size property (such a length or width) in "*" units, in which * represents a part of the remaining space.
So, if I have a parent element that is 1000px wide, and it has 2 children, which are both defined as being 1* wide, they will be 500px each. If one is defined as 3*, and the other as 1*, then one will be 750px, the other 250px.
If there is a third element, and the widths of the 3 are defined as "100px", "" "2" respectively, then the widths of the 3 will be 100px, 300px, 600px.
Is there a CSS equivalent of this, or should I just simulate it using calc()?
Flexible box layout model does that with an OK support matrix (no IE)
It does exactly what you're after, e.g. for your scenario 3:
<div class="box">
<div>un</div><div>deux</div><div>trois</div>
</div>
.box {
width: 1000px;
display: box;
box-orient: horizontal;
}
.box > div:nth-child(1){ width:100px; }
.box > div:nth-child(2){ box-flex: 1; }
.box > div:nth-child(3){ box-flex: 2; }
Fiddle'd from html5rocks example
Although ratios aren't supported in CSS, percentages are. This means you can't really specify "the rest of the width", but you can normally get what you want.
For example, your first example of 1000px with 1* could be achieved by assigning `width: 50%'. Your second example would be 75% and 25%.
Your third example is a bit more complicated, mixing fixed px values and percentage values won't work. What you can do is use some clever margins to get the overall result.
I have created a JS Fiddle to illustrate the third example.