Re: New responsive images proposal

On Sun, Sep 29, 2013 at 5:01 AM, Michael[tm] Smith <mike@w3.org> wrote:
> "Tab Atkins Jr." <jackalmage@gmail.com>, 2013-09-27 15:41 -0700:
>> On Fri, Sep 27, 2013 at 5:15 AM, Jirka Kosek <jirka@kosek.cz> wrote:
>> > I think that proposal is first which would introduce numbered attributes
>> > like src1, src2, ..., srcN. I think that we should be very careful
>> > before opening this can of worms.
>>
>> Thematically, it's similar to other attributes that come in groups,
>> like data-*.
>
> Actually I think data-* is the only other existing precedent for something
> like this that's open-ended in that it's defining a pattern for attribute
> names instead of explicit names. Well, except for Robin's equally
> unpleasant proposal to define all element and attribute names with hyphens
> in them as valid.

Right, after I wrote that I realized data-* was the only actual example.

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

>> But yes, this is somewhat new.  I don't like it much,
>> but it was required in order to avoid either using elements
>
> I don't think you've made it clear why using elements is bad.  At least it
> seems clear it not absolutely bad. Authors don't think it's bad at least.
> Based on the feedback we've been getting, it seems pretty overwhelmingly to
> be the solution they'd prefer.
>
> I'm well aware of the performance problems that have been pointed out with
> it, but I'd thought that the proposal that Kornel had put forward was a
> possible solution to that.

I wasn't trying to make a strong argument against sub-elements, I was
just referencing the existing disapproval of them.

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.

>> or having a single super-complicated syntax.
>
> The syntax proposed for src1, src2, ..., srcN doesn't exactly look
> uncomplicated to me. It's still complicated, and whatever it's reducing at
> the syntax level, it's just shifting complications to other places.

I was pointing out that mashing everything together into a single
attribute makes the syntax even more complicated and hard to read.

I think there are very reasonable arguments that, for the use-cases
I've listed, my syntax is either as simple or simpler than what you
have to calculate and write out with srcset.

> For one thing I can tell you that it'll makes it quite a bit more
> complicated to create HTML conformance-checking tools. We already have that
> with data-* but this would be even more work for anybody to implement
> checking support for than data-* does.
>
> In brief, the reason is that in RelaxNG and similar existing grammar/schema
> formalisms, there's no way to express that a certain pattern should be allowed
> as an attribute or element name. You can only allow explicit names. The
> trick that the validator.nu code uses for data-* is just to drop the data-*
> elements from a document before it gets exposed to the grammar checking
> part of the validator, and not do any further checking on their values.
>
> But that same trick won't work for the case of src1, src2, ..., srcN,
> because unlike data-* which just allows any string value, that case has a
> microsyntax that we'll need to check. So what I can imagine we'll need to
> do instead is to have a filter that sort of internally (in memory)
> normalizes all the src1, src2, ..., srcN names into some other name
> (arbitrary/opaque -- doesn't really matter what it is), and have that one
> name defined in the grammar, with some microsyntax-checking custom code
> bound to it.

I'm sorry, but validators are below literally everything else in the
priority of constituencies as I see them.  I'd be fine with proposing
features that are useful for authors or users even if it was actually
*impossible* to validate, as opposed to just difficult due to current
technology choices.  This is easy to validate with actual code, rather
than specialized conformance-checking DSLs.

~TJ

Received on Thursday, 3 October 2013 20:25:04 UTC