Remove unrealistic font-size from import-button

[pmario]

This PR fixes #8167

• [Bug] Import-button creates a probably unnecessary huge DOM element #8167

It removes unrealistic font-size from import-button -- Edge on Windows 3D-view shows it as fixed.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[github-actions]

Confirmed: pmario has already signed the Contributor License Agreement (see contributing.md)

[Jermolene]

Hi @pmario as I said on the original ticket, those 999px dimensions were not a mistake. At the time that we introduced the browse widget, it was a standard CSS technique for styling file input controls. I can't find my original source, but there are many examples like this.

Therefore, if we're going to remove those large dimensions we need to understand which browsers are impacted.

[pmario]

I made this PR a draft

---

Therefore, if we're going to remove those large dimensions we need to understand which browsers are impacted.

IMO it's not a browser problem, but a hack for image-buttons. According to StackOverflow's first answer it will allow a thumbnail button to be used to trigger a file-browser using the full thumbnail size.

In our usecase we create a fake button and then add the $browse-widget -- The size of the input type=file is adjusted by CSS

So for modern browsers we would only need this CSS: (after some brief testing)

.tc-file-input-wrapper input[type=file] {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	height: 100%;
	max-width: 100%;
	max-height: 100%;
	opacity: 0;
	outline: none;
	background: white;
	cursor: pointer;
	display: inline-block;
}

This construction is still hacky, but it should automatically adjust the input to the size of the parent-element. And it would eliminate the giant DOM element, which is the purpose of this PR.

The problem with outline: none is -- It causes an accessibility problem. -- The whole fake button is an accessibility problem if used with keyboard navigation. eg:

• The fake button is outlined "on focus", but does not open the import dialogue if activated
• using the TAB-key to focus the next dom element
• The input-element is hidden and has no outline, but does trigger the import dialogue - if you know what you do.

Luckily screen readers do see the invisible - input type=file button. -- BUT they also see the fake button which has no functionality.

I am not sure about background: white since the element is invisible anyway.

---

So the question is: Do we want to fix that?

The original construction dates back to 2013 and it is an accessibility problem. So I think we should fix it.

[Leilei332]

Since the browse widget already supports the class attribute, would it be possible to remove the fake button and style the browse widget to look like a button?

[Jermolene]

Hi @pmario @Leilei332 I am in favour of fixing the accessibility problem.

@Leilei332's suggestion is a good one if it works widely – I remember that it didn't used to be possible, but that was quite a few years ago.

[pmario]

Since the browse widget already supports the class attribute, would it be possible to remove the fake button and style the browse widget to look like a button?

The browse-widget has no class parameter. See: https://tiddlywiki.com/#BrowseWidget
It basically creates a single DOM element: <input type=file/>. That's it.

There is a hack for a reason. The visual representation of that button is "browser native" and basically impossible to style using standard CSS rules.

[pmario]

Also see: https://developer.mozilla.org/en-US/docs/Web/API/File_API/Using_files_from_web_applications#using_hidden_file_input_elements_using_the_click_method -- Where they describe the mechanism everyone seems to use for the "unstyleable" input-element.

It seems we would need to change the browse-widget in a way, that it allows us to use a BUTTON-ID, or a HTML LABEL element, that looks like a button.

This may fix the accessibility problem. ... not sure ... more experiments would be needed.