32251 Updated banner styling #862
Conversation
- updated banner styling
severinbeauvais
requested review from
davemck513,
hfekete,
mengdong19,
ozamani9gh,
rarmitag and
stevenc987
as code owners
There was a problem hiding this comment.
Pull request overview
Updates the top-of-app alert banner presentation to match new styling requirements and bumps the UI version.
Changes:
- Reworks the App-level banner markup to include a custom icon + container layout.
- Adds new SCSS rules targeting the banner element and removes the prior generic v-alert wrapper styling.
- Increments the app version to 5.8.9.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| app/src/App.vue | Updates banner structure and adds new banner-specific styling. |
| app/package.json | Bumps application version to 5.8.9. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
app/src/App.vue
Outdated
| mdi-information | ||
| </v-icon> | ||
|
|
||
| <span |
There was a problem hiding this comment.
bannerText comes from a LaunchDarkly feature flag and is injected as raw HTML. Wrapping it in a <span> constrains the injected markup to inline-only content; if the flag ever includes block-level tags (eg <p>, <div>, <ul>), this will produce invalid HTML and browsers will reflow/reparent nodes in unpredictable ways. Consider using a block element (eg <div>) for the v-html target, or explicitly restricting/sanitizing the flag content to inline markup only.
| <span | |
| <div |
There was a problem hiding this comment.
The current implementation is consistent across UIs. No change recommended.
There was a problem hiding this comment.
I changed my mind and updated the other UIs. CP is right -- div is more flexible, and due to the use of flexbox, is correctly aligned, etc.
|
/gcbrun |
|
Temporary Url for review: https://namerequest-dev--pr-862-60styfc2.web.app SB says, try the above link and compare with: |
| } | ||
| } | ||
|
|
||
| #alert-banner { |
There was a problem hiding this comment.
I would prefer this be a class over depending on ID for any new styles. Can we do that ?
ID has higher specificity and and when overriding styles with IDs we need to use !important. If we are overriding classes, then it works as you would expect, last class applied wins.
There was a problem hiding this comment.
The built-in styles are pretty specific for alerts so I would have needed to concatenate several classes to target this exact component (and use !important).
So I used id instead of class to not risk setting styles for other alert components. Only this component needs these styles.
There was a problem hiding this comment.
OK, I wont argue against it this time, but lets have it for the future. As this will compound the need for !important. And now we will need specifically all the styles to target this ID with !important to be able to override e.g. the color of dark-gray-links inside alert.
Thanks
|
/gcbrun |
|
Temporary Url for review: https://namerequest-dev--pr-862-60styfc2.web.app |
3 participants
Issue #: bcgov/entity#32251
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namerequest license (Apache 2.0).