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

On Sat, Nov 2, 2013 at 11:30 AM, Darrel O'Pry <darrel.opry@imagescale.co>wrote:

> 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.
>

Before we go down this path.. I'd love to see some data showing how
frequently viewports get resized to begin with. It's not at all clear to me
that this distinction is meaningful.

>
> (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.
>

Sure, and fwiw, I encourage you to engage whatwg on this topic. :-)


> 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.
>

I understand your point, but personally, I think that's unlikely - that
ship has sailed. That said, let's first get src-N adopted, and then we can
revisit how / if it makes sense to reconcile the different approaches.


> 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.
>

There is also MQ's...


> 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.
>

Hmm, interesting... Need to think some more about this.

ig