[Bug] -webkit-appearance: none breaks embedded form styling

[rootwork]

I confirm:

• I am running the extended version of Hugo version 0.91.0 or above to build my site.
• I have read the Hugo Clarity theme documentation.
• I have used the example site's config files as reference.
• I have reviewed other issues in this repository and mine is not recorded.

Hugo version

hugo v0.100.2-d25cb2943fd94ecf781412aeff9682d5dc62e284+extended linux/amd64 BuildDate=2022-06-08T10:25:57Z VendorInfo=gohugoio

Where is this bug showing up?

In the browser: Hugo builds the site, but something doesn't look right.

Operating system

Linux Mint 20.3

Browser (if applicable)

Firefox 105.0.1

Current behavior

This line in the base Sass file sets every element to -webkit-appearance: none.

I'm not sure what that was included for (it's been there since the beginning), but it renders all form fields mysteriously invisible. It took me awhile to track it down because it was waaaaay down at the bottom of the style cascade on the inspector. I only noticed this issue because I tried embedding an email newsletter signup form, and checkboxes weren't showing up.

Expected behavior

Checkboxes and other form fields should show up as normal when an end-user tries embedding them in a post or customizing a layout template.

Given that it affects checkboxes, maybe it was for the light/mode-switch implementation? Regardless, whatever it was meant for it should be applied more specifically to those elements, not across every element in the DOM.

Steps to reproduce

Spin up the example site, open content/about.md and enter something like this in the body content:

<input type="checkbox" name="test" value="test" checked>
<input type="checkbox" name="test2" value="test">

When the page re-renders you'll see some margins for the checkboxes, but the elements themselves will be invisible. (They are there in the DOM if you inspect it.)

Unchecking -webkit-appearance: none will cause them to appear -- though they're tiny, and I can't tell what in the CSS is causing that. If you add a height/width or min-height/min-width to them then they'll behave as normal.

Related code

https://github.com/chipzoller/hugo-clarity/blame/master/assets/sass/_base.sass#L3

Other information

@onweru Do you know what elements that line of CSS was meant to affect?

[onweru]

@rootwork, appearance: none helps standardize how input elements look across browsers, especially on safari. I think it had something to do with the search field. https://css-tricks.com/almanac/properties/a/appearance/

[rootwork]

That makes sense. So I can think of two options:

• Applying it directly to the fields it makes a difference on (the search fields, and others if any)
• Applying it only to <input> elements that are not type=checkbox (or probably radio also)

[onweru]

@rootwork, I agree ... either of those approaches is good.