Re: CfC: to publish "The picture element" specification as a First Public Working Draft (FPWD)

On Thursday, 7 February 2013 at 19:50, Edward O'Connor wrote:

> Hi Silvia,
>  
> You wrote:
>  
> > I'm not sure if you saw this on the thread about the picture element
>  
> Ahh, sorry, I missed that. Here's a reply:
>  
> > On Mon, Feb 4, 2013 at 8:47 AM, Mat Marquis <mat@matmarquis.com (mailto:mat@matmarquis.com)> wrote:
> >  
> > > Merging the two specifications has been one of the the RICG’s goals
> > > for some time now. I’d be very happy to work towards those ends,
> > > though I would propose that the scope of the `srcset` attribute be
> > > reduced to a set of resolution heuristics as a part of that effort. I
> > > want to stress that this does represent the consensus of the
> > > Community Group, rather than simply my own opinions on the matter.
> >  
> >  
> >  
> > I'm curious to hear from the srcset proponents if they agree with this
> > position
>  
>  
>  
> I'm sympathetic to the idea that the syntax of the width and height
> descriptors in image candidate strings should be modified to make their
> actual behavior more obvious. I don't actually think they should be used
> all that often by authors—the use cases calling for them are usually
> better served by clipping.

I tend to agree. There needs to be more done to have a discussion around this to see what developers think. At the moment, it's very easy to resize an image in, say, Photoshop, and just have it work (e.g., using something like picturefill). However, doing the manual labor of clipping with CSS is not so much fun - even if it's the right solution™.  
   
> > and would also be willing to contribute to a merged document. It would
> > be much easier to add the merged document into HTML than individual
> > ones.
>  
> I don't think we should merge the documents, no. Each document sets out
> to solve different (though somewhat overlapping) goals, and the features
> were designed under different constraints. We should proceed with
> speccing both and see what browser engines end up implementing.

I agree.   
>  
> Silvia wrote, in a somewhat different order:
>  
> > Also, the @srcset attribute is used in both, and defining the same in
> > two different specifications doesn't make much sense to me.
>  
>  
>  
> I agree that redefining srcset="" in the <picture> proposal would be
> unfortunate. It's not a goal of the srcset="" spec to be used by the
> <picture> spec, but I'm happy to entertain concrete proposals on how to
> tweak the spec to make referencing the feature from the <picture> spec
> easier.

At first glance, the thing that would make srcset reusable is just changing the explicit references to the img element. If it was just something generic, like "the owner element of the srcset attribute" in the processing the image candidates section, then we would be good.  

The con is that you lose the preciseness that is currently in the srcset spec by explicitly saying "the img element" repeatedly.    
  
> > […] I'd like to see the two almost-compatible proposals for <picture>
> > and @srcset be merged and published together as a FPWD, so we don't
> > put browsers into the difficult position of needing to choose which of
> > the two @srcset specifications to follow and implement and we don't
> > end up with incompatible implementations.
>  
>  
>  
> Actually, assuming we manage to avoid (as we have thus far) a duplicate
> definition of srcset="" in the <picture> spec, I think that's precisely
> the position we want to put the browser vendors in. Like Marcos said:

It is exactly why I didn't do it :)     
>  
> > The reality is that this depends on browser makers actually backing
> > the proposals[…]
>  
>  
>  
> Yup. In order for either extension spec to meet the CR exit criteria of
> the HTML spec, there will need to be two interoperable implementations
> in browser engines. Without implementations, we shouldn't merge either
> extension spec.

Agreed.  
  
> > On Thu, Feb 7, 2013 at 8:34 PM, Anselm Hannemann <info@anselm-hannemann.com (mailto:info@anselm-hannemann.com)> wrote:
>  
> […]
> > > For that I think authoring both specifications together to reach a
> > > good goal is important but I don't think we should merge both
> > > specifications into one covering all.
> >  
> >  
> >  
> > Why not? I assume you intend them to be merged into the HTML spec
> > eventually, so they will get together anyway.
>  
>  
>  
> (See my comment above that we shouldn't merge before implementations.)
> It's of course true that the people working on each extension spec
> desire their spec to be implemented by browser engines. (Otherwise, why
> work on a spec at all?) It doesn't follow, though, that the people
> working on each extension spec aim to have both of them implemented. For
> instance, I think it would be a mistake for browser engines to implement
> the <picture> element proposal. And I believe that some of the folks
> contributing to the <picture> spec would rather browser engines not
> implement srcset=""'s width and height descriptors in image candidate
> strings.

I personally don't know what is right here. Just want a solution I, and others, can actually get our heads around - there has been a lot of complaints about the complexity of the syntax. I've implemented srcset to spec [1] and I still can't make heads of tails about how it works :( That is, I could not explain it to someone if they asked me. Although it seems to address the use cases, the way it goes about it might be a (developer) usability problem. Hopefully we can get a simpler syntax but the RICG has struggled to come up with anything better so far.   

[1] http://responsiveimagescg.github.com/picture-refimp/demo/

Received on Thursday, 7 February 2013 20:28:20 UTC