[whatwg] Web Forms 2.0 comments

[Sander]

Ian Hickson wrote:
> How about this? We say that all attributes are processed, except those
> starting with the two character string "[]", which just have their two
> leading square brackets removed and are otherwise untouched.
> 
> Then any unsafe attributes can just have "[]" put at the front.
> 
> Ugly, but at least we don't have a weird attribute and a list of magical
> attributes that get processed...

I've been mulling this over for a while, but I like it even less than my
"magical attributes" solution. The main reason for this is found in content
management systems (as I create them), where roughly up to 95% of all input
elements will potentially contain user-submitted data. Always in the value
attribute of course. Using the [] solution, this means that I'd have to go
and insert that into pretty much every input element. That's a lot of
bother. Much better to filter more broadly, aka on specific attributes.
If your objection to the "magical attributes" stands (I'm not saying that it
isn't bad, but I do think that authors will be able to deal with it; after
all, it's not that different from for example CSS, where things like the
margin property are applied to a 'magical' list of elements, and that even
differing per UA), then I would propose to go back to your original
proposal, with an "excludeparsing" attribute containing a comma-seperated
list of of those attributes of descendant elements in which
[id]-replacement doesn't happen.
(That said, I can most certainly live with the [] solution - I just think
than in reality I'll hate it over alternatives.)

Let's see - related to this, I've seen a proposal floating by to not do
[id]-replacement at all. I strongly oppose that. Right now I can drop in
the template, <repeat> elements and add/remove buttons in pretty much all
applications where I'd want to use them, to vastly simplify the client-side
code, and I wouldn't have to change a single line of the backend. It fits
perfectly. If I'd somehow have to go and parse a list of values with the
same name (or be forced into automatic appending of .[id]), I don't think
I'd bother with repeat templates at all.

I do like the <template> element proposal for better degradability.

>> 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.
> 
> We can add them back if there really is a good use case. I haven't seen
> one, to be honest. 

I haven't yet thought of a "really good" usecase, but just its inclusion in
the original spec has allowed me to envision dozens of potentially
interesting uses to explore. Most being one variation or another of
'navigation' through anything containing very large amounts of data. For
example, a weblog as it will exist 10 years from now: showing a logarithmic
range to jump back 1, 2, .., 9, 10, 20, .., 90, 100, 200, .., .., 3000,
4000 days. (Or 'posts' on a message board if the objection to that would be
that it could better be done with a date element.)

>> 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.
> 
> Is the current text (using step) acceptable?

Acceptable? Yes. (Hell, I'm overjoyed just having _something_ for this in
there.) :)
Do I like it better than what I was proposing? No. :) Though this is mostly
a result of not liking so many elements for what I see as just different
aspects of the same one datatime input element.

Use case: a nature photography website with a list of national parks: asking
users for each "what is the best month of the year to visit this park?"
input type="month" is 'useless', as it includes a year (this usecase makes
me realize I liked it better when it was called expdate, as that name at
least suggested the existence of the year). So the website will use a
regular select, throwing away the semantics of "date" (with additional
side-benefits like the user-agent localizing the names of the months). You
could of course add yet another datetime-derived input value for "just
month" (and then someone else would come up with a usecase for "just day of
the month plus time in hours" (monthly meetings?)), but that's exactly my
objection. I think there are already too many input types now, when it
could all be done with <input type="datetime" part="m">, which is
extensible enough to cover every use case that hasn't yet been thought of,
can easily include step for datetime cases, and thus allows for the current
step to be reverted back to what it was when it was still called
precision.

I realize a lot of this last part has been brought up in some form or
another already, so I won't go and become a pain by continuing to argue for
it if you stick with the current solution, but I do think it'd be
worthwhile bringing up at least once more.

Thanks,
Sander