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

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> 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.

> 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.

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.

> […] 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:

> 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.

> On Thu, Feb 7, 2013 at 8:34 PM, Anselm Hannemann <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.


Ted

Received on Thursday, 7 February 2013 19:50:40 UTC