Reflecting matched media #1

Closed
marcoscaceres opened this Issue Oct 12, 2012 · 7 comments

Comments

Projects
None yet
4 participants
Owner

marcoscaceres commented Oct 12, 2012

We need to define the use cases (if any) for returning media that matched the selection of an image.
That is:

var resimg = $("#myresimg"); 
//which media matches 
if(resimg.media .... ){
  // 
}

We have the option to either return a string or a MediaList. We need to investigate which one we want to use.

var resimg = $("#myresimg"); 
//which media matches 
if(resimg.mediaText === "screen"){
  // 
}

Media lists are cool because they have the following:

[Constructor(DOMString text)]
interface MediaList {
    stringifier attribute DOMString mediaText;
    readonly attribute unsigned long length;
    DOMString item (unsigned long index);
    void appendMedium (DOMString medium);
    void deleteMedium (DOMString medium);
};
Owner

yoavweiss commented Apr 7, 2013

Anyone has a use-case for a dev to know which media matched the source that was loaded inside picture (not to be confused with the matching source's src attribute)?

Member

anselmh commented Apr 7, 2013

Isn't that needed for every JS MQ based image manipulation? Use case could be an image editor for example…

Owner

yoavweiss commented Apr 7, 2013

Can you please describe why would a dev need the matched media in this case (rather than simply the loaded resource's URL). I'm not sure I get why it is necessary.

Bare in mind that given the loaded resource and the internal DOM of picture, finding the matched media in JS is simple (even if cumbersome). So if the use-case is marginal, it may not worth spending much time on it at this point facilitating it (which doesn't mean an easier way can't be added later on)

Member

anselmh commented Apr 7, 2013

You're totally right here, @yoavweiss, it may not be worth it. So forget about my use case and let's see if someone else has some.

Owner

marcoscaceres commented Apr 7, 2013

I agree with @yoavweiss also. We should do bare minimum to address our documented use cases and then extend if we need to.

Member

nwtn commented May 1, 2013

Nobody has come forward with other use cases. Are we ok to close this and go with @yoavweiss and @marcoscaceres's conclusions?

Owner

yoavweiss commented May 1, 2013

I'm cool with closing this issue. @marcoscaceres, if you agree, close away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment