Re: [client-hints] new v1 spec draft and src-N interop

On Sat, Nov 2, 2013 at 1:14 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> On Fri, Nov 1, 2013 at 9:32 PM, Darrel O'Pry <darrel.opry@imagescale.co>wrote:
>
>> How could this version of Client Hints be implemented if src-n isn't
>> adopted or another client spec were to be introduced? How would CH-RW be
>> calculated in that case?
>>
>
> src-N is not a requirement, it just makes it easier because it asks you to
> specify image widths with respect to the viewport size. If that information
> is not available, then the value is not available until layout is done -
> for obvious reasons, this is suboptimal. I am, in large part, counting on
> src-N... if that doesn't pan out, then we can revisit the RW hint.
>

Makes sense for getting things done. and I totally agree about the power of
DPR. I think another awesome hint might indicate whether the viewport is
resizable or fixed.. mobile/tablet/kiosk vs desktop/windowing comes to
mind. For fixed sized viewports, it seems like having the viewport width
and/or height becomes more useful. Which aren't dependent on waiting on
layout or src-N.


> (In the meantime, we still have the full power of CH-DPR...)
>
> These thoughts came to mind thinking of elements without src-N attributes,
>> such as /video/source[@src], /iframe[@src], /script[@source], etc. Will
>> CH-RW be applicable to these elements or is src-N expected to be a wider
>> ranging practice to replace src in general?
>>
>
> No, I don't believe src-N is reaching any further than img (nor should
> it). Arguably, it would great to have a RW hint on video, but same
> challenge.. need to wait for layout, which may, or may not be acceptable.
> IFrames get even more tricky.. And elements that don't have a display width
> (e.g. script) should arguably be omitted altogether.
>

While images are the primary motivator for this particular community. These
specifications affect the internet at large and a much wider audience than
our image focused community. I think it's only fair to consider how the
pattern could be applied to other problems.

Video is one candidate. A number of the arguments for an against <picture>
are applicable to seeing video move to a src-N style implementation. The
usability arguments of multiple source tags vs  src-n. Why should there be
two approaches for solving the same problem, why should I have to change my
way of thinking when implementing video.

IFrame could utilize src-n for Advertising and HTML widgets use cases where
knowing the size of the container would allow serving content that is
UX/design optimized to the available presentation space,  such as
interactive ads or charting/functional widget interfaces to external
services in client side applications and dashboards.

Script and it's ilk without display width could arguably receive the width
of their parent elements as hints. This way the JS or CSS for a particular
UX based on display context could be loaded in a more declarative manner,
potentially eliminating some of code which needs to be loaded for a
specific device or environment.

-- 
Darrel O'Pry, engineer
ImageScale.co, Images for the Responsive Web
http://imagescale.co/#join <http://www.spry-group.com/>