You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mallard uses the mime attribute in two places: media and code blocks. Using a MIME type to specify the content type seems natural, but in practice it's hard to remember the right MIME type. This is especially true in code blocks, where there's not a registered MIME type for many languages. People just have to look up the x- MIME types that Yelp happens to understand.
For code blocks, it would be better to use a simple identifier like "c", "javascript", or "xml". That's what code highlighter libraries use anyway. And if we put that in a type attribute, we can take advantage of Ducktype's shorthand for type attributes, e.g.:
We could even support multiple values in the type attribute. Space-separated type attributes isn't unprecendented in Mallard. This can help you match different values accepted by different tools, or provide more specific values with fallback, e.g.:
<code type="xslt xml">
Or in Ducktype:
[code xslt xml]
For media elements, the type attribute is already in use, and works well for what it does. Specifying the actual type is less frequently used in this case, although it's important for application-type media elements. Maybe we just keep the mime attribute for that. Or maybe we let media type be a space-separated list, where the first comes from the controlled list of "image", "video", "audio", and "application". Or maybe some other syntax.
The text was updated successfully, but these errors were encountered:
We handled the mime attribute on code in Issue #38. I've just opened Issue #55 for the media element. I'm closing this in favor of the element-specific issues.
Mallard uses the mime attribute in two places: media and code blocks. Using a MIME type to specify the content type seems natural, but in practice it's hard to remember the right MIME type. This is especially true in code blocks, where there's not a registered MIME type for many languages. People just have to look up the x- MIME types that Yelp happens to understand.
For code blocks, it would be better to use a simple identifier like "c", "javascript", or "xml". That's what code highlighter libraries use anyway. And if we put that in a type attribute, we can take advantage of Ducktype's shorthand for type attributes, e.g.:
Compare this to:
We could even support multiple values in the type attribute. Space-separated type attributes isn't unprecendented in Mallard. This can help you match different values accepted by different tools, or provide more specific values with fallback, e.g.:
Or in Ducktype:
For media elements, the type attribute is already in use, and works well for what it does. Specifying the actual type is less frequently used in this case, although it's important for application-type media elements. Maybe we just keep the mime attribute for that. Or maybe we let media type be a space-separated list, where the first comes from the controlled list of "image", "video", "audio", and "application". Or maybe some other syntax.
The text was updated successfully, but these errors were encountered: