Create a presentation for HTMLWG meeting

[marcoscaceres]

As responsive images have been added to the agenda of the HTMLWG meeting, we need to create a presentation that shows the use cases, requirements, and how we see picture working with the srcset attribute. Presentation will take place on the 1st of November.

What we want to present:

• Why we made a use cases/requirements document (i.e., how we got here).
• Each of the requirements
• how the current solutions meet/do not meet each requirement
• how/why we want to harmonize the two solutions.
• Demo <picture> running in Chromium.
• Talk about what developers are doing (e.g., picturefill) and what it means for browser folks (i.e., if the solution does not meet the requirements then developers will continue to use JS based solutions which can impact negatively on users).

The format will be in HTML using reveal.js.

The slides are in the TPAC2012 directory in Meta.

[anselmh]

• Is there already a list of requirements and features to be shown?
• Until when this has to be finished?
• Preferred format (html, ppt, keynote,…)?

I have a presentation here I held at Fronteers Jam session. Feel free to pick any part of it for the presentation.

[marcoscaceres]

@anselmh I've updated the description of the issue to answer your questions. Let me know if it makes sense.

Thanks also for the link to your presentation! I'll certainly pilfer parts and media from it! :)

I'm currently doing some background research for the presentation, but would appreciate your review of it once it's a bit more polished.

[anselmh]

Of course I will review them if you want. :)

[anselmh]

• Slide Set up twitter commit account #2 has a typo "leasons" should be "lessons", right?
• for me there are too many "fun"-pictures not saying anything on the topic. It's nice to have 1/2 but that is too much I think
• The timeline is a bit mixed up right now… it should be in a clear list order
• quotes have no very nice typography, also too many after another
• I am currently missing the real facts

I will wait for some more content to give real feedback I think.

[marcoscaceres]

thanks @anselmh for the initial review (agree with everything you say). This is still a very early draft and I'm just doing a brain dump of ideas. I'll comment here once it's ready for review.

Also, what "real facts" where you hoping to see?

[anselmh]

"real facts" – use code examples and specification terms…

[marcoscaceres]

Yep, will do that once I cover the spec... I'm still undecided if I should present the Requirements section in comparison to the current solutions or independently.

[anselmh]

I would split them.

[anselmh]

Okay so just a few new comments:

• missing the points of monochrome-images and there nowhere 'different crops' is found
• design breakpoints are currently sizing only but not display-types
• you may add that a futurely bandwidth media-query can be used w/o spec change
• #-6 is unclear to me what you are trying to achieve here. There might be better examples to show the problem of either not crispy or too large images on the web.
• Image Formats (#-8): You know JPEG2000 could already handle it? Image XR and WebP should follow after JPEG2k in that case.
• I have uploaded a demo. Will you show this to them? It even should work on a Kindle w/ monochrome display
• #-13 – the comparison table: I am not sure if all the points are actually correct at srcset:
  • why would it need server side processing?
  • gracefully supports new formats (srcset should be able to handle that I think, right?)
  • think of different crops and display-types here. That is (at least for me) the major difference.
  • developer friendliness of writing the code (picture is much easier as it's a known and common pattern)
• in attributions you have a : too much at the end…
• provide the link to the demo?

That's it for now :)

[marcoscaceres]

Thanks @anselmh! That's great feedback. I'll try to address everything.

[marcoscaceres]

@anselmh started addressing some of your feedback - but not done yet. Will try to wrap up tomorrow.

[anselmh]

great, just ping me when done so I can do another review :)

[marcoscaceres]

On Monday, 29 October 2012 at 15:14, Anselm Hannemann wrote:

Okay so just a few new comments:
missing the points of monochrome-images and there nowhere 'different crops' is found

added

design breakpoints are currently sizing only but not display-types

Agreed. But I don't want to clutter the screen with code - just want to illustrate. But I will verbalise that.

you may add that a futurely bandwidth media-query can be used w/o spec change

Bandwidth is too controversial. To mention it might cause us credibility issues.

#6 (#6) is unclear to me what you are trying to achieve here. There might be better examples to show the problem of either not crispy or too large images on the web.

Added some text describing the problem.

I have uploaded a demo. Will you show this to them? It even should work on a Kindle w/ monochrome display

Will try to show it. I'm not sure how much time we have been allocated yet.

Image Formats (#8 (#8)): You know JPEG2000 could already handle it?

Did not know that.

Image XR and WebP should follow after JPEG2k in that case.

Added.

#13 – the comparison table: I am not sure if all the points are actually correct at srcset:
why would it need server side processing?

Because you can't say srcset="foo 2x, bar 2x" where foo is JPEG2000 and WebP.

gracefully supports new formats (srcset should be able to handle that I think, right?)

I don't see how without a type attribute? For example:

srcset="foo/ 2x, bar 2x"

How can the browser decide which one to use without first making a request to the server?

think of different crops and display-types here. That is (at least for me) the major difference.
developer friendliness of writing the code (picture is much easier as it's a known and common pattern)

Agreed.

in attributions you have a : too much at the end…

Fixed

provide the link to the demo?

Fixed.

Marcos Caceres

http://datadriven.com.au

[marcoscaceres]

note I have not checked in because I'm using roaming.

[marcoscaceres]

Going with current slide set. Presenting in one hour or so.