Replies: 56 comments
-
Hi @Eralmidia we will look into this issue next week. |
Beta Was this translation helpful? Give feedback.
-
@simeonoff Which next week? 😛 |
Beta Was this translation helpful? Give feedback.
-
Hi, just added it to this sprint. |
Beta Was this translation helpful? Give feedback.
-
@gmurray81 can you chime in? I'm testing the charts in Ignite UI for Angular v12.2.0 and some styling properties no longer work. I tried setting the range brushes for the linear gauge via both property binding and custom CSS properties, alas none of these methods work anymore. Obviously this affects the theming system. |
Beta Was this translation helpful? Give feedback.
-
I'll take a loot at this on Monday. I fixed some stuff recently in this area, but that actually had to do with the other way around where we had a regression specific to ES2015+ where the css properties would always take precedence. But that doesn't seem like what is being described here, so will look into this. |
Beta Was this translation helpful? Give feedback.
-
@Eralmidia That all still works if I upgrade the packages to latest, so I'll have to see what you were having issues with specifically @simeonoff |
Beta Was this translation helpful? Give feedback.
-
Or are you talking about an internal package version? |
Beta Was this translation helpful? Give feedback.
-
If you are talking about the latest internal versions, maybe that explains what you are seeing, depending on the sample. I fixed an issue where in some cases the css would always take precedence, even over a local value set by the user. That's been resolved. So maybe the sample you were using has some local values? Another possibility though, is perhaps some specific scenarios are getting confused and thinking that an internal default constitutes a user provided local value. In which case that will just need to be resolved. |
Beta Was this translation helpful? Give feedback.
-
Any news on this? This is kinda blocking our release now, and becoming a major issue for us. |
Beta Was this translation helpful? Give feedback.
-
@Eralmidia did you try my suggestion above? --axis-label-text-color: orange |
Beta Was this translation helpful? Give feedback.
-
No unfortunately it's not working. It seems to be the same issue as the color of the columns, it doesn't listen to the theme. The title however works. So the following: Both label and brushes seems to be overwritten by the palette: If I remove the palette the colors from the theme (or brushes inputs on the charts for that matter) starts working: But as mentioned, lots of other things break in the CSS in other components if I remove that line, so I'm assuming that's meant to be there. @kdinev Any chance we can bump this up from low priority, this is kinda GUI-breaking for our application? |
Beta Was this translation helpful? Give feedback.
-
hmm... those properties were working just fine outside of the main scss theme, so maybe something in the theme is taking higher precedence (higher specificity)? you could try using important to see if it behaves. I'm not really familiar with the structure of the theme, so I'll let @simeonoff investigate that aspect of it. Let me try loading the full theme in the sample I sent you and see if the behavior is the same. What's the exact package version you are using @Eralmidia? So that I can make sure I'm comparing like for like. |
Beta Was this translation helpful? Give feedback.
-
I updated this stackblitz to import the theme and, presuming I did that correctly, it seems like I can still set the axis title color using the css property I mentioned. But the theme does also try to set this, so maybe its a specificity issue? |
Beta Was this translation helpful? Give feedback.
-
Setting the properties as important didn't do anything. But yes, a specificity issue definitely seems like the most likely cause |
Beta Was this translation helpful? Give feedback.
-
It is possible that something else is colliding with those then. Let me check your example. Hopefully @simeonoff will be able to chime in as to what the expectation is in building the theme the way you are trying to. My expectation would be given my limited knowledge of scss is that given how you are declaring those themes that you are expecting it to add dark-theme as an ANDed class with the classes in the theme's rules, rather than as ORed with the classes in the theme's rules which is the whole issue, since it is resulting in every rule applying to every component. |
Beta Was this translation helpful? Give feedback.
-
Actually it was @simeonoff who told me to build it this way, 3 years back: And it has been working fine up until recently. |
Beta Was this translation helpful? Give feedback.
-
It's possible that some of the composition functions that build the theme. changed.. Or that maybe what changed is that more of the components are themed and so there are some colliding property names. You could try comparing the css rules that were emitted in the version that was working and today and that might shed some light on it. The key to the other properties working is to make sure to set the same properties that the theme is setting. .ig-data-chart {
--plot-area-background: red !important;
--title-text-color: red !important;
--label-text-color: red !important;
--category-axis-base-strip: green !important;
} These properties are working fine for me. I used !important because the ones coming from the theme have higher specificity. Note though, that I had to use --title-text-color and --label-text-color because these are what the theme was using. It should probably be using more specific variations of these properties to make sure its targeting the axes. For the strip, notice I used category-axis-base-strip because if I just used strip, it would target the y axis too. But if you use other types of horizontal axis in the chart you would have to target them also. I hope this helps! |
Beta Was this translation helpful? Give feedback.
-
Note, I was initially having a hard time testing this, because I think that the way that angular is doing hot module reloads for the scss could be playing games with us. For the canvas based components we need to explicitly extract the CSS custom props we are looking for and need to be notified if the css environment around us changes. I suspect the tooling is injecting new CSS into the page in such a way that we don't see it, sometimes, even if you are trying to hard reload. Seems more reliable to open a new tab. If there's some way for us to listen for the hot reload system changing the CSS environment, we could make sure we respond, but I'm not sure if we'll have the right hooks for that. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
it may have been that they were actually being set for a different component, and its a collison. The easiest way to parse it is to switch to the computed property view in the f12 tools rather than the style view. And see what properties are in effect. It may be that those properties were coming from pie chart or category chart style. Again, part of the issue here is that because the rule selector is: .dark-theme, .dark-theme igx-data-chart { and all of the rule selectors look that way. It means that all of the rules are getting set for anything that has .dark-theme, not just the components that those rules are actually meant to apply to. So you have rules that are trying to set properties for pie-chart that are getting applied to data-chart and vice versa. This doesn't seem like its the desired outcome, but if it is, collisions could be avoided by adjusting the property names to scope them to the components. |
Beta Was this translation helpful? Give feedback.
-
This doesn't happen when you run .dark-theme {
@include igx-theme($palette: $color-palette, $exclude: ('sparkline'));
...
} That it ends up generating selectors for |
Beta Was this translation helpful? Give feedback.
-
I have to assume this is probably incorrect behavior, to use the OR, since your general expectation when nesting in SCSS would be AND behavior, as far as I'm aware, but I'm not super familiar with scss. But maybe there's a good reason why this kind of combination was chosen over the more expected behavior. |
Beta Was this translation helpful? Give feedback.
-
Ok, so setting a color for the slider label color worked, so its defintately a collision. So seems like this will be a good band aid for the problem. |
Beta Was this translation helpful? Give feedback.
-
@Eralmidia awesome, glad to hear. |
Beta Was this translation helpful? Give feedback.
-
@gmurray81 Minor thing: I can't seem to find a variable for the strip-color in the theme docs (https://www.infragistics.com/products/ignite-ui-angular/docs/sass/latest/#function-igx-data-chart-theme). How do you set that? And also, just in case there are some issues with the other components, which css var would I need to override for this? |
Beta Was this translation helpful? Give feedback.
-
Sorry, to clarify my language above, by AND I mean the rule would apply to Its the former behavior we want, not the latter. @Eralmidia those docs may only contain the properties that the scss mixin for creating data chart themes supports. But the chart supports many more custom css properties than that exposes. Basically you can take any visual related property on the chart and convert it to spinal case to set it as a custom css property. In the case of the strip color, there is a property on Axis called strip, so you can set it as: --strip: red; but you can also specify the containing type name to resolve ambiguities: --axis-strip: red; furthermore there are a lot of different types of axes in the chart. So you potentially want to set the strip color for a particular axis type: --category-x-axis-strip: red; so you can resolve ambiguities by pre-pending the target type to the property name. |
Beta Was this translation helpful? Give feedback.
-
to see what visual properties are available on the chart to configure its look and feel, you can check the API doc for the chart. |
Beta Was this translation helpful? Give feedback.
-
Thanks @gmurray81 I assumed things were available in the theme docs like in the other components, but I'll try to locate the chart vars then 👍 |
Beta Was this translation helpful? Give feedback.
-
Question
I know there is a repository for the charts, but I believe the theming support were created by you guys, and since you are generally quick to respond, I'm hoping you can give me some pointers on themes for charts.
To put it simply, I don't understand how I'm supposted to style my charts at all. Since we upgraded from igx 10 to 12, I can't seem to get my charts to apply the correct brushes. Formerly, we generally fed the brushes to the brushes inputs of either the charts or series, but this no longer seems to work, because something in our theme.scss is overriding it.
My next attemt was setting up a theme, but this doesnt seem to work either, because the color palette supplied to the igx-theme seems to be overriding any colors set. So, for instance, I have the following set up for my applications dark theme:
As far as I understand, this should now give the first three series blue, pink and red colors. Looking at a data chart however, I get this:
The yellow color is actually provided by the palette. If I remove
@include igx-theme($color-palette);
from the themethe colors of the theme will suddenly start working:
This will however mess with how other components look, like for instance the time picker, so I'm assuming this is not how I'm suppose to solve this:
It does seem like the theme is actually applied, because if I add forinstance a color the the title, like so:
this is actually displayed as expected:
Also, in the docs, I can see text color for title and sub title. How exactly do I set the label color?
I'm attaching the full theme.scss as well.
theme.zip
Beta Was this translation helpful? Give feedback.
All reactions