Skip to content

Conversation

@guywillis
Copy link
Contributor

@guywillis guywillis commented Jan 25, 2024

Fixes: #469

New

Note

The following has been implemented to prevent any breaking changes:

  • Deprecated color variables left in for legacy support only (with comments). All new color variables inherit from existing color variables for backwards compatibilty.
  • Deprecated .notify-btn-icon mixin left in for legacy support only (with comments). New .ui-btn-ctrl provided as fallback for backwards compatibilty.
  • New color mixins applied to deprecated .btn-text and .btn-icon selectors for legacy support only (with comments).

Summary

kirsty-hames and others added 30 commits January 11, 2024 16:23
- focus state inherits from hover (as per existing component focus styles)
- existing @visited vars are only used by components so grouped with content item
- focus state inherits from hover (as per existing focus styles)
- locked state inherits from disabled (as per existing locked styles)
- Replace @btn-ui-color vars with @ui-color vars. Nav, Notify and Drawer btns inherit from their view colours. This sets an extra level of vars to define global ui colors or edit these separately as per existing Vanilla.
- rename _buttonStates.less file to _state-mixins.less.
- ui-btn-controls vars added
- shared Notify and Drawer btn styles combined into single ui-btn--controls mixin. Replacing .notify-btn-icon mixin.
- set menu item btn vars to inherit from item ui
- item ui locked state added
- set .narrative__strapline-icon to inherit from narrative__strapline-btn to reduce additional state declaration styles
… controls and strapline

- Narrative strapline icon background color set to transparent to prevent icon background obscuring the btn focus outline
- border-radius added
- default drawer item vars represent current drawer styles
- margin gives option to display items in a 'button style'
- when margin is set, apply border to whole of button (not just bottom)
- drawer item selected state expanded to support aria-current="true" (used by languagepicker which should inherit selected, not disabled styling.
Copy link
Contributor

@kirsty-hames kirsty-hames left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating schemas @guywillis. All looking good. I've just added a few text amends.

@swashbuck
Copy link
Contributor

Hi, @guywillis . This is looking great. Thanks for the hard work. I have a few comments/questions below.

  1. For disabled outline style buttons, I think I would prefer just a lighter border instead of a filled background. I do like the filled style on hover/focus, though.
Outline
  1. In the Less filenames, I think the 'i' should be capitalized in 'UI' since it is an acronym. Ex: _drawerUIStyles.less not _drawerUiStyles.less. Microsoft says "When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io." I'm sure you could find sources that disagree, of course.
  2. core/questionButton.less - "button" should come first like core/buttonQuestion.less. This is similar to the notify/notifyPush and drawer/drawerItem Less files and would keep these button files together.
  3. btn-color-outline(): Why use a box shadow and not an actual border? I get why we should not use outline since that should be reserved for focus states.
  4. This may be out of scope, but I do not like that some variable names include "color" (ex. @menu-item-btn-color-hover) while others do not (ex. @progress-border). Without including "color" or something similar (ex. "bg-color"), it's unclear what the variable is for. For instance, @progress-border could define the border width or the entire border shorthand style.

Otherwise, great work!

@guywillis
Copy link
Contributor Author

Hey @swashbuck, thank you for your comments and feedback.

  1. For disabled outline style buttons, I think I would prefer just a lighter border instead of a filled background. I do like the filled style on hover/focus, though.

I agree, I think I would prefer this visual too. Our initial reasoning for keeping the filled disabled buttons for the outline style were two fold:

  1. It provides a very clear visual indication that the button is disabled, especially in contrast to an active outline style button.
  2. It provides simplicity in the Vanilla theme Less.

I would not be adverse to changing this but having experimented with mimicking this change in others button areas it looks weaker to me than the filled version.

Item

Filled Outline
item-filled item-outline

Item UI

Filled Outline
itemUi-filled itemUi-outline

Notify UI

Filled Outline
notifyUi-filled notifyUi-outline
  1. In the Less filenames, I think the 'i' should be capitalized in 'UI' since it is an acronym. Ex: _drawerUIStyles.less not _drawerUiStyles.less. Microsoft says "When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io." I'm sure you could find sources that disagree, of course.

I am not against such a change, it makes sense.

Reflecting upon the names of the files _itemStyles.less, _btnStyles.less etc, I think we can actually drop the Styles part and instead rename the folder from _buttonMixins to _buttonStyles

  1. core/questionButton.less - "button" should come first like core/buttonQuestion.less. This is similar to the notify/notifyPush and drawer/drawerItem Less files and would keep these button files together.

This change makes a lot of sense, I am in favour.

  1. btn-color-outline(): Why use a box shadow and not an actual border? I get why we should not use outline since that should be reserved for focus states.

Predominantly, I prefer box shadow over border as it's more flexible:

  • box shadow doesn't affect the elements width or height
  • it can be applied outside the dimensions of the element as well as the inside
  • it can support multiple values at once
  1. This may be out of scope, but I do not like that some variable names include "color" (ex. @menu-item-btn-color-hover) while others do not (ex. @progress-border). Without including "color" or something similar (ex. "bg-color"), it's unclear what the variable is for. For instance, @progress-border could define the border width or the entire border shorthand style.

I am in agreement here. It should be consistent and flow together. I think it would be best if we addressed this as a separate issue.

@swashbuck
Copy link
Contributor

Thanks, @guywillis . I agree with all your points. Fine with leaving the disabled outline styles as is. Should be simple enough to change in a custom theme.

@kirsty-hames
Copy link
Contributor

Hi @guywillis / @swashbuck, I've had a read through all comments above and I'm in agreement. I just have one preference regarding the following,

Reflecting upon the names of the files _itemStyles.less, _btnStyles.less etc, I think we can actually drop the Styles part and instead rename the folder from _buttonMixins to _buttonStyles

I agree with dropping 'Styles' from the files but think it makes sense to keep the folder as _buttonMixins. As these files contain mixins only. 'Styles' is always a given with CSS anyway :)

Copy link
Contributor

@swashbuck swashbuck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@oliverfoster
Copy link
Member

We need one more +1 here from a non-kineo. 3 weeks outstanding.

@joe-allen-89 joe-allen-89 merged commit dbb53be into master Mar 31, 2025
@joe-allen-89 joe-allen-89 deleted the issue/469 branch March 31, 2025 20:33
@github-project-automation github-project-automation bot moved this from Needs Reviewing to Recently Released in adapt_framework: The TODO Board Mar 31, 2025
github-actions bot pushed a commit that referenced this pull request Mar 31, 2025
# [9.25.0](v9.24.2...v9.25.0) (2025-03-31)

### New

* Adapt buttons overhaul (fixes #469) (#490) ([dbb53be](dbb53be)), closes [#469](#469) [#490](#490)
@github-actions
Copy link

🎉 This PR is included in version 9.25.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Adapt Buttons - Vanilla issue Replace hardcoded icon button border-radius with variable

7 participants