Thanks for this post, its very interesting.
Nethertheless, I think its hard to say that 71% coverage is good enought because, to be sure this will works, we also need to cross this with the support of the <picture> element which is 81% coverage.
I know I'm too sceptical here but I'm mostly desperate to see how slow are browsers to implement W3C living standards...
The reason the <picture> syntax is structured that way is to enable progressive enhancement. If a browser does not understand how to handle <picture>, then the <img> inside is shown instead. Same with source being forward-looking for unknown formats, as the article mentions. So the fallback WebP -> Jpeg -> img with src is pretty clean ime. Nothing bad happens either way!
Evergreen browsers have been quite responsive to supporting <picture> for a few years now too :)
(The caniuse link gives me 87% percent, could it be a font issue or the "site data" setting being on?)
Ah, I meant the coverage percentage for picture, which caniuse puts at 87% and I thought the comment above said 81%.
I think if you mention the picture tag coverage, it is best to also include that it will fall back to the img tag (basically treating picture like a generic div). It is a common misconception that I see about using features, that we might avoid using them if they are not supported everywhere. In reality, they are often designed to progressively offer a better experience where supported, and picture is there in all evergreen browsers.
Mat Marquis, one of the people who worked on the spec back when it was established, goes over some of the history and progressive-enhancement decisions. The best I remember is in the ebook Image Performance, from A Book Apart. I'll see if I can find some other reference, it's a great read :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this post, its very interesting.
Nethertheless, I think its hard to say that 71% coverage is good enought because, to be sure this will works, we also need to cross this with the support of the
<picture>element which is 81% coverage.I know I'm too sceptical here but I'm mostly desperate to see how slow are browsers to implement W3C living standards...
Very well noticed! I completely not took into account the picture tag, which make this part irrelevant. Gonna rectify it thank you :)
Same feeling as you, I am very sad to see the slowness of LS in browsers...
The reason the
<picture>syntax is structured that way is to enable progressive enhancement. If a browser does not understand how to handle<picture>, then the<img>inside is shown instead. Same withsourcebeing forward-looking for unknown formats, as the article mentions. So the fallback WebP -> Jpeg -> img with src is pretty clean ime. Nothing bad happens either way!Evergreen browsers have been quite responsive to supporting
<picture>for a few years now too :)(The caniuse link gives me 87% percent, could it be a font issue or the "site data" setting being on?)
Gonna double check for caniuse filters, I tell you that right after I checked.
I did not know the browser will fallback to the img tag if the picture tag is not supported. Thank you so much for sharing.
I guess I will still mention the picture tag coverage to be clearer :)
Ah, I meant the coverage percentage for picture, which caniuse puts at 87% and I thought the comment above said 81%.
I think if you mention the picture tag coverage, it is best to also include that it will fall back to the img tag (basically treating
picturelike a genericdiv). It is a common misconception that I see about using features, that we might avoid using them if they are not supported everywhere. In reality, they are often designed to progressively offer a better experience where supported, andpictureis there in all evergreen browsers.Mat Marquis, one of the people who worked on the spec back when it was established, goes over some of the history and progressive-enhancement decisions. The best I remember is in the ebook Image Performance, from A Book Apart. I'll see if I can find some other reference, it's a great read :)