Intent to Ship - The picture element, source children and related img source selection
242 views
Skip to first unread message
Yoav Weiss
Jul 16, 2014, 3:04:45 AM7/16/14
to blink-dev
Emails
Yoav Weiss - yo...@yoav.ws
Christian Biesinger - cbies...@chromium.org
Spec
Summary
Enable a responsive images solution for the "art direction" use case, allowing authors to provide multiple image sources, varying according to media query based breakpoints.
Motivation
The "art-direction" use case is a major use-case of the responsive images problem, and solving it would allow authors to use media queries to specify alternate image sources (or sets of sources, in concert with the `srcset` attribute) to suit their layout breakpoints and reduce bandwidth costs across a wide range of display sizes/layouts.
The picture element and it's related HTMLImageElement source selection algorithm resolve that use case in an efficient and author-friendly manner.
Compatibility Risk
Low.
The feature is a subset of the overall picture specification, which Firefox are actively working on. (Scheduled to ship in Firefox 33 AFAIK)
WebKit have shown willingness to experiment with the feature, and WebKit community members have expressed favorable opinions about it.
IE are considering the feature.
Ongoing technical constraints
None.
Link to “Intent to Implement” blink-dev discussion
Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes.
OWP launch tracking bug?
Row on feature dashboard?
Yes
Requesting approval to ship?
Yes.
Tab Atkins Jr.
Jul 21, 2014, 9:38:55 PM7/21/14
to Yoav Weiss, blink-dev
LGTM, definitely.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.
> email to blink-dev+...@chromium.org.
Eric Seidel
Jul 22, 2014, 1:31:45 PM7/22/14
to Tab Atkins Jr., Yoav Weiss, blink-dev
The API OWNERS met today and agreed this was OK to ship.
Concerns were raised about the difficulty implementing correctly APIs
like this where attributes are provided by child elements (and getting
all the cases correct of child elements coming/going, etc.). But this
API seems pretty far down the shipping train (and appears to have
broad support across browsers and developers) to revisit that
fundamental assumption.
Concerns were also raised about the stable state quiecence logic and
whether we implement it correctly:
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
But that can also be investigated (and possibly fixed) asynchronously
from shipping this feature.
Concerns were raised about the difficulty implementing correctly APIs
like this where attributes are provided by child elements (and getting
all the cases correct of child elements coming/going, etc.). But this
API seems pretty far down the shipping train (and appears to have
broad support across browsers and developers) to revisit that
fundamental assumption.
Concerns were also raised about the stable state quiecence logic and
whether we implement it correctly:
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
But that can also be investigated (and possibly fixed) asynchronously
from shipping this feature.
Christian Biesinger
Jul 22, 2014, 5:59:14 PM7/22/14
to Eric Seidel, Tab Atkins Jr., Yoav Weiss, blink-dev
On Tue, Jul 22, 2014 at 1:31 PM, Eric Seidel <ese...@chromium.org> wrote:
> Concerns were also raised about the stable state quiecence logic and
> whether we implement it correctly:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
> But that can also be investigated (and possibly fixed) asynchronously
> from shipping this feature.
Can you be more specific about the concerns? AFAIK, I implemented it correctly.
> Concerns were also raised about the stable state quiecence logic and
> whether we implement it correctly:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
> But that can also be investigated (and possibly fixed) asynchronously
> from shipping this feature.
-christian
Adam Barth
Jul 22, 2014, 6:03:14 PM7/22/14
to cbies...@google.com, ese...@chromium.org, jacka...@gmail.com, yo...@yoav.ws, blin...@chromium.org
On Tue Jul 22 2014 at 2:59:10 PM, 'Christian Biesinger' via blink-dev <blin...@chromium.org> wrote:
On Tue, Jul 22, 2014 at 1:31 PM, Eric Seidel <ese...@chromium.org> wrote:
> Concerns were also raised about the stable state quiecence logic and
> whether we implement it correctly:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
> But that can also be investigated (and possibly fixed) asynchronously
> from shipping this feature.
Can you be more specific about the concerns? AFAIK, I implemented it correctly.
I just remember there was some back and forth about the differences between microtasks and awaiting a stable state, etc. I just wanted to check up on how all that got resolved to make sure our implementation is in sync with the spec.
None of that needs to block shipping the feature. It's just something that came up in our discussion today.
Adam
>>> email to blink-dev+unsubscribe@chromium.org.
Christian Biesinger
Jul 22, 2014, 6:08:08 PM7/22/14
to Adam Barth, Eric Seidel, Tab Atkins Jr., Yoav Weiss, blink-dev
On Tue, Jul 22, 2014 at 6:03 PM, Adam Barth <aba...@chromium.org> wrote:
> On Tue Jul 22 2014 at 2:59:10 PM, 'Christian Biesinger' via blink-dev
> <blin...@chromium.org> wrote:
>>
>> On Tue, Jul 22, 2014 at 1:31 PM, Eric Seidel <ese...@chromium.org> wrote:
>> > Concerns were also raised about the stable state quiecence logic and
>> > whether we implement it correctly:
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
>> > But that can also be investigated (and possibly fixed) asynchronously
>> > from shipping this feature.
>>
>> Can you be more specific about the concerns? AFAIK, I implemented it
>> correctly.
>
>
> I just remember there was some back and forth about the differences between
> microtasks and awaiting a stable state, etc. I just wanted to check up on
> how all that got resolved to make sure our implementation is in sync with
> the spec.
>
> None of that needs to block shipping the feature. It's just something that
> came up in our discussion today.
Ah yeah, the outcome was to make stable states identical to
> On Tue Jul 22 2014 at 2:59:10 PM, 'Christian Biesinger' via blink-dev
> <blin...@chromium.org> wrote:
>>
>> On Tue, Jul 22, 2014 at 1:31 PM, Eric Seidel <ese...@chromium.org> wrote:
>> > Concerns were also raised about the stable state quiecence logic and
>> > whether we implement it correctly:
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
>> > But that can also be investigated (and possibly fixed) asynchronously
>> > from shipping this feature.
>>
>> Can you be more specific about the concerns? AFAIK, I implemented it
>> correctly.
>
>
> I just remember there was some back and forth about the differences between
> microtasks and awaiting a stable state, etc. I just wanted to check up on
> how all that got resolved to make sure our implementation is in sync with
> the spec.
>
> None of that needs to block shipping the feature. It's just something that
> came up in our discussion today.
microtasks. Assuming that we implement microtasks per the spec, this
should be implemented correctly. Hope this helps.
-christian
Adam Barth
Jul 22, 2014, 6:28:56 PM7/22/14
to cbies...@google.com, ese...@chromium.org, jacka...@gmail.com, yo...@yoav.ws, blin...@chromium.org
On Tue Jul 22 2014 at 3:08:06 PM, Christian Biesinger <cbies...@google.com> wrote:
On Tue, Jul 22, 2014 at 6:03 PM, Adam Barth <aba...@chromium.org> wrote:
> On Tue Jul 22 2014 at 2:59:10 PM, 'Christian Biesinger' via blink-dev
> <blin...@chromium.org> wrote:
>>
>> On Tue, Jul 22, 2014 at 1:31 PM, Eric Seidel <ese...@chromium.org> wrote:
>> > Concerns were also raised about the stable state quiecence logic and
>> > whether we implement it correctly:
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#await-a-stable-state
>> > But that can also be investigated (and possibly fixed) asynchronously
>> > from shipping this feature.
>>
>> Can you be more specific about the concerns? AFAIK, I implemented it
>> correctly.
>
>
> I just remember there was some back and forth about the differences between
> microtasks and awaiting a stable state, etc. I just wanted to check up on
> how all that got resolved to make sure our implementation is in sync with
> the spec.
>
> None of that needs to block shipping the feature. It's just something that
> came up in our discussion today.
Ah yeah, the outcome was to make stable states identical to
microtasks. Assuming that we implement microtasks per the spec, this
should be implemented correctly. Hope this helps.
Did that get reflected in the spec for stable states?
Adam
>> >>> email to blink-dev+unsubscribe@chromium.org.
Philip Jägenstedt
Jul 22, 2014, 6:42:19 PM7/22/14
to Adam Barth, cbies...@google.com, Eric Seidel, Tab Atkins Jr., Yoav Weiss, blink-dev
Adam Barth
Jul 22, 2014, 6:43:05 PM7/22/14
to phi...@opera.com, cbies...@google.com, ese...@chromium.org, jacka...@gmail.com, yo...@yoav.ws, blin...@chromium.org
Great! Thanks everyone!
Adam
Reply all
Reply to author
Forward
0 new messages