Re: New responsive images proposal

"Tab Atkins Jr." <jackalmage@gmail.com>, 2013-10-03 13:24 -0700:

> On Sun, Sep 29, 2013 at 5:01 AM, Michael[tm] Smith <mike@w3.org> wrote:
> > Anyway I don't think src1, src2, ..., srcN is good for authors. I think
> > it's already clear at least that it's not the syntax most would prefer.
> 
> That's not clear at all.  I know you don't like it, but I've received
> a *bunch* of favorable feedback on the syntax from the RICG and from
> random people on Twitter.

I mainly just meant that authors and the RICG so far seem to prefer
<picture><source> over using an attribute or attributes. But I've followed
some of the feedback on src1, src2, ..., srcN and, yeah, I can see it's true
that it's gotten positive responses from people in the RICG and community.

> Even if someone *does* come up with a way to interpret sub-elements in
> a way that's not horrible, it maintains an innate and unremovable
> horrible-ness from looking exactly like <video><source>, but acting
> differently.

Fair enough. I think we have other ugly features of the platform that look
the same but act differently, but I guess that's not an excuse to add more.

> I'm sorry, but validators are below literally everything else in the
> priority of constituencies as I see them.

Don't think of is as "validators" problem, then. Think of it as an
authoring problem -- the problem being, How do we help authors catch
authoring mistakes, or how do we avoid doing things that are going to make
it hard for authors to catch authoring mistakes, or how do we help authors
catch mistakes as early as possible in the authoring process.

> I'd be fine with proposing features that are useful for authors or users
> even if it was actually *impossible* to validate,

I know you're just putting that forward as something hypothetical, but I
would sure think a red flag ought to be raised if a feature introduces some
class of potential new mistakes an author could make, while at the same
time doing it in a way that actually makes it very difficult for them to
catch those mistakes during the authoring process.

In this case, this feature introduces a syntax that seems relatively
error-prone. So it seems useful to try to think about how best to help
authors catch errors they might run into with it.

> as opposed to just difficult due to current technology choices.  This is
> easy to validate with actual code,

Yeah, I guess it authors making mistakes with syntax in src1, src2, ...,
srcN are going to catch those eventually while testing their code. But I
think it's subjective how "easy" validation-by-running-the-actual-code is
for an author relative to using tools that do static analysis.

> rather than specialized conformance-checking DSLs.

I think it might be better to think of it as a type of static analysis
rather than validation. So it's important to the degree that you think
other mechanisms for doing static analysis on code are important to
programmers in other environments.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Friday, 4 October 2013 03:08:06 UTC