Works fine in most browsers accept...
OS X 10.7.5 - Firefox 30.0 + Safari 6.1.5
Here is the HTML:
<input id="fileupload" type="file" name="files[]" data-url="/do/upload_my_files" accept=".pdf,.docx,.doc,.xls,.xlsx,.txt,.csv,.ppt,.pptx,.zip,.rar,.psd,.txt,.pps,image/*" multiple>
It shows only images available to select, all other files are greyed out.
The HTML 4.01 specification allows only media types (MIME types) in the content of an accept attribute. HTML5 extends this with notations like .pdf. Browsers that do not support the latter see your attribute just as accept="image/*">. Thus, add the media types (when available) such as application/pdf to the list, primarily using the authoritative media type list by IANA. If this does not help, you are probably out of luck and should perhaps remove the attribute, if the browsers that don’t cope with it are important enough.
I had this same issue and found that while Safari will not accept the comma-separated extensions, you can actually use the previously mentioned IANA list to address most types, including MS Office files (which is what I needed):
.doc/.docx: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xls/.xlsx: application/vnd.openxmlformats-officedocument.wordprocessingml.document
.ppt/.pptx: application/vnd.openxmlformats-officedocument.presentationml.presentation
It is working for me in both Chrome and Safari (6+). The IANA list doesn't make it easy to find what you need, but there is a handy list at freeformatter.com that tells you exactly what to use for each extension.
Related
Here's a very weird bug that occurs in Safari 15.3 and 15.4 (macOS) but not in any other browser.
If I have the following element:
<input type="file" accept=".json,.cbor">
I can select any .cbor file.
However, if I do:
<input type="file" accept=".json,.jpg,.cbor">
Safari shows a 'tempImageXXXXX.jpg' name and does not select the actual file.
This only happens for .cbor files in our test, but I assume it might have something to do with unknown mime types? .wav, .json, .jpeg, .mp4, etc. all have no issues. Also no other browser has any issues with this. Re-ordering the extensions in the element neither.
To replicate: just rename a txt file to .cbor and paste the code above into jsfiddle.
try using this:
<input type="file" accept="application/json,image/jpg,.cbor" />
if that did not work fine, try changing .cbor with text/plain
The actual answer is that Webkit (the web engine behind Safari) is converting images when an image mime-type is listed in the accept tag of an HTML element. This has been introduced with the following change in Webkit and it is used in their example to transform HEIC images into JPEG on the fly when an image is drag and dropped from the Photos app.
However, at Ocus, we discovered a bug linked to this change. For some mime-types (which I haven't been able to list) the name of the file is changed to tempImageXXXXX. The OP's fix worked because they used image/* instead of a specific image mime-type in the accept field.
So, the real fix is the above bug.
What you can do meanwhile is use:
<input type="file" accept="application/json,image/*,.cbor" />
You can check for specific image mime-type by plugging into the input's events.
I would like to upload a image using safari on ipad
here is my html code
<input type="file" accept="image/*">
When i try to select a file, safari prompt me to choose "take photo" or "select existed file", how can i disable the "take photo" options, and just select an existing file?
I also look up w3c document, and try codes below, but not work
<input type="file" accept="image/*" capture="filesystem">
According to this HTML5 compatibility comparator, Safari supports only partially the media capture feature: it complies with the accept attribute but ignores the catpure attribute.
So I am afraid you will have to wait for a better support from Safari before it works the way you want...
What's more, according to the W3C specifications:
When the capture attribute is specified, the user agent SHOULD invoke a file picker of the specific capture control type.
The keyword SHOULD means that Safari can choose not to follow the recommendation for some reason and still claim to be compliant with the standard...
When I try to load a PDF Data URI into an iframe (eg, src="data:application/pdf;base64,...") in FireFox (18.0.2 [current release], OSX) it instead opens a download window.
For an example, check out the website JSPDF.com
The same site works fine in Aurora (20.0a2)
Is this a known issue with Firefox? Is it not conforming to the spec...?
Aurora has a built-in PDF renderer that can render PDFs inline.
Current release as of yesterday does not have that; it first appears in Firefox 19, which is about to be released.
A browser without a PDF plug-in or built-in PDF renderer will simply offer to download or open in a helper app a PDF that's loaded in a window as you're doing, which is exactly what you see.
As far as the spec goes, both behaviors are compliant. Nothing says a browser needs to support inline rendering of PDF.
You need to modify the options :
To :
I had a very similar problem with Firefox, iframes and data URIs. I resolved it by checking that there was no spaces in the data type definition. Mine was text/html, so instead of writing this:
src="data: text/html, ..."
it had to go like this:
src="data:text/html,..."
I conclude that firefox didn't understand the content type with spaces, thus considering it was a downloadable file.
This might be caused when there is no adobe reader installed. I'm not sure though. As I can't test it here as I don't have a Mac with Firefox running.
Oh, what frustration. The supposedly XHTML-complient CKEditor can't actually be served as application/xhtml+xml, so I have to switch to text/html. Suddenly my pages start breaking all over the place.
I serve a well-formed HTML5 document that uses namespaces---in particular, the "example" namespace. Some elements have the "example:fooBar" attribute, but I see now that Chrome when reading a document as text/html converts all attributes to lowercase---grrr!!!
So I change the attribute to "example:foobar" and try element.getAttributeNS("http://example.com/ns", "foobar"). No luck. So I investigate the DOM, and Chrome 17 shows a "localName" of example:foobar. Ack! How hard can namespaces be? Shouldn't Chrome be using a local name of foobar? That is, after all, the local name; example is the namespace prefix!
Is this is Chrome bug? Do all browsers do screwy things like this?
I came across a browse file dialog-control tag in html and the tag was
<input id="myfile" name="myfile" type="file" accept="application/pdf"/>
but the 'accept' attribute doesn't seems to have any effect. I am using Internet Explorer 8.
according to the w3schools (http://www.w3schools.com/TAGS/att_input_accept.asp), the 'accept' attribute is not properly supported by any of the major browsers. The filter inside the file browser dialog will not work.
You could use a javascript validation on the form onsubmit event to verify if the file type is correct, returning false otherwise.
It seems like browsers have trouble following the IANA specifications found here:
http://www.iana.org/assignments/media-types/media-types.xhtml
In my case, the application/pkcs* media types don't work at all, while for some reason application/x-pkcs12 works in chrome and partially(.p12) in IE. Firefox seems completely oblivious.
I also found this more optimistic discussion over here. File input 'accept' attribute - is it useful?
So, the best description would be "probably unsupported for uncommon formats", and with the x-pkcs vs pkcs confusion more or less unusable in my case.
Delimiter
I can confirm in some modern browsers that if you want the file dialog types to appear you need to use a comma as a delimiter:
<input accept="image/apng, image/jpeg, image/png" name="example" type="file" />