-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
report: create naming convention for css variables #9149
Conversation
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.
love that we're standardizing these thanks @hoten! 🎉 💯
@@ -15,41 +15,56 @@ | |||
* limitations under the License. | |||
*/ | |||
|
|||
/* | |||
Naming convention: |
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.
❤️
across multiple components, either create more variables or just drop the "{component}-" | ||
part of the name. Append any modifiers at the end (ex: 'big', 'dark'). | ||
|
||
For colors: --color-{type}-{hue} |
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.
seems like you mean intensity/lightness/saturation here instead of hue
, type
is currently the hue :)
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, thanks!
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 couldn't find an MD lingo for describing those tags (700
, A700
, ...)
--section-indent: 16px; | ||
--audit-item-gap: 5px; | ||
--text-indent: 8px; | ||
--footer-vertical-padding: 16px; |
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.
seems like we're a tad loose with property-name
should this be --footer-padding-vertical
according to the convention? maybe add this as a counter example to the comment if not?
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.
Yeah that makes sense. padding-vertical
isn't a property, but padding-{top,bottom}
is, and padding-vertical
follows from using the "common descriptor" rule.
--lh-audit-vpadding: 4px; | ||
--lh-audit-group-vpadding: 12px; | ||
--lh-section-vpadding: 8px; | ||
--lh-audit-vertical-padding: 4px; |
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.
same deal here with padding-vertical
vs. vertical-padding
@@ -320,7 +335,7 @@ | |||
} | |||
|
|||
.lh-audit__description, .lh-audit__stackpack { | |||
--inner-audit-right-padding: calc(var(--text-indent) + 2px); | |||
--inner-audit-right-padding: var(--stackpack-horizontal-padding); |
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.
elsewhere we used margin-right
which seemed to align with the convention, flip here too to match property name?
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.
for sure
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.
LGTM as first pass on our new naming convention!
TODOs are followups?
across multiple components, either create more variables or just drop the "{component}-" | ||
part of the name. Append any modifiers at the end (ex: 'big', 'dark'). | ||
|
||
For colors: --color-{type}-{intensity} |
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.
would probably go with {hue}
over {type}
since I'm not sure what type
means in the context of a color, I know my last comment was kinda ambiguous on that sorry!
Would like to resolve some of them here. The ones that just say also, if we don't want to prefix all vars with |
--audit-item-gap: 5px; | ||
--text-indent: 8px; | ||
--footer-padding-vertical: 16px; | ||
--audit-item-gap: 5px; /* TODO rename. */ |
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.
audit-margin-horizontal
?
--secondary-text-color: var(--color-black-800); | ||
--informative-color: var(--color-blue-900); | ||
--medium-75-gray: #757575; | ||
--medium-50-gray: hsl(210, 17%, 98%); | ||
--medium-75-gray: #757575; /* TODO rename / switch to MD */ |
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 think this is exactly --color-gray-600
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.
right you are
--medium-75-gray: #757575; | ||
--medium-50-gray: hsl(210, 17%, 98%); | ||
--medium-75-gray: #757575; /* TODO rename / switch to MD */ | ||
--medium-50-gray: hsl(210, 17%, 98%); /* TODO rename / switch to MD */ |
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.
--color-gray-50: #fafafa
instead?
--chevron-size: 12px; | ||
--inner-audit-left-padding: calc(var(--score-shape-size) + var(--score-shape-margin-left) + var(--score-shape-margin-right)); | ||
--inner-audit-left-padding: calc(var(--score-icon-size) + var(--score-icon-margin-left) + var(--score-icon-margin-right)); /* TODO: rename */ |
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.
--audit-description-padding-left
?
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 really like having this convention defined. thanks for working through it!
|
||
{intensity} is the Material Design tag - 700, A700, etc. Omit "-{intensity}" if there is only one | ||
color of that hue. | ||
*/ | ||
.lh-vars { | ||
--text-font-family: Roboto, Helvetica, Arial, sans-serif; | ||
--monospace-font-family: 'Roboto Mono', 'Menlo', 'dejavu sans mono', 'Consolas', 'Lucida Console', monospace; | ||
--body-background-color: #fff; | ||
--body-text-color: var(--color-black-900); |
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.
according to the convention, should all --body-
be --report-
now?
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.
Let's do --report-
.
.lh-vars { | ||
--text-font-family: Roboto, Helvetica, Arial, sans-serif; | ||
--monospace-font-family: 'Roboto Mono', 'Menlo', 'dejavu sans mono', 'Consolas', 'Lucida Console', monospace; | ||
--body-background-color: #fff; | ||
--body-text-color: var(--color-black-900); | ||
--body-font-size: 16px; | ||
--body-line-height: 24px; | ||
--subheader-color: hsl(206, 6%, 25%); | ||
--header-font-size: 20px; | ||
--snippet-color: hsl(206, 6%, 25%); |
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.
this probably should just adopt an existing color. seems odd to have it be off on its own
--text-indent: 8px; | ||
--footer-padding-vertical: 16px; | ||
--audit-margin-horizontal: 5px; | ||
--stackpack-padding-horizontal: 10px; | ||
--secondary-text-color: var(--color-black-800); |
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.
--color-... ? or does that only apply for the "root" colors?
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 could go either way with this. The two ways to interpret...
--secondary-text-color
, if you considersecondary-text
to be a "component"...--color-secondary-text
, because anytime you reach out for a color it's nice to just do--color
and look at autocomplete. The average / fail / etc. colors already are like this.
I'm leaning towards 2), plus expanding the color naming rule to cover these.
--medium-50-gray: hsl(210, 17%, 98%); | ||
--color-gray-600: #757575; | ||
--color-gray-50: #FAFAFA; | ||
--snippet-background-color: var(--color-gray-50); |
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.
lets just use --color-gray-50 directly?
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.
There's actually a few of the color component variables defined in this manner already:
--report-text-color: var(--color-black-900);
--informative-color: var(--color-blue-900);
--snippet-background-color: var(--color-gray-50);
--tools-icon-color: var(--color-gray-600);
--env-item-background-color: var(--color-black-100);
--plugin-badge-background-color: var(--color-white);
--topbar-background-color: var(--color-black-100);
--metrics-toggle-background-color: var(--color-black-200);
which is kinda nice because inverting the --color-
variables is all that needs to be done to do dark theming.
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.
or do you mean removing the variable --color-gray-50
and inlining the value here
--report-secondary-border-color: #ebebeb; | ||
--display-value-gray: hsl(216, 5%, 39%); | ||
--chevron-line-stroke: hsl(216, 5%, 39%); | ||
--report-width: calc(60 * var(--body-font-size)); | ||
--report-min-width: 400px; | ||
--report-header-height: 161px; |
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.
this is the only --report- prefixed item that refers to a specific component..
oh look at that.. it's actually outdated and old now. PR drafted: #9188
@@ -9,7 +9,7 @@ | |||
} | |||
|
|||
:root { | |||
--lh-background-color: #304ffe; |
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.
seems like this isn't used anymore. i think it can die.
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'm actually gonna revert it b/c I don't want to touch the viewer at all rn.
@@ -39,7 +39,7 @@ | |||
--report-text-color: var(--color-black-900); | |||
--report-font-size: 16px; | |||
--report-line-height: 24px; | |||
--snippet-color: hsl(206, 6%, 25%); | |||
--snippet-color: var(--color-black-800); |
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.
look at Background and foreground colors do not have a sufficient contrast ratio.
in the now deployment for a snippet.
a57fef5
to
8e6209a
Compare
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.
looks good, it's nice to have a system.
What to pick as the component seems like it will definitely be ambiguous at times. And without scoping, variables like --plugin-icon-size
are still just kind of out there (ideally you'd use css to scope them, but that makes overriding in different breakpoints/environments messier).
It's also somewhat BEM like, so I wonder if we should adopt the underscore/hyphen/double-hyphen conventions from there, but I also don't care either way about BEM so I'm fine with whatever :)
--color-black-900: #212121; | ||
--color-black: #000000; | ||
--color-blue: #2962FF; | ||
--color-gray-50: #FAFAFA; |
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 wonder how we started using gray
instead of grey
:)
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.
fwiw the MD sites all say gray. the correct way, coincidentally
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.
fwiw the MD sites all say gray.
ha, well the third party site in the comment above doesn't :)
the correct way, coincidentally
freedom is the only way, yeah
--color-green-700: #018642; | ||
--color-green: #0CCE6B; | ||
--color-green: #0CCE6B; /* TODO: this is not a MD color */ |
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.
/* TODO: this is not a MD color */
do we care?
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.
goood question. calling @yuinchien - should we only use colors from Material design?
For colors: --color-{hue}-{intensity} | ||
|
||
{intensity} is the Material Design tag - 700, A700, etc. Omit "-{intensity}" if there is only one | ||
color of that hue. |
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.
if this gets longer or really applies to multiple places it could go in CONTRIBUTING.md, but seems ok here now
--body-line-height: 24px; | ||
--subheader-color: hsl(206, 6%, 25%); | ||
--header-font-size: 20px; | ||
--report-background-color: #fff; |
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 these are all changing in blame anyways, does it make sense to sort these, at least grouping by component?
May want to do that at the very end, though, cause the diff will be hard to follow
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 want to wait until a completely separate PR, so it's in two commits and separates concerns in the PRs. Want to be able to follow through any changes in UIs like github's.
--env-item-padding: 10px 0px; | ||
--env-item-font-size: 28px; | ||
--env-item-line-height: 36px; | ||
--metric-description-padding: 0 0 2px calc(var(--score-icon-margin-left) + var(--score-icon-size) + var(--score-icon-margin-right)); | ||
--gauge-circle-size-big: 112px; |
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.
should these be --score-gauge-*
like the other gauge vars? Or the others should be --gauge-*
?
--score-gauge-percentage-font-size: 28px; | ||
--score-icon-margin-left: 4px; | ||
--score-icon-margin-right: 12px; | ||
--score-icon-margin: 0 var(--score-icon-margin-right) 0 var(--score-icon-margin-left); |
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.
can we pick different prefix than score for one or both of the score things since they're quite different?
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.
changed --score-gauge
to --gauge
--body-line-height: 20px; | ||
--audit-group-margin-bottom: 20px; | ||
--report-font-size: 14px; | ||
--report-line-height: 20px; | ||
--env-name-min-width: 120px; | ||
--gauge-circle-size-big: 96px; | ||
--gauge-circle-size: 72px; | ||
--header-padding: 16px 0 16px 0; | ||
--plugin-icon-size: 75%; |
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.
kebab case does present kind of a problem for parsing component vs property, but that's not new here
The only visual change should be this layout fix (see that bad chevron):
Before
After
Open to discussion. Note, I will follow up with sorting. Some stuff to start us off:
body
before, but I don't like that because places like PSI / DevTools don't provide the entire body to the report. I'm thinking eitherreport
ordefault
.lh-
?