[whatwg] Web Forms 2.0 comments

Ian Hickson wrote:
> On Thu, 10 Jun 2004, Sander wrote:
>> <snip longwinded way of me saying> "If a repetition template has 
>> user-entered data it might clash with the template's [ID]."
> 
> Ouch, good point, a template might well include user-entered data that
> might match that string. For that matter a script might contain [foo]
> which happens to be the ID of the template.
> 
> I'm somewhat reluctant to just say "only do these attributes" since
> there's bound to be use cases where you need to do it that haven't been
> covered. Like, in fact, value (there are some interesting use cases that
> involve only using it in value, instead of name, and some cases where
> you would want to affect the scripts).
> 
> Any other ideas for solving this?

I've been thinking about this for a while, but I can't come up with any
ideas which _really_ make me happy. That said, through a process of
elimination, I've pretty much convinced myself that the way to go would
be:

The parsing of [ID] is by default limited to the "for", "form", "headers",
"id", "name" and "template" attributes. For those cases where inserting the
[ID] in another attribute is desired, a new attribute "parseattributes"
(needs a better name, obviously) is defined for use within a repetition
template. This attribute is used to specify a comma-separated list of those
attributes of descendant elements in which the [ID]-string will be searched
for and replaced by the repetition block's index. This specified list of
attributes replaces the default. Thus, if this attribute exists, but is
empty, no attributes will be matched.


Reasoning: 
Since CDATA attributes have no illegal characters, no string can be
constructed which does not run the risk of clashing with user-entered data.
Since a solution akin to requiring the webmaster to utilize bitstuffing
techniques is clearly undesirable, the solution should focus on allowing
the webmaster to determine for which attributes [ID]-parsing is desired.
(Since only the webmaster can be considered capable of determining this.)
However, having to specify this all the time is also undesirable, so a
reasonable default should be chosen. As the name attribute almost _needs_
to be included in this default because of the intended use of repetition
templates, but the name attribute also has the type CDATA, a way will need
to be provided to exclude attributes from the default. This latter
requirement means that a way of modifying the attribute itself to indicate
if the attribute should be parsed or not becomes bothersome. (Throw away
early ideas of: <foo [value]="" /> - though I wouldn't know if that would
be valid XML anyway.) Thus what is left is for the webmaster to specify
upfront which attributes are safe for [ID]-parsing.
Finally, the list of default attributes to be parsed consists of those
attributes which are either both inherently 'safe' (types: ID, IDREF,
IDREFS - in which square brackets are not allowed) and likely to be used in
typical cases (which excludes all random attributes which take numerical
values), or which are semi-essential to repetition templates being useful.

Various minor alternatives to this general theme can be discussed (should
"parseattributes" also apply to the element on which it is set? maybe even
be limited to that? only be allowed to be set on the element which also
defines the template-name? should other attributes be included in the
default? should the default be "everything", with the attribute listing
exclusions?), but for now I prefer my choices (obviously), and unless
someone can poke big holes in my reasoning or has some kind of brilliant
alternative, I think this should be the general solution.
The biggest problem I see is that if you want to retain the default list of
attributes, and then add just one more (for example, value), you need to
write the long-winded string of parseattributes="for, form, headers, id,
name, template, value". Yet I don't see a way around that (at least not
without adding yet another attribute), plus, for most basic cases,
parseattributes="name, value" will probably suffice. 
Another problem is that parseattributes affecting descendant repetition
templates might hamper modularity. Maybe the 'current' list should be reset
at each new template.

>> More on repetition: I find the existence of the <repeat> element next to
>> the repeat attribute with numerical value to be confusing. I suggest
>> dropping the latter. (Comparing against an older draft, I vaguely
>> suspect this already being the plan, with the necessary editing simply
>> not having been done yet.)
> 
> Not sure what you meant by this.

You specify both repetition blocks (3.2.2: "An element ... with the repeat
attribute ..., with the attribute's value equal to an integer") and initial
repetition blocks (3.5.4: "The repeat element ... is used to insert
repetition blocks without having to explicitly copy the repetition template
markup in the source document.")
I just now grokked that the former might exist so that you can (dynamically)
set the "repeat" attribute on an existing element to turn it into a
repetition block, but the benefit of setting an attribute versus replacing
a node seems very small to me, and the existence of two ways to create a
repetition block both confusing and wasteful.


>> On which subject: Hixie, are you interested in editorial comments on the
>> Web Forms draft yet, or is it still too early for that?
> 
> Editorial comments are welcome but be aware that I'm likely to ignore any
> that aren't of great benefit to the spec. :-)

*grins* Okay. I'll look over fantasai's comments, and then see if I have
anything left which I consider to be sufficiently worthwhile to bother you
with.



Two incidental comments on stuff from other threads:

> On Thu, 10 Jun 2004, Dean Edwards wrote:
>> imho, something like the <repeat> construct belongs in the realm of
>> jsp/asp/php. maybe this functionality can be included as a DOM method
>> for completeness?
> 
> It is a DOM method too. In fact, it's defined in terms of two DOM
methods.
> And it could indeed be done on the server side, although it would be a
> lot uglier.
> 
> Should I just remove it for now?

I at least oppose the idea of removing it; no matter how odd or
unconventional (though really, it's not that bad - it's just a placeholder
for content to be added at run-time), the benefits of its existence are
huge.


> Maybe we should drop "precision" altogether and just have "step", then
> make it apply to all the numeric and date/time types.

That's throwing away the ability to specify logarithmic numbers. Not used
very often admittedly (at least in my experience), but the possibility of
them is very welcome nonetheless.
I'm personally leaning toward the earlier suggestion of a list of
datetime-part values ""y,m" for expdate, "y,w" for week, "y,m,d,h,M""
(which you called "nice and generic, but ... much more complicated"), but
extended to (for example) "h,15M" - which would specify a precision of 15
minute increments for a time consisting of hours and minutes. I think
authors will be more than willing to put up with the complexity of this (I
know I would be) to have just one general purpose datetime element which
can deal with all the weird requirements which comes up in actual use.

Thanks for your attention,
Sander

Received on Monday, 14 June 2004 14:09:42 UTC