Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

DRY goal is not written as a goal #59

marcoscaceres opened this Issue Oct 4, 2012 · 12 comments


None yet
5 participants

marcoscaceres commented Oct 4, 2012

The goal said:

Don't repeat yourself: If the same image is used multiple times on a single page, it would be useful to define the resource selection in a single place in the document and have this affect all instances of the image

This needs to be rewritten to say how the proposal achieves this. See other goals in the spec.

@ghost ghost assigned Wilto Oct 4, 2012


Wilto commented Oct 10, 2012

This was originally added to the proposal by Adrian Bateman, but he’s been quiet since—@MattWilcox reached out to him to discuss this goal further but never received a response.

The main idea is that one could define their image breakpoints as variables in a central location, to avoid writing a bunch of repetitive markup in the event that multiple adaptive-sourced images are occupying the same same space.

I maintain that this is a problem worth solving, but not something we should aim to solve with this initial picture proposal. I’d much rather see this considered as an overarching way of handling rich media with variable sources—so, potentially video as well. First, I think we should focus on an adaptive image solution with the potential to fall in-line with video, and once that’s in the bank we can find ways of making both more efficient at the same time.

@MattWilcox: you’ve definitely done the most research in this area; where do you land on this currently?

In an ideal world I'd love to see it straight away. But then, everyone always wants everything as soon as possible.

Much more realistically I think we should address the <picture> basics first and get it out in the wild in use as soon as possible. We can add enhancements such as DRY later. Personally, I won't be using <picture> until there's better DRY support, but we need something implemented ASAP. Even if it is "feature lacking". The more complex something is the longer it takes to get out the door and after that the longer it takes to actually be implemented. If we wait until we've got a concrete theoretical solution to DRY that (by necessity) also tackles JS, HTML, and CSS breakpoint creation and cross-technology interoperability - we'll be waiting for a long time for any browser to even begin supporting <picture> - and therefor even longer before we can actually be using it.

As for how this ought to be codified in the proposal - I'm not sure. Is this about the long-term goals, or is it about the v.1.0 goals? And, does the DRY aspect even belong as part of picture? I see it as something more with a more overarching scope - of which picture is a part, but it's not the core.


marcoscaceres commented Oct 10, 2012

@Wilto I agree.

@MattWilcox it's for the v1 goals. It is a W3C specification requirement that the WG show that each goal is met before the specification can proceed to Rec.

Based on the feedback, I am removing this goal from the spec and we can revisit this later. @MattWilcox if you have any idea for how to meet this goal in the future, please let me know. Please have a good think about it.

There has been some work on this over on the Resp Img pages - I do not know how that might work in any kind of browser-level parser detail though, this is higher-functionality thinking. Take a look at http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ (from May) for the general idea and rationale on this.


marcoscaceres commented Oct 11, 2012

@MattWilcox thanks for the link. Ok, I get where we might want to go with that. Ideally, you just target the picture element through a stylesheet and magically set the set of sources that way (within some media query). A general way of doing that through CSS would be useful. Definitely something we need to return to later (or work with the CSS WG on).

Kind of. I do not want to be altering or controlling HTML images via CSS. That is not the job of CSS.

The proposal is a method wherby we can declare breakpoints in one place (the HTML Head) - it's in the HTML because that is the logical place for it to go. That's the source that is loaded first, that's the place where we describe meta data about the resource, that's the place breakpoints need to be. I then want <picture> (and, really, any other relevent HTML elements or properties) able to use the declared breakpoints from the head area (which will already have been loaded) in any way that's useful. For example, by creating a 'dynamic' path to a file, which is controlled via the matching breakpoint. However that's set - be it by screen size, connection type, or whatever.

Likewise, I think that the CSS and the JS should be able to inspect the HTML breakpoint and do their logic based off that. Rather than needing to do their own sensing all over again. The breakpoints don't change between technology stacks, so why do we keep re-sensing the same thing.


marcoscaceres commented Oct 11, 2012

@MattWilcox ok, so we clearly have diverging viewpoints about how to approach that problem (a good thing! :) ). We will come back to that when the time is right. We've nearly distilled the use cases into a set of requirements in the spec, so I'm looking forward to discussing those with you. If you have time, it would be great if you could join us on IRC irc://irc.w3.org:6665/#respimg.

If I could figure out how to IRC I would. Downloaded Colliloquy for OSX and it doesn't want to list any rooms for the irc.w3c.org server at that port. I've no idea what I'm doing with IRC, it's an ancient voodoo I don't remember anymore.


yoavweiss commented Oct 11, 2012

@MattWilcox - setting the port in many IRC clients doesn't work. As an IRC
noob, here's what I did:

  • install irssi (http://irssi.org)
  • run it using irssi -c irc.w3.org -p 6665
  • once connected: /join #respimg

On Thu, Oct 11, 2012 at 2:02 PM, Matt Wilcox notifications@github.comwrote:

If I could figure out how to IRC I would. Downloaded Colliloquy for OSX
and it doesn't want to list any rooms for the irc.w3c.org server at that
port. I've no idea what I'm doing with IRC, it's an ancient voodoo I don't
remember anymore.

Reply to this email directly or view it on GitHubhttps://github.com/Wilto/draft-prop/issues/59#issuecomment-9337349.


marcoscaceres commented Oct 11, 2012

@MattWilcox sorry, yeah... it's a bit old school but it's good for collaboration once you get it going. I use http://limechat.net/mac/ . Colliloquy is annoying. If you have any more issues, happy to help you get it going over skype.

attiks commented Oct 11, 2012

@MattWilcox or go to http://irc.w3.org/ enter your name and #respimg, works pretty good

nwtn pushed a commit to nwtn/picture-element that referenced this issue Mar 18, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment