This is a weird test case but if you've got Stylelint in your editor and
you're working on changing files, I've found that after typing "var("
(and my editor adding the closing ")"), the theme_colors rule tries to
run against this and fails as it expects the var() to contain a variable.
So if we do detect var(), we just do nothing and wait for the user to
actually fill it in.
Bug: chromium:1152736
Change-Id: Id78fa4f7b05a1107e609bd7b0cde5c0f4bbbc8e7
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2896898
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL fixes the fact that the stylelint rule wouldn't deal with:
```
border-bottom: var(--foo) solid var(--color-details-hairline)
```
It does this via a naive regex that splits the border value into its
three pieces, and then only lints the final declaration, which is the
color.
Bug: 1198504
Change-Id: I409adaf8b8777112ce4f3b24f0a6f63bd7435c25
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2823831
Auto-Submit: Jack Franklin <jacktfranklin@chromium.org>
Commit-Queue: Paul Lewis <aerotwist@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
It seems there is no requirement for these files to be split; they don't
seem to have a logical split and they are both injected into the `body`
element when DevTools runs. If we kept both of these files around, we'd
have to inject them both into the component docs helpers, and deal with
both of them when it comes to figuring out where legacy CSS variables
are defined.
To make it a bit simpler I've merged `inspectorStyle` into
`inspectorCommon`. I went this way because:
* `inspectorCommon.css` is (I think!) a better name than `inspectorStyle.css`
* `inspectorCommon.css` was bigger.
I also drive-by disabled the stylelint `comment-empty-line-before`,
which was forbidding empty lines before any CSS comments; which made the
entire file feel very squashed!
Bug: none
Change-Id: Ifaa834c7bf56291561e2e5cc124c4efd85c3cc56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2716285
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
This CL turns on the use_theme_colors stylelint rule which enforces that
any colors use variables defined in our codebase.
There are many, many violations, unsurprisingly (about 1500), so for now
I have disabled every single violation. The goal of the dark mode
migration will be in part to remove all violations of this rule.
Additionally, new code going forwards should adhere to the rule and not
add the comment to disable the warning.
Bug: 1152736
Change-Id: I51372724ea51485daef3d4f75b7d3f60a7c8016f
No-Presubmit: true
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2671323
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
This introduces the `use_theme_colors` Stylelint plugin which checks
that all colors used in our codebase use the CSS variables defined in
either themeColors.css or inspectorStyle.css. Long term we will remove
inspectorStyle.css but for now it's not going anywhere.
It does this by looking at certain rules and seeing if there are any
colors defined in them. If there are, it errors unless those use
variables that are defined.
It also can be run in fix mode, where it disables the rule for that
given line. This is important as we have 100s of violations of this rule
at the moment, and it's going to take time to get us to a place where we
do not.
It also will allow violations in a
:host-context(.-theme-with-dark-background) block as those will normally
be using specific colors to override (although this is discouraged).
Bug: chromium:1152736
Change-Id: I79281ba931ad94f76216ee1f4c8fd0406cf0c304
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2667199
Commit-Queue: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Kriti Sapra