css variables :root vs :host - css

Just starting with webdevelopment (coming from android)
in my project I tried to assign variables as in many tutorial is mentions with help of ":root" :
:root {
--accentColor: #20a8d8;
--primary: #96a1a5;
--secondary: #415a72;
--bgColorrr:#1e2e38;
}
But that did not work at all.
After changing it to ":host" it work though - can someone please explain what is the reason behind :root not working?
May be worth mention: I used that on my custom component (Angular 5) and I'm using CoreUI (in case that may effect some CSS)

You're talking about Shadow DOM. Elements can get a new kind of node associated with them. This new kind of node is called a shadow root. An element that has a shadow root associated with it is called a shadow host. The content of a shadow host isn’t rendered; the content of the shadow root is rendered instead. There's this thing called Style Encapsulation.
Also I would suggest avoiding the use of :root. I know the docs say to use :root and technically I think that's fine to do at the document level, but you are using a framework maybe there is a conflict inside of the Shadow DOM and cause a bug. Avoiding :root all together might just be a good habit to get into. #pb4now correct me if I'm totally wrong about stuff.
Here's more info about Shadow DOM and read more about Angular Style Components. Hope it helps.

Related

Using existing CSS selectors to apply styles across the Shadow DOM to custom elements

This question likely has no single direct answer, but hopefully will lead to some best practices or common patterns to use when adapting an existing styles framework to new web component development.
For my case, I have a component <custom-avatar>, and it's all set up properly with self-contained styles and functionality, everything is just peachy.
In certain use cases, the application display needs to stack avatars, just one slightly overtop one other at a diagonal, and the pattern I'm following is using a simple component <custom-composite-avatar>. All this does is wrap the slotted content in a <div> with the correct styling class, but key aspect is retaining the composability for flexible re-use, like so:
<custom-composite-avatar>
<custom-avatar title="first"></custom-avatar>
<custom-avatar title="second"></custom-avatar>
</custom-composite-avatar>
The tricky bit lies in the styles, which are imported from a monorepo that provides the same BEM-ish CSS and component CSS modules to other flavors of the component library like React, Vue, etc. I have the avatar and composite-avatar styles imported just fine, but forcing the intended overlap display is defined with the hierarchical selector .my-composite-avatar.my-composite-avatar--medium .my-avatar {}
So with .my-composite-avatar class applied to the div wrapper within <custom-composite-avatar> and the .my-avatar class applied to the wrapper within the <custom-avatar> and it's own Shadow DOM, that parent/child CSS selector is no good.
I doubt there is a silver bullet for this, but this seems like it will be a rather common scenario as more people migrate to Web Components while using existing styling systems. What approach makes the most sense to ensure that the composite component remains composable, and adaptation of existing selectors pain-free (or at least easy to communicate to other devs)? can this be solved with ::host or ::slotted, or will these cases require significant re-work?
Thanks for reading, your ideas are appreciated!
I would advice to become good friends with CSS properties
because they trickle down into shadowDOMs following CSS selectors.
CSS Custom Properties(variables)
and getPropertyValue
and setProperty if you want to be brutal and make Custom Elements change the outside world.
example
I have an <SVG-ICON> element taking configuration from attributes OR CSS properties
with my favorite lines of code:
let val = this.getAttribute(attr)
||
getComputedStyle(this)
.getPropertyValue("--svg-icon-" + attr)
.replace(/"/g, "")
.trim();
Allows for your standard attribute configuration:
<svg-icon name="configuration" fill="grey"></svg-icon>
But more powerful (simplified example):
<style>
body {
--svg-icon-fill: "grey";
}
svg-icon[selected] {
--svg-icon-fill: "green";
}
</style>
<svg-icon name="messages" selected></svg-icon>
<svg-icon name="configuration"></svg-icon>
CSS = Custom String Scripting
It doesn't often happen, but sometimes the simplest code makes me very happy.
There is no Styling restriction!
These 2 lines allow any String you want in CSS properties:
.replace(/"/g, "")
.trim();
Example
<style>
[name*="globe"] {
--svg-icon-tile: "rect:0,0,24,24,0,fill='blue'";
--svg-icon-stroke: white;
}
</style>
<svg-icon name="feather-icons-globe"></svg-icon>
The --svg-icon-tile has nothing to do with CSS, it is read (and parsed) by the <SVG-ICON> connectedCallback() code to generate a SVG background/tile for all icons named globe.
The double-quotes aren't required, but without them your IDE will complain about invalid CSS.
Have fun coding... you will pull some hairs when you start with calc() in your CSS properties...
But you can take 'CSS' to another level.
PS.
And monitor the future of ConstructAble StyleSheets aka ConstructIble StyleSheets aka Constructed Sheets aka AdoptedStyleSheets:
https://developers.google.com/web/updates/2019/02/constructable-stylesheets
https://chromestatus.com/feature/5394843094220800
iconmeister

How do I customize the styles within an Angular Material Input?

I am working with a freelance client on the side that wants to utilize Angular Material throughout the project. However, they do not like the way that the underline looks in the angular material input. I have tried a variety of approaches to change this, but I haven't found any success yet.
To be honest, I haven't even been able to find the tag in the DOM that would let me alter that border.
Here are the Angular Material docs, as you can see all of the available options have at least some form of a bottom border.
Some approaches I've tried:
This one is from the old angular material and no longer works for the new angular material
The accepted answer here is for the new angular material, but I was not able to get it to work. I implemented exactly as described and no styling changed.
This approach looked like it would work. Unfortunately, I could not get it to work either.
Any help or input on this topic would be appreciated.
For reference, the client said that any changes that deviated from the desired design would be denied. So I have to get this to work. I believe I could maybe, possibly lobby to build a custom input component as a solution, but I know that they are dead set on Angular Material.
Edit. Added a pic of desired look:
this little code did it for me. I didn't want to display it and just set height and width to 0.
::ng-deep .mat-form-field-underline{
height:0 !important;
width:0 !important;
}
However I think its kinda hard to style the Angular Material Components and for me its sometimes better to built my own.
First of all, you'll need a .scss to be imported either within the default theme.scss or after the import of the material stylesheet in main.scss.
Now, Material offers you the option of customising colours and some of the styles by overriding their #mixins found somewhere in the Material folder ( I don't have the folder in front of me.. very sorry for the vague pointing... ).
Back to the newly added file; You can override material's default styling by checking the DOM for certain classes and then adding them in said file with the desired changes. Because the file is loaded after Material's, the default styling in overridden. Same thing applies for the #mixin you chose to override. Just have a look in the file, copy-paste the whole #mixin and change accordingly.
Now if you wish to go even further, my colleagues and I have a custom library that uses Material BUT the whole styling is stripped off leaving you with the bear input within the mat-form-group and then using a <input disabled/> with a position:absolute over it. That way you get to benefit from material without using their style.

Where is this style attribute on my Angular router-outlet element coming from?

So I've got an Angular app that has pretty basic routing, and I'm using flexbox to layout my components. The issue I can't figure out is with code like this:
<div fxLayout="column"
fxFlex
class="layout__right">
<router-outlet></router-outlet>
</div>
The child component that is routed to contains the following in its SCSS:
:host {
#include make-flex-container(column);
flex: 1;
}
That make-flex-container just applies some flexbox related styles, and works fine in many places of the app. What's happening in my case though is when routing to this particular child component I see a style tag applied to the ng-component element created by Angular. What's causing my problem is for some reason the style includes flexbox items that are overriding what I'm putting in :host:
You can see in the screenshot that my :host styles are being applied, but the styles on the ng-component tag are simply overriding them. For the life of me I can't understand why there's a specific style tag added here, so where the content within it would come from. Does anyone know why Angular would put style tags on the HTML generated for router-outlets? When I navigate to other components at this same routing level this style tag isn't present.
I assume this is an issue with my code, but I just can't run down where to look given what I see.
UPDATE
Here's a minimal reproduction of the issue on Stackblitz:
https://so-48451609-routing-flex-issue.stackblitz.io
In that example you can see how the element created next to the router outlet has styles applied to it. The only dependency added there is #angular/flex-layout, so it's gotta be doing something to cause this.
The fxLayout directive applies styles to child elements. It does this on the element itself to not interfere with other styles.
The #angular/flex-layout library's static API has directives that work either on a DOM container or DOM elements. fxLayout is an example of the former, fxFlex is an example of the latter.
See the docs here, note the two sections for elements and containers: https://github.com/angular/flex-layout/wiki/Declarative-API-Overview#api-for-dom-containers
THEY COME FROM VIEW ENCAPSULATION
I believe that these classes are part of view encapsulation that prevents angular elements from being styled from outside and to prevent interference between view components. At least that is what they say in official docs #angular.io.
As suggested #this SO post the '_ngcontent-c0' is naming of the first component within the host.
ANGULAR MATERIAL IS CAUSING TROUBLES
I have found a bunch of issues related to encapsulation at GitHub and they often seem to be related to using Angular Material, which seems to have encapsulation turned off sometimes somehow. Such as described here. Hence I conclude that your implementation of Angular Material might be at fault. For in depth analysis of what the mechanism of this unwanted interaction is, you might probably like to start by reading joh04667's answer to your question since it provides links to the documentation of the particular material you use.
PROPER STYLING
Common solution to those issues is overriding styles with /deep/ selector as described in both above shared links. A number of unofficial articles on styling Angular app is available as well, such as this one.
IDEA
So the idea is to overwrite the styles in your component with /deep/ like this:
:host /deep/ .your_flex_class {
#include make-flex-container(column);
flex: 1;
}
CONSIDER VALID CSS
Since I think that you use Scss, using /deep/ selector should be ok and should be compiled successfully (I use it quite often to style inline SVGs). However, in a fact, this selector seems to be deprecated as a whole bunch of things related to the issue of Shadow DOM. I believe the correct universal approach would be to use 'shadow-piercing descendant combinator':
:host >>> .your_flex_class {
#include make-flex-container(column);
flex: 1;
}
It should does all the same as /deep/ selector. To explain the mechanism, let me cite from official docs for CSS Scoping Module Level 1
When a >>> combinator (or shadow-piercing descendant combinator) is encountered in a selector, replace every element in the selector match list with every element reachable from the original element by traversing any number of child lists or shadow trees.
Basically, it does not care about the wrapper and bites down to your target to style it. So you have even one more option to try ...
Ok, once I created a working example of this I eventually found the culprit and a suitable work-around. What is happening is within my router child component I'm using fxFlex from #angular/flex-layout to flex the element. I'm applying the flexbox container CSS in the :host{} section of the components CSS, but flex-layout doesn't see this in the rendered HTML and applies the style tag to do a flexbox row layout automatically.
Here's an issue on Github with my comments and a suitable workaround of using !important in my :host{} CSS:
https://github.com/angular/flex-layout/issues/496#issuecomment-360870510

Confusion with BEM modifiers

I have started using BEM methodology while writing my CSS and there have been few occasions where I have struggled to find out the best way to do a particular thing.
I would like to take up a simple example of a panel here.
Lets say I am writing a panel component CSS using BEM style. So my CSS might look as follows:
.panel {}
.panel__titlebar {}
.panel__content { display: none; }
A panel can be either chromeless or with chrome. So I define another modifier class for the panel:
.panel--with-chrome {
border: 4px solid black;
border-radius: 4px;
}
Now lets say, the panel can be in a fullscreen/maximized state also in which the chrome and titlebar disappear. Instead of defining modifiers for both panel and titlebar, it would be be wise to define the modifier just on parent (say panel--fullscreen) and rest elements shall change accordingly. So now my CSS becomes:
.panel--fullscreen {
/* something has to be done here */
}
.panel--fullscreen .panel__titlebar { display: none; }
To remove the chrome in fullscreen mode, I can either:
toggle the panel--with-chrome class in JS along with the panel--fullscreen class
overwrite the chrome CSS inside the panel--fullscreen class.
First isn't good because ideally I would like to simply toggle just one class (.panel--fullscreen) in JS to toggle fullscreen mode.
And second one is bad because I'll have to overwrite previous CSS which is a bad practice.
So whats the best way to go about it? Appreciate your comments.
Thanks
The answer depends on many things.
First, how much logic and appearance have "panel--with-chrome" and "panel--fullscreen" modifiers. And also on what kind this logic is.
If "panel--with-chrome" brings a lot of CSS properties and special JS functionality, I would toggle it in JavaScript when applying "panel--fullscreen".
It also depends on a JavaScript framework you use. In "i-bem.js" which we use at Yandex it's easy to react to appending a modifier:
A square changes size modifier when after a click
Reacting on applying a modifier
But if the framework you use doesn't allow to express such a reaction handy, this answer won't work that great for you.
In the other case, when "panel--with-chrome" has not very much properties and doesn't bring any JavaScript logic to a page, I would redefine those CSS properties in "panel--fullscreen" class.
To sum up, there is no universal solution and strict rules to follow. You should decide yourself what will be useful in your case. The decision should depend on many things:
if you expect your project to be maintained in the future, which solution will be easier to support?
capabilities of the JavaScript framework you use
performance stuff
Not in this particular case, but sometimes we measure speed of rendering for variants we are choosing from.
opinion of the other guys, if you work in team
file structure of your project
We, here at Yandex, store CSS and JavaScript for a block in the same block folder. So, it is not a problem to share logic between CSS and JavaScript since they all are in one place.
But if you keep your JavaScript files separately, this can influence on how comfortable it is to support shared logic.
And so on...
I’d go with the first option; you are toggling state after all, so you need to add/remove/toggle classes accordingly. It’s better than undoing a load of stuff in CSS IMO.

gwt how to use setStyleName(String style, boolean add) - for a gwt standard widget

I want to style/mark a MenuItem in GWT MenuBar. So i have some logic that adds a style name to a menu item (the logic is working properly).
mItem.setStyleName("menuItemMarked", true);
with this set getStyleName yields "gwt-MenuItem menuItemMarked" as expected.
But how to use/apply this style in css (at the moment i put css in uibinder.xml)? (as you may see i am not a css expert)
update: what i tried is that.
.menuItemMarked{background-color: yellow}
this is not working. if i call "inspect element"(chrome) i can see "class="gwt-MenuItem menuItemMarked" but i can not find the style "menuItemMarked" in the list of applied styles?!
Where are you specifying your CSS?
If your code is located within your code packages, it is likely being obfuscated by the GWT compiler. This applies to <ui:style> blocks in .ui.xml files, and .css files included in ClientBundles.
In this case, you will want to check out Programmatic Access to Inline Styles from the GWT docs. This will allow you to change your code to:
mItem.setStyleName(style.menuItemMarked(), true);
Alternatively, you can tell GWT to not obfuscate certain CSS classes. Here is a detailed answer to a similar question
Finally, if GWT does not touch your CSS file (it is being served from your server like other files), then you will need to make sure that your file is being included in your page properly. Your browser's dev tools should be able to help with that.
Make sure you specify correct selector name in your css. In this case you need to have following:
.gwt-MenuItem.menuItemMarked {
background-color: yellow;
}
Since gwt-MenuItem remains the first class name in the list it takes precedence over any styles (incl. background-color) defined in the subsequent classes. The only way to overrule this is to define styles with more specific selector like above. Check this link out for more detailed explanation.

Resources