Don't CSS reset img and svg width and height

[justinwolfe]

Problem/Feature

The CSS reset seems to be working great and didn't break anything.....jk 😅 😹 ! Here's what the Messages blank slate looked like for a little while (now fixed):

The CSS reset blew things up because the height and width got passed as props to the Image component, which means that they're set as attribute properties directly on the image. i.e. this

  function renderExampleMessageImage() {
    return (
      <Fragment>
        <ExampleMessageImageUI
          height="412"
          src={getImagePath('example-message.png')}
          title="Example Message"
          width="315"
        />
      </Fragment>
    )
  }

Renders as this HTML:

<img height="412" src="http://localhost:9020/images/messages/blank-slate/example-message.png" title="Example Message" width="315" data-cy="Image" class="Imagecss__ImageUI-egra31-0 eSUNsm c-Image sc-fzpjYC fOXZih">

Because width and height attributes in images and iframes have (thanks for the link @Charca) the weakest specificity of all, that meant that the reset was resetting them to initial, letting them balloon in size 🚫 !

This was an issue that @ryan-mulrooney noticed in Message and a few other places in hs-app when QAing the original reset PR and led to adding the cssReset prop to toggle it on and only doing so in hs-app-ui and not hs-app...which works great except we didn't totally connect the dots that Messages is in hs-app-ui now so the prop didn't prevent this case from happening.

Solution

There was an easy immediate fix for this particular case that @jakubjanczyk took, which was just to move the width and height declarations out of props passed to the component and into CSS rules in the Styled Component (since the SC class specificity would be higher then and the issue wouldn't happen).

So we're okay now, but @Charca noted:

for the future, I'm wondering whether we could not reset width and height for elements that could take a presentational attribute (img, iframe, svg, etc) to prevent cases like this one? Although now that we're using the css reset, cases like this one will be much more obvious in the future, so we probably don't have to worry too much about it.

That makes sense to me, so this PR makes that change!

Guidelines

Make sure the pull request:

• [ ] Follows the established folder/file structure
• [ ] Adds unit tests
• [ ] If it is a refactor or change to an existing component, have you verified it won't break existing Cypress tests or have you updated them?
• [ ] Did you verify some accessibility (a11y) basics?
• [ ] Adds/updates stories. Guidelines
• [ ] Adds/updates documentation (ie proptypes) Guidelines
• [ ] Has it been tested in Help Scout's supported browsers?
• [ ] Requests review from designer of the feature
• [ ] Add label (bug? feature?)