Thoughts on adding a type attribute
Matt Wilcox brought this idea up a few months ago, but the issue seemed to fall off the table and was lost in other discussions. It’s something I’d like to see get some more feedback and general discussion from other developers so I’m bringing it back up. Below are some thoughts I’ve put together for adding a type attribute to source tags in the picture element.
- A type attribute would allow for a native HTML way to use new image formats, which could help decrease the load of image assets, increase site performance, i.e. WebP, JPEG-XR.
- The type attribute could also be a starting point for responsive image formats. As an example, a user could specify a new responsive image format which streams its data per however that magic would work and if the new responsive image format is not supported in the browser, it could fallback to the next image in the source stack, depending on which media query is active in the source list.
- The idea of fallback images is something that is being worked on in CSS: http://dev.w3.org/csswg/css4-images/#image-notation
- Since the picture element markup is very similar to the HTML5 video element, it seems to just make sense to also include type attributes just like the video element.
- I’m curious if type could be an optional attribute and only needed if you are planning to use newer image formats that would need a fallback pattern. This would be ideal so developers don’t have to specify type=”image/jpg” or type=”image/png” on each source tag
- Adding a type attribute seems like a very future friendly and forward thinking action.
Here is a gist of this concept: https://gist.github.com/3410238
Adding the type attribute to source tags in the picture element seems to be beneficial with no apparent drawbacks. I’m sure there are some issues so feel free to let me know what your concerns and issues/drawbacks are of adding a type attribute.
It’s great to see this discussion being brought up again, the more we can discuss these kind of approaches the better solution we will end up with.
If the idea around adding a type attribute was for a new type of image format wouldn’t we be better off looking at it from the .appcache approach?
Rather than specify a type within the element this is done on the server or, at a stretch, in a .htaccess file.
The type attribute might has to be added indeed but this should only happen if browser vendors need this to decide if the support format. It would be much easier not to use the type attribute.
So I’d wait what the WHATWG members and UA vendors say to that issue. Thanks for remembering us 🙂
Like Justin said, normally this should come out of server config file (htaccess or nginx-conf…).
I think it would be useful from the fallback angle. Without it, browsers that don’t support any new image types will fallback to the image specified in the img tag. It would be good if we could specify fallbacks for when newer image types aren’t supported for each breakpoint we define rather than a one size fits all fallback, though we could have a “fallback fallback” as well.
As I understand it, the actual spec would rely on the the existing definition of the source element instead of defining a new element.
The existing source element contains the type attribute; therefore, the source element within picture would also contain type.
At least, that would be the initial approach subject to feedback and refinement.
The CSS4 image() proposal doesn’t include type information – so it presumably it infers it from the extension (dangerous maybe), could the same approach not be used here?
HTML5 has dropped the type attribute from script and CSS so why bring it back?
Also I seem to remember reading somewhere the video element may change.
It looks like type is included in this W3C editors draft.
@Justin @Anselm – True, I know I’ve set the MIME type in an .htaccess file before when using . Though I think a native way to do this in just HTML will be great. I agree that type would only need to be added to the source element if the developer is using something other than a standard image formats, jpg, gif, png…
@James – Yeah, this is the main reason I’m thinking the type attribute would be used for. It would be a great catalyst for supporting new image types like WebP, and JPEG-XR.
@Andy – While the type attribute seems to be disappearing from HTML, it could add a lot of benefit to picture in helping making it a future friendly html element. Josh Emerson wrote a while back on how he was trying to display SVG images. Josh came up with a pretty cool solution, though I feel like the type attribute used with the source elements in picture could fix the issue he was having altogether and make supporting new image formats with fallbacks really easy.
Brett, surely it should be an option as it is now in editors draft. 🙂 A website should also work without server-side technology.
Without requiring browsers to parse the type attribute (if present), and skip sources they can’t decode, we’re blocking future improvements to responsive images.
I am in favor of modifying the img element. There is clearly a need and the picture element is too similar for my liking. I’m also in favor of a new image format supported by a new type attribute.