Skip to main content

Customization 'accept' attribute values of file input in upload widget.

Andrei

Hey. I have a use case of uploading video files using the upload widget.
I limit the uploaded files to videos using resourceType parameter which adds validation.

Browse button in the upload widget is file input.

<input type="file" name="file" class="cloudinary_fileupload">

When it is clicked on mobile (for example on iOS) it provides the following options: Take Photo or Video, Photo Library and Browse. HTML5 input allows accept attribute to control those options. In my case, it would limit options to Take Video, Photo Library, and Browse if I had specified the following accept parameter accept="video/*".

<input type="file" name="file" class="cloudinary_fileupload" accept="video/*" />

Is there a way to control attributes of Browse file input in the upload widget?

2

Comments

14 comments

Date Votes
  • Aditi Madan

    Hi Andrei,

    You can use the `clientAllowedFormats` option in the upload widget and specify the video formats and that way it will only let the user upload video files. If you try and invoke the widget through input element it will eventually open the widget disregarding the accept parameter and the button element does not support accept type. You can either use resourceType or clientAllowedFormats.

    Regards,

    Aditi

     

    0
  • Andrei

    Aditi, thanks for your suggestion.
    We're using `resourceType` video when configuring the upload widget and I was trying the `clientAllowedFormats` option as well. It is limiting uploading however it is used by API for validation.

    It would be nice to have an option to control the `accept` option on file input. In addition to the existing options for Look and feel customization it would improve UX.
    Any chance of having an additional parameter for this purpose in the future?

    As an example, such parameter could support a comma-separated list of allowed file extensions or MIME types and be directly bind to input (Browse button)

    0
  • Aditi Madan

    Hi Andrei,

    I will raise a feature request with our product team to consider adding this in the future. As of now, we have the options that I shared earlier with you.

    Regards,
    Aditi

    1
  • Ed

    Has there been any progress on this? Seems basic to improve the UX of the this section

    0
  • Eyal Katz Talmon

    Hey Ed! Thanks for reaching out.

    The feature request is still being considered and prioritized against other tasks, and therefore, unfortunately, there wasn't any progress made so far. We'll update this thread about any progress made in the future.

    Regards,

    Eyal

    1
  • Ed

    Just adding to this. Is there any way I could get access to the input from a query selector? So far it seems not possible due to the iframe being from a different origin. Or is there a way to get the widget codebase so I can make the changes myself?

    0
  • Michal Kuperman

    Hi Ed,

    Currently, there is no option to access the input from a query selector or to get the widget codebase. 

    Let us know if you need any further assistance.

    0
  • Aditi Madan

    Hi Andrei and Ed,

    I just wanted to let you know that this issue is fixed now. You should be able to use the `accept` attribute with the upload widget.

    Please test and let me know if you have any questions.

    Regards,

    Aditi

    1
  • Kirill

    Hi Aditi,

    Could you elaborate on where we can use the `accept` attribute?

    Moreover, in accordance to docs(and your answer above), we can use `clientAllowedFormats`
    Here is the description:

    Allows client-side validation of the uploaded files based on their file extensions. You can specify one or more file extensions, and/or limit the allowed files to "videos" or "images".
    Note: As a shortcut, you can use a string to pass a single value (e.g. "gif")
    Default: null.
    Example: ["webp", "gif", "videos"]

    But when

    ['image/*', 'video/*']

    or 

    ['images', 'videos']
    <input type="file" name="file" class="cloudinary_fileupload" accept=".image/*,.video/*" tabindex="-1" multiple="multiple">

    As you can see somewhere internally a dot is added to all array elements. It is confusing.
    In order to specify all images/videos, we have to define all formats.

    Could you help with that?

    0
  • Eyal Katz Talmon

    Hey Kirill, thanks for reaching out!

    It seems that the syntax mentioned in the documentation is incorrect here.
    The correct syntax is using singular notation -

    clientAllowedFormats: ['image', 'video']

    This generates the following accept attribute for the input element -

    accept="image/*,video/*"

    I'll create an internal ticket for the documentation team to fix this section.

    Hope this helps!

    0
  • Kirill

    Thank you Eyal Katz Talmon!

    What about `audio`? I've tried 

    clientAllowedFormats: ['image', 'video', 'audio', 'raw']

    Output is 

    accept="image/*,video/*,.audio,raw/*"
    0
  • Stephen Doyle

    Hi Kirill,

    In our feature set, audio files are considered "videos" for the purposes of identifying which transformation options can be used with them, and this parameter is parsed based on our resource type values of 'image', 'video', 'raw'.

    I can see that doesn't match what you need here, which is for the 'accept' property to include an audio/* MIME type.

    It may be possible for us to add a special 'audio' option here or to also add audio/* when the 'video' value is provided and I've created a task for our widgets team for that.

    In the short term for audio files I think the best workaround is to list the specific formats via their file extensions (e.g. aac, mp3, wav, etc)

    Thanks,

    Stephen

    0
  • Kirill
    Edited

    Hi Stephen,

    Thank you for your response.

    A special 'audio' option here seems to be the best option. Since as a user, I want to control what exact types input can accept(maybe just audio).

    Anyway, thank you!

    Kirill

    0
  • Stephen Doyle

    Hi Kirill,

    I've linked the task I created for the widget team with this forum thread, so we can let you know if any changes are made to address this, and in the short term I think listing the specific audio formats you want to support should represent a workaround for most cases

    Regards,

    Stephen

    0

Post is closed for comments.

Didn't find what you were looking for?

New post