New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LPS-136427 Move Some Custom Properties to Clay CSS #1277
Conversation
Please only forward critical changes to Brian Chan during stabilization. Nonurgent changes should wait until the ongoing 7.4 DXP EP3 & CE GA3 release has been completed. For more details on the release timeline and status, see product-delivery. |
CI is automatically triggering the following test suites:
|
ci:stop |
❌ ci:test:sf - 0 out of 1 jobs passed in 5 minutesClick here for more details.Base Branch:Branch Name: master Sender Branch:Branch Name: custom-properties 1 Failed Jobs:For more details click here.
|
Jenkins Build:test-portal-source-format#5089 Jenkins Report:jenkins-report.html Jenkins Suite:sf Pull Request:liferay-frontend#1277 Testray Routine:EE Pull Request Testray Importer:publish-testray-report#1967 |
Jenkins Build:test-portal-acceptance-pullrequest(master)#5028 Jenkins Report:jenkins-report.html Jenkins Suite:relevant Pull Request:liferay-frontend#1277 Testray Routine:EE Pull Request Testray Build:[master] ci:test:relevant - pat270 > liferay-frontend - PR#1277 - 2021-07-22[16:00:07] Testray Importer:publish-testray-report#1544 |
@marcoscv-work , @edalgrin comment plz |
I'm taking a look 👀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code seems really good (I'm going to try it, in the portal, later), just a couple of questions
- Couldn't we remove the variables that we don't need for the custom properties?
- Is the
!default
flag necessary?
Apart from that, I would love to be able to select just 1 color as primary
and automatically obtain primary-d1
, primary-d2
, etc (or in this case: hover, focus, active). It's something they required for Stylebook but could get. With the current system is not possible because we are using SASS (preprocessor) to get those, ideally we should switch to HSL colors that allow calculations through custom-properties (example) but it requires a redefinitions of the colors and probably a sort of standardization: use the same amount of lighten or darken among all the colors (5.1 != 5)
--blockquote-font-size: #{$font-size-base} * 1.25; | ||
--blockquote-small-color: #{$gray-600}; | ||
--blockquote-small-font-size: #{$small-font-size}; | ||
--blockquote-font-size: #{getDefault($blockquote-font-size)}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are already providing a fallback in the custom properties declarations I think we don't need to redefine all these (👇 ) custom properties, they aren't' used anywhere (that's one of the changes I wanted to to in the layer edalgrin#121)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if it's not needed we can remove them.
$border-color: #f1f2f5; | ||
$bright-color: #1865fb; | ||
$complementary-color: #30313f; | ||
$dark-color: #272833; | ||
$input-bg: #f1f2f5; | ||
$light-color: #e7e7ed; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember taking a look at these and finding out that they were useless improvable, maybe we aren't use use them anymore or we can use the clay variable instead of new ones. I wanted to review these on the upcoming epic https://issues.liferay.com/browse/LPS-134071 but since we are here..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed here brianchandotcom@6df096f (we just need to rebase this PR)
it looks very promising |
Just started reviewing :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing the change in the portal it works wonderfully! 😄
There is a problem with the .rounded
class that used $border-radius
and it's defined in the Stylebook.
By the way, we have a widget to test these (although we don't have buttons in there 🤔)
Apart from the previous comments and this new one 👆, it seems almost ready! Perhaps we should add the custom properties for Dialect (padding, font, etc..) and wait/ask for what might be useful to others team/project as well? (lol, commerce, forms)
This doesn't translate well for all colors in real life. Just look at the differences in the lightness values of Lexicon's (https://liferay.design/lexicon/foundations/color/) color palette. Primary, Secondary, Light, and Error aren't consistently stepped. We can't automagically provide this. Stylebooks also seem like it should be a general way to customize, meaning we should support all valid CSS color values. |
@edalgrin Thanks, I wish I knew about this widget. |
Well, this looks very interesting and promising, I have some concerns about how much it can grow when I include variables for other components. In the end they are APIs that we will have to maintain for the long term. |
I was talking with @emiliano-cicero and he was working on a similar concept https://www.figma.com/file/wWYQHFoBnCxTjKKnYta19I/Color-palette-for-illustrations, perhaps we could make it compatible with Lexicon? |
Hello everyone, all this looks really exciting. The illustration palettes concept was an exercise designed to work on images with a great visual richness but not intended to be applied to the product with constraints such as accessibility. About creating a color palette for Lexicon, we could develop a way to check color pairings' contrast accessibility. At the same time, each color would be consistently stepped in each palette gradient. Some time ago, I worked on a project where we studied a model to create palettes based on the magic number, creating color palettes that comply with contrast accessibility. We created several palettes with values between 0 (white) and 100 (black) depending on their luminance value to get the contrast ratio with a simple subtract operation of a pair of colors values. A magic number of 40+ ensures a contrast ratio of 3+ You can see more about the process in this video where we presented the color patterns building model. Regarding the scalability that @matuzalemsteles talks about, I have added a high-level description of the process and some reference sources in the Lexicon Design Tokens Research document. Among all, I believe that Amazon Style Dictionary is the standard that has achieved a scalable model that can also be applied to our tokenization model, but please tell me what you think about it. Thanks. |
@hold-shift it's a good job alias, I've seen some of these libs implementing the Design Tokens idea or spreading this idea I see that the big benefit of it really is offering configurations for multiple platforms. One of the concerns is how we balance the use of global tokens with component-specific tokens, for example the definition of the new Button component, we have some component-specific tokens that could be related to the global ones.
How would we be doing this balance to use global tokens instead of adding component-specific tokens. Another point when I talk about is the granularity of specific tokens for the component, for example:
Could these tokens escape the definition? probably they are the key piece to allow Dialect to create its own components, but would that be deviating from that and looking at Dialect's Figma could it repeat for other components? My concern is more with how we scale this granularity, we will probably know more when we have the analysis of the other components. I've added a few more info about it, in case you're interested liferay/clay#4174 I liked the idea of versioning and status for tokens, these are good things to keep track of like we try to do in React components, we don't have the test definition but it would be great before committing to it for the long term. |
background-color: var(--btn-primary-background-color, $primary), | ||
border-color: var(--btn-primary-border-color, $primary), | ||
box-shadow: $c-unset, | ||
color: var(--btn-primary-color, color-yiq($primary)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In these cases we shouldn't use --primary
token instead of creating a component-specific one, it seems a bit inconsistent, for example in theory btn-primary
would follow the colors of primary
, as well as subsequent ones, with would that allow you to change the color of btn-primary
without following the global color of --primary
, in which case wouldn't it be a bit contradictory? And if the user wants a different color for the button, wouldn't it be a new variation?
Bootstrap 5 has a function based on luminance that outputs What if I want to shift left or right (e.g., my primary button to be yellow / black on active)? There's nothing in the magic number equation that will do that for me. It just tells me if two colors satisfy a contrast ratio. It doesn't pick the color I want. This is the main reason we shouldn't implement this. It adds tons of complexity for no real benefit. |
ci:test:relevant |
Jenkins Build:test-portal-acceptance-pullrequest(master)#32 Jenkins Report:jenkins-report.html Jenkins Suite:relevant Pull Request:liferay-frontend#1277 Testray Routine:EE Pull Request Testray Build:[master] ci:test:relevant - pat270 > liferay-frontend - PR#1277 - 2021-07-31[02:07:56] Testray Importer:publish-testray-report#101 |
let's break everything then :D |
ci:forward |
CI is automatically triggering the following test suites:
The pull request will automatically be forwarded to the user
|
Skipping previously passed test suites: |
✔️ ci:test:sf - 1 out of 1 jobs passed in 2 minutesClick here for more details.Base Branch:Branch Name: master Sender Branch:Branch Name: custom-properties 1 Successful Jobs:For more details click here. |
All required test suite(s) passed. |
Pull request has been successfully forwarded to brianchandotcom#104983 |
Jenkins Build:test-portal-source-format#23 Jenkins Report:jenkins-report.html Jenkins Suite:sf Pull Request:liferay-frontend#1277 Testray Routine:EE Pull Request Testray Importer:publish-testray-report#112 |
Not sure we wanted to add custom properties outside the custom properties folder 😬 https://github.com/liferay-frontend/liferay-portal/pull/1277/files#diff-07100ecd816943034e37b0128d4cc5364467959e487dec90db72c6eea3164106L1-R25 |
@edalgrin what's the reason for we wanted to add custom properties outside the custom properties folder? |
https://issues.liferay.com/browse/LPS-136427
Hey @marcoscv-work @edalgrin @nhpatt @dsanz @matuzalemsteles @drakonux ,
I was able to move a lot of the custom properties to Clay CSS. Some places that are giving me trouble is:
It's due to Bootstrap functions and mixins. I need to update those, but didn't have enough time today to figure out a work around. Anyway take a look and tell me what you think.
Edit: I've cleaned the custom properties implementation up a lot. I believe we can get rid of the
custom_properties
directory and bake it directly into Classic Theme. Some things that need to be updated besides the two points above:#wrapper
:can we change this to replace the custom property inside
:root
? We don't need to try and scope CSS this way anymore with Cadmin.initial
and resetting the property back to its default.#wrapper
anymore and just usebody
. I can update Clay CSS so we can customizefont-size
in thebody
tag better.--hr-border-color
called Separation Border Color in Stylebook? It's so hard to make the connection between that label and the variable name.Here is some markup you can toss into a fragment for testing: