How to Modify Styles
On this guide you will find some ways to modify styles in you recently migrated app, also some tips and best practices.
Introduction
If you analyze the way styles were applied in Silverlight and compare it with how modern web pages are styled, you can see some significant differences. In Silverlight, properties could be defined directly in the XAML, which affected the appearance of the control that was being rendered, these same properties could be edited from the C# associated with that XAML, these would have the same impact as those applied from XAML. In addition to this, there was a way to apply generic styles based on a Style property that had a key that was later associated with a control, all controls that had this key would be affected, it was a powerful tool since it overwrote the control template, as an example, a Button could have the appearance of a TextBox.
Those are a few ways styles were applied in Silverlight, while in modern web applications the most standardized way is using stylesheets (CSS, SCSS, LESS), although it is also possible to apply it from code behind is not very common, based on the exposed theory, you can see that differences are more than noticeable between both technologies, in a Silverlight migrated application you will find a mix between both approaches, so the appearance can be affected by editing properties on model associated with the component, as well as editing directly from a .scss file, these types of solutions do not apply to all cases, there are some scenarios where one approach may work better than another, the different ways to use styles are detailed below.
Applying Styles
There a quite a few ways to apply styles on your recently migrated, let's see some of them with the help of the following samples.
Modern approach
In this section the documentation will cover some of the "modern" approaches, none of them are available since all are based on the stylesheet premise, it will take advantage of the scss classes, variables, etc.
Component Style
Each component supported by the i-component library has an associated .scss file that contains the default styles of the component, the default appearance of a Silverlight control should match the styles of this file, this is the best way to apply default styles. It is noteworthy that if you edit this file all controls will be affected, for example, if a button is defined to have a red background color, all buttons in the application will have a red background.
You can see that each component is associated with a .scss file.
It is clear that the style of TextBox matches the Silverlight since it is the default appearance. If you go to the component repository, then open up text-box.component.scss you will find the definition of this style.
Associated Migrated Class
When a Silverlight control is migrated to Angular, it will have an associated SCSS class, which can be used to change the style for each component, this method is limited due to the Angular style encapsulation, usually, few things can be changed if is inside of the component itself, although it is not recommended you can break this encapsulation using ::ng-deep selector.
This method would only work on Angular since it is a web approach that does not exist on Silverlight.
If you go to the definition of this component on MainPage.component.html , in this case, you are looking for a grid, once that is found you can see that it has the class already mentioned, then you can go to MainPage.component.scss to add CSS properties to customize the element.
Generic Components Style
As mentioned before, each control supported byi-components has an associated .scss, but this library also has a generic style file, this file must be treated with extreme care because it can overwrite the style of any component, and it has the potential to affect the general style of the application. The purpose of this file is to override other style-level behaviors or to add generic styles to components.
In this scenario, the sample is using a StackPanel which has some special rules to position its items, this style was written in the stackpanel.scss file, then that can be imported into the main styles.scss of i-components since it will affect other controls as well.
Generic Migrated Style
Similar to the previous point, with all the previously mentioned implications, editing this file means that the entire migrated application will be affected.
When to apply a style in the general file of components or the generic file of migrated application? A simple way to approach this problem is identifying if the appearance is default or not, if the change you want to apply is the default behavior of Silverlight, these should go in the component repository, since these represent the default versions of what it can be found in Silverlight, on the other hand, if the style is more focused on changing the default behavior of your application, in other words, generic customization but specific to your migrated application, it should be applied in the generic styles file of the migrated app.
This method would only work on Angular since it is a web approach that does not exist on Silverlight.
On the styles.scss in your migrated app you can write your custom generic styles, keep in mind that this will override existing styles, so be careful.
Using CustomCSSClasses property
CustomCSSClasses is a framework property that can be found on all component models, which adds a class to the component itself.
It can be helpful to identify the element in the DOM and use selectors to apply the required styles.
This method would only work on Angular since it is a web approach that does not exist on Silverlight.
Directly on the component model, you can set the name of the class that you want to apply, then on the styles.scss you can add the actual CSS class.
On MainPage.ts file.
On styles.scss file.
Legacy approach
In this section, you are going to see some technics that are more Silverlight style, remember that a lot of the Styling mechanisms that use Silverlight have been converted to Angular as well, so you will see that Angular and Silverlight would be very similar.
Using Model properties
Earlier in the introduction chapter, it is mentioned that this is one of the ways to apply styles in Silverlight, therefore in the migrated application should be a similar mechanism, it is important to remember that Silverlight controls will be migrated to models that are subsequently associated with a component, some of these properties affect the aesthetics of the component, another point to note is that not all properties are supported in all controls, for example, the background property may be supported in the button but not in the grid, for this approach to work, the property must be properly supported. Assuming the property is supported you can do the following.
As you can see, you can set properties through HTML input or set in code behind accessing the component model.
Using Model.Style property
Finally, the Style property of the component model essentially assigns other properties of that same model, for example.
In the following snippet, you can see that the Style property sets other model properties.
Here you can see all the samples that you just covered in the documentation, on the annexes section you can download both the Silverlight version and the migrated Angular one.
Specificity and importance of the Styles
As you may know, to apply a style through CSS there are some variables to keep in mind, the most important one is specificity since the most specific selector would be the one applied, if there are two equally specific selectors, the browser will apply the last one imported.
On your migrated application you may find a style that is being applied through the model, and you may want to use CSS instead, i-components library usually would always prefer the model value instead of the CSS one, since the framework is applied directly in the element style, this cannot be overridden without using !important.
Tips and best practices
Avoid using !important, try using more specific selectors.
Avoid using ::ng-deep, but if you have to use it with the :host, it should look like this.
Instead of hardcoding px values such as height and width use SCSS variables, this also applies to color properties, these variables can be used through multiple files if you create a _variables.scss
Height and Width are properties directly applied in the element style, it does not matter how specific is your selector it will not work, to avoid this, you can add [useCss] input to add your custom height and width through SCSS.
Another powerful tool is using CSS custom variables, such as the following.
This can be useful to override third-party libraries in the case they are supported, and also can be used to create variables to override component-level styles that you later want to override in your migrated application.
If you need to override the default width inside a XamGridCell, you will see that by default the XamGrid set to auto !important, but if you need to be managed by the control itself you can add the horizontal-selfalign class so the important tag will be ignored.
Since the horizontal-selfalign is HostBinding you can set it through an input.
Annexes
Last updated
Was this helpful?