Run & review this pull request in StackBlitz Codeflow.

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

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.

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.

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?

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.

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.

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.

closed as draft