Yui button inspired style

[scherler]

Testing done

• .jenkins-button--outline
  
• .jenkins-button--outline (on hover)

Proposed changelog entries

• human-readable text

Proposed upgrade guidelines

N/A

Submitter checklist

Preview Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[janfaracik]

Heyo. The existing classes for Button should work for your primary/destructive use cases - see https://weekly.ci.jenkins.io/design-library/Buttons/

e.g. jenkins-button jenkins-button--primary jenkins-!-destructive-color and jenkins-button jenkins-button--primary jenkins-!-success-color

You'd want to add an 'outline' modifier though for the 'Analyse now' button, e.g. jenkins-button jenkins-button--outline unless the default button styling could work instead?

[scherler]

@janfaracik makes a lot of sense and thanks for pointing it out (I will follow up with a sample in the design-lib) I renamed the outline example

[scherler]

jenkinsci/design-library-plugin#360

[janfaracik]

--btn-* vars are deprecated (YUI only), would just use var(--text-color) if it needs to be set.

[janfaracik]

These props could be inherited from the base jenkins-button class.

[scherler]

Well but the original yui outline button had been bold, but if you want we can change it but IMHO it makes more sense bold.

vs

[janfaracik]

This wouldn't work if paired with colour modifiers. We've been using currentColor in our other button modifiers to inherit the colour from modifiers.

[scherler]

hmm are you sure

however I added jenkins-button--outline[class*="color"]

[scherler]

jenkins-button jenkins-button--outline jenkins-!-success-color

:hover

[scherler]

6188712

[janfaracik]

Heya, I'm travelling today but I'll take a look as soon as I can :)

[scherler]

good traveling and MCAAHNY

[janfaracik]

Thanks, hope you had a good time too :)

.jenkins-button--outline {
  color: var(--color, var(--text-color-secondary)) !important;
  --button-background--hover: color-mix(in srgb, var(--color, var(--text-color-secondary)) 15%, transparent);
  --button-background--active: color-mix(in srgb, var(--color, var(--text-color-secondary)) 20%, transparent);
  --button-box-shadow--focus: color-mix(in srgb, var(--color, var(--text-color-secondary)) 10%, transparent);

  &::before {
    background: transparent;
    border: 2px solid var(--color, var(--text-color-secondary));
    opacity: 1 !important;
  }

  &:hover {
    &::before {
      background: var(--button-background--hover) !important;
    }
  }

  &:active {
    &::before {
      background: var(--button-background--active) !important;
    }
  }
}

.jenkins-button[class*="color"] {
  background: transparent;
  color: var(--color) !important;

  &::before {
    --button-background: currentColor; // changed this
    opacity: 0.1;
  }

How is something like this? The buttons styling is a little confusing (and more complex than it needs to be as modern CSS wasn't available when it was originally written, I do wanna tidy up this file)

I’m not totally sure about adding an outline button to core - I feel our default/secondary style already covers the same ground. Any thoughts on using it as a local class, using a prefix like {plugin-name}- instead of jenkins-?

Any thoughts @jenkinsci/sig-ux ?

[A1exKH]

@scherler LGTM.

[krisstern]

I’m not totally sure about adding an outline button to core - I feel our default/secondary style already covers the same ground. Any thoughts on using it as a local class, using a prefix like {plugin-name}- instead of jenkins-?

I tend to agree that we should use the outline button as a local class instead of core.

[uhafner]

I’m not totally sure about adding an outline button to core - I feel our default/secondary style already covers the same ground. Any thoughts on using it as a local class, using a prefix like {plugin-name}- instead of jenkins-?

I tend to agree that we should use the outline button as a local class instead of core.

I also think that having too many styling options will confuse plugin authors and users. I think all existing styles have a semantic meaning now (default, secondary, destructive), and if the new style has no semantic meaning then we should not add it.

What is the reason for adding this new style? Or why does one of the existing buttons do not work? In jenkinsci/warnings-ng-plugin#1912 we also replaced the deprecated outlined YUI button with the Jenkins secondary button style which works quire well.