CustomStyleService not working for css-mixin object #29
Comments
|
Let me make sure I understand your problem. If you remove the My first thought is that backslash escape character that Angular is adding when it compiles a custom mixin property is breaking something somewhere along the line. I'd be interested to see if anything changes if you declare the mixin property at the end of the block. While div {
--custom-property: red;
}is valid CSS, div {
--custom-property: { color: red }
}is technically not, since It works when you declare it at the document level (in HTML or in external CSS files) because Angular isn't trying to parse those. I wonder if Angular is only parsing CSS for the emulated view encapsulation, that I'll dig into it and try to figure out what specifically is causing that problem. I have a feeling that it's going to end up being a bug ticket with the Angular compiler. |
|
@hotforfeature Thank you for your response. |
|
Were you using https://github.com/platosha/angular-polymer when you tried this in Angular 2.x + Polymer 1.x? This library handles custom styles quite differently. Specifically https://github.com/platosha/angular-polymer/blob/master/src/renderer/shared-custom-styles-host.ts#L29 is a good indicator of the difference. Instead of wrapping what Angular generates as a Two different methodologies, both with their pros and cons. That SharedCustomStylesHost may be solving a problem I overlooked though. I'm not 100% familiar with how Angular generates styles to know if that's where the backslash is coming from, or if it's somewhere else. This is just my first guess and where I'll start looking. |
|
@hotforfeature Yes, I was using angular-polymer. I really appreciate your explanation. |
|
I'm not sure I understand what state you're talking about, are styles not applying? Or is there some other application state that is breaking? If so, what isn't working? Do you get console error messages? CustomStyleService only modifies the document head's styles, so without knowing more about what action your components are doing, it's hard to say if there'd be any conflicts going on. Do you get an error message in the console? How quickly are these new components created and destroyed? You could try moving |
|
@hotforfeature Moving |
|
If you have a sample repo or plunker highlighting the problem I can take a look at the issue. |
|
@hotforfeature I am sorry but it's difficult for me to make a sample for you to use to reproduce my case. Would you like to check via my screen? |
|
Looks like webpack's css-loader is the culprit. I created a simple test webpack project. index.js require('./style.css')style.css html {
--my-mixin: {
color: blue;
}
}webpack.config.js module.exports = {
module: {
loaders: [{
test: /\.css$/,
loader: 'css-loader'
}]
}
};
(function(module, exports, __webpack_require__) {
exports = module.exports = __webpack_require__(1)(undefined);
// imports
// module
exports.push([module.i, "html {\n \\--my-mixin: {\n color: blue;\n }\n}\n", ""]);
// exports
/***/ })The CSS @apply proposal is still very much a rough draft and in early stages of talks across browsers. I don't think we'd get much response or motivation filing a feature request to support it in css-loader, especially when you could use PostCSS in webpack and there's a PostCSS @apply plugin for it. Nor do I think we'd get anywhere asking Angular to switch from the simple css-loader to a complex PostCSS setup. Where do we go from here? Well, I think the best thing we can do is intercept the styles before they are added to the dom as a script tag. angular-polymer may have the right idea in a specialized We could intercept the raw CSS strings and fix the escaped mixin blocks. The rest of the CSS data is there, it just breaks when put after the escaped mixin. We'd also be able directly create and manage the I'll start working on a rough draft implementation. Thanks @First87 for finding this problem! |
|
@hotforfeature No problem. I really appreciate your support. I will consider the possibility of interception. Thanks again. |
|
@First87 I think I may have discovered a possible workaround in my development and discovery. ShadyCSS's apply shim works by converting paper-textarea {
--paper-input-container-input: {
color: darkgreen;
font-size: 20px;
};
} to paper-textarea {
--paper-input-container-input_-_color: darkgreen;
--paper-input-container-input_-_font-size: 20px;
} You may be able to use mixins immediately by writing your mixin block in the "parsed" output that ShadyCSS is expecting. As a side note update, my progress in hacking a fix is going well! I should have it within the next couple of days if work doesn't swamp me. |
|
@hotforfeature It might be kind of a good solution. Btw, sometimes we need to define and use our own mixins. For example, I define a mixin object to apply word-wrapping styles to elements: --my-word-wrapping: {
overflow-wrap: break-word;
word-wrap: break-word;
-ms-word-wrap: break-word;
word-break: break-word;
-ms-word-break: break-word;
...
};Then I use .message-item .text {
@apply --komed-word-wrapping;
/* more styles here */
}I feel it's not reasonable to give parsed css to everywhere the custom mixin is used. Well, of course, I can replace It will be better to me if origami fully supports CSS mixin. :) However, I found another problem in css-mixins with Angular4+Polymer2. The problem is that the document-level styling seems to be parsed differently on different browsers. /* index.html */
...
<!-- custom-style with Polymer 2.x syntax -->
<custom-style>
<style>
* {
...
}
:root {
...
}
body {
...
}
.app-def-btn {
...
}
...
<style>
<custom-style>
...On Google Chrome, all work as intended, however, when I inspect on FireFox and Edge, they are parsed differently as So I am wondering if it's possible to allow Polymer2's custom style (the document-level styling) and Angular's component-level stylings work together. |
|
You can still define and use your own mixins with this workaround method. Change html {
--my-word-wrapping: {
overflow-wrap: break-word;
word-wrap: break-word;
-ms-word-wrap: break-word;
word-break: break-word;
-ms-word-break: break-word;
}
}to html {
--my-word-wrapping_-_overflow-wrap: break-word;
--my-word-wrapping_-_word-wrap: break-word;
--my-word-wrapping_-_-ms-word-wrap: break-word;
--my-word-wrapping_-_word-break: break-word;
--my-word-wrapping_-_-ms-word-break: break-word;
}That is what ShadyCSS will convert your mixin to. The only problem (that's now fixed) is that Angular isn't allowing ShadyCSS to get to that point. There's nothing about Origami that does or doesn't support mixins. Angular does not support CSS mixins. All I've done is added a hack to force Angular to accept them so that developers don't have to use the above workaround.
|
|
@hotforfeature Thank you for explaining. |
|
It is not a bug, it's how ShadyCSS works. That specific issue is actually about the class name Everything you mentioned in your comment is working as intended. |
|
@hotforfeature Ok, thanks. Then is there any way to prevent ShadyCSS adding |
|
Chrome natively supports Shadow DOM while Firefox and Edge do not. Scoping isn't a feature you'd want to disable, it's very important in what ShadyCSS is doing. If something isn't styling properly, it's quite likely that your style rules are not using Shadow DOM correctly. Take a look at https://github.com/webcomponents/shadycss#about-scopingshim for a deeper explanation into what ShadyCSS is doing. |
|
@hotforfeature Got it. So basically Polymer's new custom-style and ShadeCSS aim to scope styles and prevent them leaking into the shadow trees of other components for the browsers with native support of Shadow DOM v1. Right? However, I asked a way to remove style-scoping So finally, in order to make app work fine on the browsers without native support of Shadow DOM, shall we style elements while caring for Many thanks for your support so far in a timely manner. |
|
This really isn't new, it's been a core concept about Shadow DOM: view encapsulation. Previously, Polymer 1.x had ways to break through this encapsulation, such as Take the following markup: <div class="blue">
<my-element>
#shadow-root
<div class="red"></div>
</my-element>
</div>Shadow DOM v1 means there is no possible way for you to break my element's shadow root and style my div. This used to be possible with v0, but not anymore. Say you have this document-level CSS: my-element .red {
background: blue;
}ShadyCSS would turn this into my-element:not(.style-scope) .red {
background: blue;
}On Chrome, if you removed <div class="blue">
<my-element class="style-scope">
<div class="red"></div>
</my-element>
</div>We don't have a native Shadow DOM, so we're emulating it. Now if you removed What you're wanting to do will break styling on browsers that do not support native Shadow DOM, not fix it. This isn't a feature to turn off or disable, this is Shadow DOM. If something isn't styling properly because of Shadow DOM encapsulation and you're trying to fix it, you may be approaching document-wide styling the wrong way when using web components. tl;dr;We're talking very abstract though, and maybe there's just miscommunication. If you have a project repo or plunker you want to share highlighting the specific problem, I'd be happy to take a look at it. There may be a correct solution to your problem that doesn't involve trying to break through Shadow DOM. |
|
@hotforfeature It seems that we're saying on different topics, it's not your fault. I think I have mixed up various things together and that must have confused you. I am sorry for that. Anyway I have been totally trying to mention scoping and styling with Angular and Polymer. I mentioned custom-style and ShadeCSS in the late comment, because Before I enter the topic, I'd like to make sure I have the same point of ShadowDOM v1 spec and support of it with you. (If something wrong, please correct me first.)
Let's come back to the main topic. <!-- #eg1 -->
<my-component>
#sharow-root
<style>
:host {...}
.title {...}
my-element-inner {...}
</style>
<div class="title">...</title>
<my-element-inner>...</my-element-inner>
</my-component>This is how <!-- #eg2 -->
<head>
...
<style scope="my-component">
my-component {...}
.title.my-component {...}
my-element-inner.my-component {...}
</style>
...
<head>
...
<my-component>
<div class="title my-component">...</title>
<my-element-inner class="my-component">...</my-element-inner>
</my-component>You see there is no I think we should carefully focus on how Angular renders component and how Let's say that Did you catch my idea? I am sorry, but in my poor opinion, origami doesn't work properly as a bridge between Angular 4 and Polymer 2. And I am wondering if I should open a new issue for this ...
Please feel free to share your feedback of my poor thought. Further I want to get your short guide to use <!-- document-level styling -->
<!-- :not(.style-scope) is appended to all selectors here after ShadeCSS handles -->
<custom-style>
<style>
* {
font-family: ...; /* globally used font */
...
}
body {
margin: ...;
line-height: ...;
min-height: ...;
background-color: #fbfbfb;
}
/* more global CSS and css variables and mixins that will be applied through all elements */
html {
--a-css-variable-for-Polymer-or-other-web-components: ...;
--a-css-mixin-for-Polymer-or-other-web-components: {
...
}
--a-css-variable-for-custom-Angular-components: ...;
--a-css-mixin-for-custom-Angular-components: {
...
}
}
.def-btn {
/* will apply for buttons like as <paper-button class="def-btn" ... */
}
</style>
</custom-style>What is the best way to implement this architecture? Hope to get your recommendation for it. Thank you for leaving feedback. |
|
You are still talking very much in the abstract. We could go back and forth for quite a while, but I don't think that is the best use of our time. The TL;DR; response is that Origami registers all of Angular's styles with ShadyCSS (by wrapping them in Can you link your project's repository, or a sample repo that reproduces the problem? Once you have that, explain which styles are not working correctly on Chrome and Firefox, and what you expect the result to be. I'll then go through it and see if I can figure out what the problem is. |
|
@hotforfeature Excuse me, but could you read out the last comment? I am implying something there. Yes, I am talking in the abstract, but I wrote there what I think of origami and what I wish origami does. Thank you. |
|
@First87 I spent an hour drafting a full response before I realized that we were getting nowhere just by talking. We need to get our hands into code to see the problems. I did read your comment fully. ShadyCSS and Angular's style scoping do not conflict with each other. I do not believe there would be any benefit in using ShadyCSS's It is also impossible to use CSS custom properties and mixins in Angular without ShadyCSS. This is the reason I chose to wrap all styles with When writing a Polymer component, you don't have to use Angular components are the same as web components. They're emulated by default, but that is what they're modeled after. If I have overlooked something, I'd be glad to fix it. However, I don't see from your samples any issue that would cause conflict. This is why I'm asking for a project. Once we have our hands on code we can run it in the browser and see where the gaps are. |
|
@hotforfeature Sorry for no update for days. Just opened another issue and moved to it: #33. |
According to the Custom Style guide,
CustomStyleServiceworks fine on custom css variables, but it doesn't work for mixin objects.Here is an example:
With
CustomStyleServiceadopted, the component style is correctly wrapped with<custom-style>element, butpaper-textareagets compiled incorrectly. It gets transpiled in the following (captured by Chrome Inspector):As given above,
--paper-input-container-colorand the next@applydisappeared, they appear and work correctly as our expectation once I comment out--paper-input-container-input.However, if I move
paper-textareastyles into the document-level styling, all work fine, this is somewhat weird.Hopefully get help to solve this problem!
The text was updated successfully, but these errors were encountered: