Re: [mediaqueries] Media Source Extensions and device capabilities

On Tue, Sep 23, 2014 at 12:10 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Tue, Sep 23, 2014 at 9:22 AM, Mark Watson <watsonm@netflix.com> wrote:
> > Hi Tab,
> >
> > I am not really a CSS expert, so that is why I posted the underlying
> > requirement without presuming a CSS solution.
> >
> > But, naively, I would think that if we had a "device pixels" unit (dpx)
> > corresponding to physical device pixels, we could construct a media query
> > along the lines of "min-height: 1080dpx". This could be used to annotate
> a
> > <source> element on an HTMLMediaElement or with window.mediaMatch() to
> > obtain events as the window is moved to / from displays with HD
> resolution.
>
> A combination of 'width'/'height' and 'resolution' MQs would
> accomplish this, if necessary.
>

​Frequently, one might not know the pixel density ('resolution' in MQ
terms) or the width/heigh in physical dimensions, but would know the actual
resolution in physical pixels - or at least a lower bound on that. For
example, when sending output over HDMI.

Is it possible to construct a query that matches ( <height> * <pixel
density> ) >= 1080 ?


>
> > Likewise, one could imagine, "min-audio-channels: 6", although as per the
> > previous discussion of this there are some details to work out as to
> exactly
> > what is meant by "audio channel" here. As with video, the requirement is
> to
> > avoid *where possible* delivering media which is just going to be
> down-mixed
> > or down-scaled. So, for audio, the "min-audio-channels: 6" might fail to
> > match only if the UA knows for sure that 6-channel audio will be
> down-mixed.
>
> Right, this is the sort of thing that sounds reasonable.  What I meant
> in my request is seeing what kind of <video> markup might be used if
> such a MQ existed.
>

​Did my example above answer that ? I am more interested in the script
case, since in our application the media to be played is chosen by JS and
fed into ​Media Source Extension.

...Mark



>
> ~TJ
>

Received on Tuesday, 4 November 2014 20:32:48 UTC