[whatwg] Web Forms 2.0 comments

[Ian Hickson]

On Sat, 26 Jun 2004, Sander wrote:
>
> 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.

But how often would you put user-submitted data in _template_ elements?


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

You could do that by using a linear range then interpreting it as a power.


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

The problem is that with your solution, UAs have to be able to work out
how to render the UI of thinks like "d,h,m,15w". I have no idea how that
would look, let alone how a UA would handle it or how to specify it in
the spec.


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

For a dropdown to pick a month, there is nothing wrong with <select> with
twelve child <option> elements.


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

I'm not convinced that you'd actually _want_ the names localised in such a
case:

   What month is best to visit the park? [ Janvier |v]

I'm also not really sure I understand what benefit the semantics would
actually bring you here. So it's a month. So what? It's not like Google
(or any data mining software) or an AT (or an non-visual UA) is going to
benefit from that information, is it?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'