Intent to Ship: The picture element's sizes and extended srcset attribute

[Yoav Weiss]

Emails

Yoav Weiss - yo...@yoav.ws

Spec

http://picture.responsiveimages.org/

Summary

Enable a responsive images solution for the "resolution switching"/"variable width images" use case, by letting authors hint the browser regarding eventual layout dimensions, and provide multiple resources in multiple dimensions. As a first stage, these features would be shipped only with the img element.

Motivation

The "resolution switching" use case is a major use-case of the responsive images problem, and solving it would enable authors huge savings when designing Responsive/fluid Web sites.

The sizes and extended srcset attributes, as defined in the picture specification, resolve that use case in an efficient and elegant manner. 

Compatibility Risk

Low.

That feature is a subset of the overall picture specification, which Firefox are also working on. 

I intend to port the feature to WebKit and the project have expressed willingness to accept patches behind a compile flag.

The feature is under consideration in IE.

Ongoing technical constraints

None.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/vuLeAM9fJww/UHnMz7QLRWgJ

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

http://crbug.com/357586

Row on feature dashboard?

Yes - for the entire picture specification.

Requesting approval to ship?

Yes.

[Tab Atkins Jr.]

LGTM

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Adam Barth]

On Tue Jun 03 2014 at 1:21:59 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Emails

Yoav Weiss - yo...@yoav.ws

Spec

http://picture.responsiveimages.org/

Summary

Enable a responsive images solution for the "resolution switching"/"variable width images" use case, by letting authors hint the browser regarding eventual layout dimensions, and provide multiple resources in multiple dimensions. As a first stage, these features would be shipped only with the img element.

Motivation

The "resolution switching" use case is a major use-case of the responsive images problem, and solving it would enable authors huge savings when designing Responsive/fluid Web sites.

The sizes and extended srcset attributes, as defined in the picture specification, resolve that use case in an efficient and elegant manner. 

Compatibility Risk

Low.

That feature is a subset of the overall picture specification, which Firefox are also working on.

Can you help me understand the implementation status in Firefox?  At that link, I see a large not of patch files, most of which have review+ associated with them, but I'm not sure how many of them have landed or are available in Firefox's nightly builds in some fashion.

 

I intend to port the feature to WebKit and the project have expressed willingness to accept patches behind a compile flag.

The feature is under consideration in IE.

For what it's worth, "under consideration" is a neutral signal from IE.

The reason I ask these questions is because I'm trying to understand how this functionality fits into Blink's shipping guidelines.  The <picture> specification is from a W3C community group rather than a working group, which means we don't have the formal steps of Last Call or Candidate Recommendation to guide us about the maturity of the specification.  On the implementation side, Firefox is clearly working on their implementation, but it's unclear how supportive Safari or IE actually are.

It's possible we should ship img@sizes now, but I'd would feel more comfortable if either (1) a standards body declared the specification ready for implementation in some fashion or (2) Firefox's implementation was shipping in at least their nightly/channel channel.

Maybe (1) has already occurred in the RICG, but that's not reflected in the specification?  If so, you might want to add a section at the top of the document named "Status of this document," as is typical of W3C specifications.

The reason these steps are important before shipping this feature is that we don't want to change img@sizes after shipping it.  We can be more confident about the stability of the feature if the RICG declares it stable or if other implementors would also feel the pain of changing their implementation.

Adam

[Tab Atkins Jr.]

On Tue, Jun 10, 2014 at 9:53 AM, 'Adam Barth' via blink-dev
<blin...@chromium.org> wrote:
> It's possible we should ship img@sizes now, but I'd would feel more
> comfortable if either (1) a standards body declared the specification ready
> for implementation in some fashion or (2) Firefox's implementation was
> shipping in at least their nightly/channel channel.
>
> Maybe (1) has already occurred in the RICG, but that's not reflected in the
> specification? If so, you might want to add a section at the top of the
> document named "Status of this document," as is typical of W3C
> specifications.
>
> The reason these steps are important before shipping this feature is that we
> don't want to change img@sizes after shipping it. We can be more confident
> about the stability of the feature if the RICG declares it stable or if
> other implementors would also feel the pain of changing their
> implementation.

I can declare it stable right now. It's stable. No changes will occur
besides compatible bugfixes and future extensions.

~TJ

[Adam Barth]

On Tue Jun 10 2014 at 11:38:50 AM, <mar...@marcosc.com> wrote:

On Tuesday, June 10, 2014 12:53:24 PM UTC-4, Adam Barth wrote:

On Tue Jun 03 2014 at 1:21:59 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Emails

Yoav Weiss - yo...@yoav.ws

Spec

http://picture.responsiveimages.org/

Summary

Enable a responsive images solution for the "resolution switching"/"variable width images" use case, by letting authors hint the browser regarding eventual layout dimensions, and provide multiple resources in multiple dimensions. As a first stage, these features would be shipped only with the img element.

Motivation

The "resolution switching" use case is a major use-case of the responsive images problem, and solving it would enable authors huge savings when designing Responsive/fluid Web sites.

The sizes and extended srcset attributes, as defined in the picture specification, resolve that use case in an efficient and elegant manner. 

Compatibility Risk

Low.

That feature is a subset of the overall picture specification, which Firefox are also working on.

Can you help me understand the implementation status in Firefox?  At that link, I see a large not of patch files, most of which have review+ associated with them, but I'm not sure how many of them have landed or are available in Firefox's nightly builds in some fashion.

We aim to ship in Firefox 32. This is a high priority feature for Mozilla.

That's great.  Maybe we should aim for shipping img@sizes in M28.  That should align roughly with Firefox 32, if I'm reading the calendar correctly.

 

I intend to port the feature to WebKit and the project have expressed willingness to accept patches behind a compile flag.

The feature is under consideration in IE.

For what it's worth, "under consideration" is a neutral signal from IE.

The reason I ask these questions is because I'm trying to understand how this functionality fits into Blink's shipping guidelines.  The <picture> specification is from a W3C community group rather than a working group,

This is incorrect. The picture element was moved to the HTML Working Group about a year ago. It's just that dealing with the HTMLWG process is such a train-wreck that we just started self-hosting the spec. But it's a "HTMLWG" spec for all intents and purposes.

Ah, that's good to know.  That wasn't clear to me from http://picture.responsiveimages.org/

 

which means we don't have the formal steps of Last Call or Candidate Recommendation to guide us about the maturity of the specification.  On the implementation side, Firefox is clearly working on their implementation, but it's unclear how supportive Safari or IE actually are.

The picture spec is being folded into WHATWG HTML. This will then automatically appear in the W3C HTML5.1 Nightly. It will then go through the appropriate W3C standardization process as part of "HTML5.1".

Ok.

It's possible we should ship img@sizes now, but I'd would feel more comfortable if either (1) a standards body declared the specification ready for implementation in some fashion or (2) Firefox's implementation was shipping in at least their nightly/channel channel.

Mozilla is coordinating closely with Yoav on the development of this feature (our engineer, John Schoenick, speaks with Yoav, Tab, and the rest of the picture team. on about implementation detail on a daily basis).

Maybe (1) has already occurred in the RICG, but that's not reflected in the specification?  If so, you might want to add a section at the top of the document named "Status of this document," as is typical of W3C specifications.

As above, this will happen automatically once the text is moved officially into the WHATWG spec. We are working to make this happen ASAP and already have Hixie's blessing to do so.

That also sounds positive.

On Tue Jun 10 2014 at 12:07:56 PM, Tab Atkins Jr. <jacka...@gmail.com> wrote:

I can declare it stable right now.  It's stable. No changes will occur
besides compatible bugfixes and future extensions.

Great!

LGTM to ship in M28 presuming Firefox stays on track to ship their implementation in Firefox 32.  Please leave the runtime flag in place in case we need to adjust the release schedule to stay synchronized with Firefox.

Adam

[Elliott Sprehn]

On Tue, Jun 10, 2014 at 12:10 PM, 'Adam Barth' via blink-dev <blin...@chromium.org> wrote:

...

That's great.  Maybe we should aim for shipping img@sizes in M28.  That should align roughly with Firefox 32, if I'm reading the calendar correctly.

 

...

LGTM to ship in M28 presuming Firefox stays on track to ship their implementation in Firefox 32. 

I'm glad our feature shipping time machine is working now!

- E 

[Adam Barth]

Err...  M38, since we don't have a time machine.  :)

[Marcos]

On June 10, 2014 at 3:13:56 PM, Adam Barth (aba...@google.com) wrote:
> > Err... M38, since we don't have a time machine. :)

Just got word also that we had a delay on a review, which is causing us to delay to 33. In any case, we are full steam on this on the Moz side :) 

Will also make sure the status of the doc gets updated to say that this is a W3C HTMLWG spec. Sorry about the confusion. 

[Ojan Vafai]

LGTM as well. I see Opera has one of the spec editors. I assume Opera are happy with shipping this?

[Tab Atkins Jr.]

On Tue, Jun 10, 2014 at 2:13 PM, Ojan Vafai <oj...@chromium.org> wrote:
> LGTM as well. I see Opera has one of the spec editors. I assume Opera are
> happy with shipping this?

I'll just quote zcorpan:

> I'm on my phone. Don't have work email

That wasn't very useful, but given that he's the one integrating the
spec into WHATWG HTML, I'd say they're down with this.

~TJ

[Yoav Weiss]

Awesome! M38 it is.

(And someone should really get going on that time machine :P )

[Simon Pieters]

On Tue, 10 Jun 2014 23:13:38 +0200, Ojan Vafai <oj...@chromium.org> wrote:

> LGTM as well. I see Opera has one of the spec editors. I assume Opera are
> happy with shipping this?

Yes.

--
Simon Pieters
Opera Software

[Yoav Weiss]

On Wed, Jun 11, 2014 at 12:42 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Awesome! M38 it is.

Re-reading the thread, Firefox will probably ship in Firefox 33 (shipping October 14th) rather than Firefox 32 (shipping on September 2nd).

If I read the schedule correctly M38 will hit stable on September 26th. (So a week before Firefox 33 hits stable)

Given that, are we still good for M38?

[Adam Barth]

On Wed Jun 11 2014 at 3:42:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Jun 11, 2014 at 12:42 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Awesome! M38 it is.

Re-reading the thread, Firefox will probably ship in Firefox 33 (shipping October 14th) rather than Firefox 32 (shipping on September 2nd).

If I read the schedule correctly M38 will hit stable on September 26th. (So a week before Firefox 33 hits stable)

Given that, are we still good for M38?

That's fine with me.

@marcos: Are you all happy with that timing?

Adam

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Marcos]

On June 11, 2014 at 12:44:13 PM, Adam Barth (aba...@google.com) wrote:
> > On Wed Jun 11 2014 at 3:42:55 AM, Yoav Weiss

> > Given that, are we still good for M38?
> That's fine with me.
>
> @marcos: Are you all happy with that timing?

Yes, this aligns really nicely. 

[Ojan Vafai]

Just to be clear, this still needs one more LGTM from an API owner.

[TAMURA, Kent]

LGTM3.

--
TAMURA Kent
Software Engineer, Google