UI: Add proxy icons to proxy services and instances where appropriate #5463
Conversation
| @@ -79,6 +80,15 @@ | |||
| margin-top: -10px; | |||
| background-color: $color-transparent; | |||
| } | |||
| %with-proxy::before { | |||
| @extend %pseudo-icon; | |||
| background-image: url('data:image/svg+xml;charset=UTF-8,<svg width="18" height="18" xmlns="http://www.w3.org/2000/svg"><g fill-rule="nonzero" fill="none"><path d="M2.242 7.138l6.963.774a1 1 0 0 1 .883.883l.774 6.963a1 1 0 0 1-1.104 1.104l-6.963-.774a1 1 0 0 1-.883-.883l-.774-6.963a1 1 0 0 1 1.104-1.104z" stroke="%23BAC1CC" fill="%23FAFBFC"/><path d="M5.242 4.138l6.963.774a1 1 0 0 1 .883.883l.774 6.963a1 1 0 0 1-1.104 1.104l-6.963-.774a1 1 0 0 1-.883-.883l-.774-6.963a1 1 0 0 1 1.104-1.104z" stroke="%238E96A3" fill="%238E96A3"/><path d="M8.242 1.138l6.963.774a1 1 0 0 1 .883.883l.774 6.963a1 1 0 0 1-1.104 1.104l-6.963-.774a1 1 0 0 1-.883-.883l-.774-6.963a1 1 0 0 1 1.104-1.104z" stroke="%23BAC1CC" fill="%23FAFBFC"/></g></svg>'); | |||
There was a problem hiding this comment.
This works fine, but it's a little gnarly having to account for the # encoding whenever adding an svg. Other UIs use ember-inline-svg to help treat svgs like svgs. ember-svg-jar is also popular.
Granted these are slightly different, since they put the svg in the DOM, but that also makes it possible to style the svg dynamically.
There was a problem hiding this comment.
Those are good options. If we were inlining SVGs into HTML I'd definitely use one of those, but given we're using inline CSS we can’t use them here.
| text-indent: -9000px !important; | ||
| width: 24px; | ||
| margin-top: -8px; | ||
| transform: scale(0.7); |
There was a problem hiding this comment.
The scale here is a little odd. Is this because the SVG is too large? Why not set the width lower?
There was a problem hiding this comment.
The scale means I can change the scale of the entire icon in one line, otherwise I'd have to change the width/heights of 2 things in 2 selectors, the gray background which is CSS and the icon itself which is pseudo content, plus the size of the border radius. That would probably be about 10 lines of code as opposed to 1. Plus scale does what it says on the tin, and just seemed easier. Is there any reason why not to use scale here?
There was a problem hiding this comment.
I don't think there's a reason not to aside from it being unexpected (with the expected thing being width/height) and maybe a "wtf" down the road if things don't line up and the transform: scale gets overlooked.
Not strong arguments and your reasoning is good, just thought I'd ask.
|
Yeah the vertical alignment is weird, I thought the same! I wasn't sure what to do as we don't have designs with this combination of icons. I did tweak external-source icon down a bit so the text and source icon was on the same baseline:
But I kind of stopped there as I know these external-source icons are changing so figured it was pointless playing with it as the next change here will be those new icons, hopefully before the next release. I decided not to do that change in this PR to keep it separate, but pretty soon they'll all look like this:
They all have the same gray box ^, so its more obvious how they line up. If we don't have time to do the new icons before next release, then I can shout @opihana to do me a quick mockup of how this should be aligned and we can do that pre-release instead. I'm gonna merge this now, but thanks for the review! |
This PR adds new proxy icons to services with the
Kind: connect-proxyIn Service listing views:
in Service detail/Instance listing views:
and Instance detail views:
An extra note here, the 'external service' icons will be changing to use a similar grey rounded box background and move to Type column in listing views. These icons will therefore move to use the new
%type-iconCSS component in a later PR.