W3C home > Mailing lists > Public > public-html@w3.org > September 2013

Re: New responsive images proposal

From: Michael[tm] Smith <mike@w3.org>
Date: Sun, 29 Sep 2013 21:01:00 +0900
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Jirka Kosek <jirka@kosek.cz>, Robin Berjon <robin@w3.org>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
Message-ID: <20130929120058.GC99230@sideshowbarker>
Hi Tab,

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

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.

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

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

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.


Michael[tm] Smith http://people.w3.org/mike
Received on Sunday, 29 September 2013 12:01:11 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:05 UTC