- 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>
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. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Received on Sunday, 29 September 2013 12:01:11 UTC