Tag update proposal: alternateEnclosure
amcquade opened this issue · 3 comments
Currently, the specification mandates the inclusion of the "type" attribute for alternate enclosures. However, the requirement for this attribute has proven somewhat cumbersome for users when implementing the interface on our platform. In many cases, determining the MIME type from the provided URL suffices for most media types. However, challenges arise when users submit links without file extensions, IPFS files, YouTube links, livestream URLs, and similar cases.
Therefore, I propose that we reclassify the "type" attribute from required to recommended. This adjustment aims to simplify the adoption process of this tag. While obtaining the MIME type is ideal, it's not always feasible. In such instances, prompting users to ascertain this information might introduce unnecessary complexity. By making the attribute recommended rather than mandatory, we ensure a smoother and more user-friendly experience for adopting the tag.
You almost seem to be making the case for type to remain required.
Users shouldn't have to worry about the mime type, only the publishing tool should handle that.
Thank you for sharing your perspective on the matter.
We understand your concern about maintaining the "type" attribute as required, particularly to ensure that users are not burdened with determining MIME types themselves. Simplifying the user experience is indeed a priority, and we appreciate your emphasis on this aspect.
Our intention with the proposal to reclassify the "type" attribute as recommended is to strike a balance between providing guidance and avoiding unnecessary complexity for users. While we acknowledge the importance of the publishing tool handling MIME type considerations, we also recognize the practical challenges users face in certain scenarios, such as when dealing with media types lacking file extensions or originating from diverse sources.
By making the "type" attribute recommended, we aim to offer flexibility while still providing valuable guidance for those who may need it. Ultimately, our goal remains to ensure a smoother and more user-friendly experience for all stakeholders involved.
We value your input and welcome further discussion on how best to address this matter to benefit our users.
Part of the issue is the way the type field is defined and the lack of standardization around it for non-traditional types. Perhaps this stems from the fact that the alternate enclosure tag was originally intended for a use case that's slightly different than what it is increasingly being used for today, which is video platform urls. If the type is required, we should define some wider standards for it, or maybe define a different field altogether. Right now what we're seeing is apps and platforms making up their own types. For example, one platform is setting type="video/youtube" and another podcast app is expecting type="video/mp4" for youtube (neither of which are technically correct mime types for what is actually a page url). This is going to make adoption by app developers much more difficult in the future if these kind of types are not defined/standardized in some way.