rewrite so it works without media.js about picture

[knightdr]

First, how would the implementation be easier? I'm trying to get at if it's generally difficult to implement or because of multiple file dependencies.

Second, if you want a version without media.js, picturefill is the other option I know of. I know you've created a demo using that as well. I would say speed is the biggest difference. In performance tests, picture was faster, in part that speed is due to Media.parseMatch's ability to parse media queries.

Is there something you like about picture that you don't about picturefill and vise versa or are both implementations lacking?

Let me know how I can help.

[attiks]

The 'problem' is that there's already a poly fill for matchmedia in Drupal 8 core, so if we add this picture solution to core we need to rewrite a lot of other core code, and that will be hard to defend.

The thing I like about this solution is that images are only loaded once.

The other solution is to rewrite media.js as well so it uses the same interface as matchmedia, but I have to think some more about this :-)

[knightdr]

"rewrite media.js as well so it uses the same interface as matchmedia"
See line 255 of media.js window.matchMedia || (window.matchMedia = Media.match);

media.js already supports the native matchMedia interface. Unlike matchMedia.js, media.js supports addListener like the spec does (triggered on match and unmatch) and on resize mql.matches will change from true to false and vise versa as native does.

Addition:
@WickyNilliams has created a pull request that would fix the match/unmatch scenario paulirish/matchMedia.js#28

[attiks]

I'll try to have a look at the code tomorrow, it's getting late over here.

[knightdr]

Ok, thanks for hanging in there. I appreciate you trying to make this work.

[WickyNilliams]

Yeah, @knightdr has already been very accommodating to an earlier request of mine to match (no pun intended) the matchMedia API :)

I've not looked into the this particular project yet so correct me if I'm off the mark... From an outsider's perspective I think it should just rely on the matchMedia API rather than any specific implementation of it (in this case media-match). That way, any polyfill can fit the bill, and the end consumer is given the power to decide which (if any!) polyfill to utilise.

[knightdr]

Hmm. You and your thoughts @WickyNilliams.

You're making some sense. Your sense will require me to do a little re-think on how picture (https://github.com/weblinc/img-srcset and https://github.com/weblinc/nonresponsive) is currently implemented. I'm using Media.parseMatch because it can return the media query it matched on. I'm using the query as the property name where the value is the src of the img to load. It also bypasses the need to store the query list object in an array like Media.match does.

[attiks]

@WickyNilliams that's what I meant
@knightdr I think it would be possible to split media.js in 2 parts, one the polyfill and a new one that extends matchMedia with the features and parseMatch so it can still be used by picture.js

[knightdr]

@attiks
I guess I was being simple when thinking that the performance increase would be enough of a reason to switch from other polyfills. Looking over the jsPerf, media.js is 700+ times faster than matchMedia.js. When looking at devices with slower processors it's 1,000+ times faster.

So when I created the other plugins, again my thought was "wow, this is way faster and it's used in picture, img-srcset and nonresponsive". Basically eliminating the need to choose because it's so much faster. Since, media.js supports the native API, I didn't see an issue.

I don't see how media.js could be split but I'm open to talking about it.

[WickyNilliams]

@attiks apologies, I was concurring with your sentiment and adding some further reasoning.

@knightdr I have a lot of thoughts, most of them crap, but I think this one was worthwhile :)

As for your reasoning above, I think the end consumer should still have the decision. Some people may favour file size (the classic polyfill) over speed (your polyfill) and it's ultimately something that you should not dictate by inclusion. Others may not even care about polyfilling older browsers, another reason why it should be an optional include rather than a hardcoded dependency. I spent a long time thinking about this with enquire, which is why I did not include any polyfill in the codebase, leaving the decision the user.

[knightdr]

@WickyNilliams

I guess this is why I'm paying you the big bucks, these thoughts.

The only reason I personally would want to continue development on "picture" is if it added something to the community. If I follow your argument down the path as I see it then I would come to the conclusion that I should focus my efforts on forking picturefill.js rather than this project. If I add matchMedia into picture then it's really a slight difference from picturefill.js. Currently I see this project as more of a departure even though they both strive to achieve the same end.

[knightdr]

@WickyNilliams @attiks

What do you think of "picture" becoming a plugin to Media? So it could be Media.picture to show that these efforts are linked and then I think it's less of an issue that "picture" uses Media specific implementation. Too much fragmentation of picture like functionality? I would then see if I could improve picturefill.js performance.

[knightdr]

@WickyNilliams @attiks ,
I've just released v2.0.0 of this project. Thought you would be interested. I've removed the dependencies as we discussed. This version is different enough and performant enough at the moment to be a separate repo from picturefill.js. If this performs well, maybe it can be folded in to picturefill or at least share some of the concepts. After all, picturefill has a much greater awareness.

I'm closing this one out now.

[WickyNilliams]

I'll check this out when I have some time (tomorrow most likely). Thanks for the update David

[knightdr]

Fantastic Nick, I appreciate any feedback. Same hourly as before, right? ;)