[whatwg] Re: several messages

[Matthew Raymond]

Ian Hickson wrote:
> On Thu, 27 Jan 2005, Matthew Raymond wrote:
> 
>>>1. A proposal to control the submission format for WF2 UAs.
>>>
>>>I disagree that this is desirable. The whole point of having a type is 
>>>that it means we can all standardise on a single, reliable, 
>>>unambiguous, easy to parse, standard submission format.
>>
>>It also means that you can't simply whip up a page that uses WF2, you 
>>have to alter the server to support ISO8601. This may not be possible.
> 
> I find it very hard to believe that this would be a common problem.
> 
> Supporting ISO8601 is pretty easy. It's one of the simplest date/time 
> formats to parse.

    It still means that the webmaster has to alter all server-side 
scripting involving dates/times. What happens when you hired an outside 
group to setup those scripts, but your HTML is in-house?

> And yes, it means you can't write a page and have it submit to someone 
> else's server if they don't support ISO8601 yet. That is an edge case. I 
> really don't think we need to support that. It certainly doesn't deserve 
> so much attention that all UAs should support it and the model should be 
> made more complicated for everyone else.

    Only the implementation of my <format> concept is more complicated. 
People can still use your way if they so choose.

>>>Having a single format means libraries can be written that can then 
>>>just be used directly, instead of having to handle dates individually 
>>>for each site as we do now.
>>
>>I fail to see why it would be so difficult to create a library that 
>>converts an ISO8601 date or time into a custom time using a strftime 
>>formatted string. If it's so bloody hard, I'll write it for you.
> 
> I'm not sure what you mean. I was referring to the fact that if all UAs 
> submit dates and times in ISO8601 format, then libraries like CGI.pm can 
> simply have methods that convert incoming dates and times into appropriate 
> types before the site-specific server-side code processes it.

    Why would they need the format converted at all. The whole concept 
behind <format> and the like is that it sends the data in a format the 
servers ARE ALREADY USING. There is no conversion on the server side, 
only validation, which they should be doing in the first place, and even 
if the validation doesn't work perfectly on the server, it only has to 
work on the correct format, which a WF2 UA will send. There is no 
argument here. It's an illusion.

>>>The most common suggestion is an element that would not render in UAs 
>>>that supported the new input controls but would in legacy UAs.
>>>
>>>Unfortunately, this makes some assumptions that I'm not sure we can 
>>>make. For example, it assumes that a UA either supports all of the new 
>>>date/time input types as well as the <format> element, or it supports 
>>>none of them.
>>
[Snipped my confused response.]
> 
> Nothing to do with strftime formatting (indeed I'm not sure where that 
> comes in). I meant cases such as:
> 
>    <p> <input type="date"> <format>...</format> </p>
>    <p> <input type="time"> <format>...</format> </p>
>    <p> <input type="datetime"> <format>...</format> </p>
>    <p> <input type="month"> <format>...</format> </p>
>    <p> <input type="week"> <format>...</format> </p>
> 
> ...in a UA that only supports type="date" and type="time". What will get 
> displayed?

    That's fixable by simply having the UA treat <format> as a simple 
<span> whenever it's not associated with a datetime-like format. The UA 
would then product the desired legacy fallback.

>>>Given past experience with the way UAs implement specs a bit at a time, I
>>>really don't think this is a good assumption.
>>
>>Please provide a use case for my most current proposal where this would be
>>a problem.
> 
>    <p>Please insert the date: <input type="date"> <format> DD MM YYYY </format> </p>
>    <p>Please insert the time: <input type="time"> <format> HH MM </format> </p>
> 
> ...in a UA that only supports type="date".

    Well, first of all, stop with the not associating <format> with its 
control. Second, if <input> is not a type that supports <format>, then 
format would be rendered as I suggested above.

> The reason <format> is being proposed (as I understand it) is to help with 
> migration. Once all UAs support the new types, assuming we're lucky enough 
> to ever get there, <format> will no longer be useful. In the meantime, 
> though, we will have UAs that support some types and not others.

    Where "others" would mean formats you can't create with the <format> 
element, which would be few if any. If I'm mistaken, please provide 
examples.

> So any 
> solution we have has got to be able to handle that -- and ideally, without 
> any work on the UA implementor's part, because it is the fact that the UA 
> hasn't finished his work that leads to this problem in the first place (so 
> we can't give him more work and expect that to address the problem).

    So what you're saying is that UA implementors are going to implement 
half of the WF2 system with regards to dates and times, but not the 
other, when they know for a fact that it will cause problems just by 
reading the specification they're implementing. So, who is this vendor 
who's not going to implement the who date/time solution, and why should 
we care if they don't, considering in all likelihood they aren't going 
to have any real marketshare to begin with?

>>>I also am not too happy about the idea of introducing an element 
>>>purely for the purpose of hiding content from new UAs -- effectively 
>>>deprecating the element straight away.
>>
>>It does more than just provide fallback content. For one, it provides 
>>the submission format for WF2 user agents.
> 
> If we were to have a way to change the submission format, it would be 
> using an attribute on the <input> element. It makes no sense to have it on 
> another element.

    Unless you want the fallback formatting hint, which you can't put in 
the |value| attribute because you may need |value| to (surprise!) put an 
actual value in it. Also, if you haven't noticed, we're creating an 
<input> element with so many attributes that it can easily take up three 
lines in a text editor with the word wrap turned on.

>>Another thing is that, in theory, a WF2 UA could use the submission 
>>format as the one they display to the user, and either display the 
>>content in a manner similar to legacy clients or simply display the 
>>content text as a tooltip.
> 
> "In theory" isn't really, IMHO, good enough reason to add a whole new 
> element at this stage in the process (if ever -- most of the elements that 
> we added at the start of the WF2 work which were added for theoretical 
> reasons have now been removed for practical reasons, in fact).

    The example was intended simply to show the semantic flexibility of 
<format>, not to justify its entire existence. As for considering ideas 
at this late stage, I was under the impression that until the 
implementation stage is reached, any valid idea would be considered. If 
not, they all you're really asking us to do is point out typos in the 
WF2 draft.

>>>Most of the JS was added at Jim's insistence, so as to degrade 
>>>gracefully in UAs with two or three users. Also, the code takes care 
>>>of the timezone problem (which <format> doesn't). It also handles 
>>>hiding the format just for supported types so it works with incomplete 
>>>WF2 UAs, and has graceful fallback in both WF2 and non-WF2 UAs when JS 
>>>is disabled.
>>
>>I was under the impression I had sent a modified version of your page 
>>that did exactly what you're talking about. (Then again, I didn't really 
>>get to test it...) And that was based on an outdated version of 
>><format>.
> 
> It didn't handle hiding the format just for supported types, which was one 
> of the main issues I had with your proposal.

    Again, easy to address, as shown above.

>>>I can't really see how to achieve that with <format>.
>>
>>| <format for="time1" value="%I:%M %p %z">
>>|   Format: hh:mm am/pm TMZ
>>| </format>
> 
> I hate to say this, but that's way too complicated. :-)

    I made the format string from a simple table on a webpage. The for 
is only there because <format> isn't inside the label. The format itself 
is complex, thus making the example appears complex. Here's military 
time without a timezone, with the <format> assumed to be inside the <label>:

| <format value="%H:%M">Format: hh:mm</format>

    Of course, that's pretty much ISO8601 time, so:

| <format>Format: hh:mm</format>

>>>>2) It uses a fallback method of displaying formatting hints that 
>>>>forces webmasters to learn Javascript, even when they may have 
>>>>little or no use for it outside of the date/time formatting issue.
>>>
>>>Not really, the code is generic and can be cut-and-pasted.
>>
>>So it's okay to make them use Javascript because someone else can do the 
>>work for them? And what happens if they have special needs your script 
>>doesn't address?
> 
> They don't _have_ to use the JS. If they want to, they can.

    They do if you want the <input> to have a value and the format hint 
hidden on WF2 clients.

> Certainly I don't see that providing JavaScript like in the demo is any 
> worse than the JS people provide now to do pulldown menus, or, for that 
> matter, any worse than asking them to understand the <format> example you 
> gave above. :-)

    If you give artificially complex problems, you'll get artificially 
complex answers. The <format> was designed to be complex only when you 
need maximum flexibility. Note again how simple a time hint can be:

| <format>Format: hh:mm</format>

>>>>3) It requires that you add the ISO8601 date and time format to your 
>>>>server's date/time parsing, regardless of whether you actually want 
>>>>people to be able to submit data to the server in that format.
>>>
>>>And <input type="file"> requires that you support multipart/form-data, 
>>>and using the <select data=""> feature requires that you use a 
>>>particular format, etc. I don't really see why that is a problem.
>>
>><select data=""> doesn't require modifying the server in any significant 
>>way. It merely requires that the file referenced in |data| be placed on 
>>the server. The <input type="file"> element, so far as I know, is 
>>already supported. I'm not really following you here.
> 
> <input type="file"> is supported _now_, but it wasn't when it was 
> introduced.
> 
> Yes, supporting type="date" et al will require changes on the server side. 
> It will also require changes on the HTML side, and probably on the CSS 
> side, and various other places. New technologies tend to require changes.

    Yeah, that's why most people power devices in their cards using 
adapters that plug into their cigarette lighters. My cell phone didn't 
require me to buy a new car.

> The key is that those changes can be made without making the page 
> completely useless (as useless as IE asking you to download the file, for 
> instance, as with XHTML), so that users with new UAs can use the file and 
> benefit from new features, while users of legacy UAs can use the file, 
> albeit in a sub-optimal way.

    I don't know where this is going. Are you saying that <format> 
doesn't degrade gracefully, and if so, how?

>>>>4) On legacy user agents with Javascript disabled or unavailable, it 
>>>>requires the user to delete the format hint when entering a new 
>>>>date.
>>>
>>>In most UAs the current value is selected when you tab into a control, 
>>>so that doesn't seem like a serious problem.
>>
>>Under Windows, if you're using the mouse to click the control, and you 
>>click between characters, the text will not be highlighted, forcing the 
>>user to perform further actions to delete the text.
> 
> Like double-clicking before you type. True. Again, not a huge deal.

    Actually, right now clicking on the text of your Date Control Demo 
in  Firefox isn't doing anything at all to select the text. /me shrugs.

>>>Also, as you say, it's only an issue when JS is disabled.
>>
>>Which is entirely possible in some environments.
> 
> Yes, but enough of an edge case that it shouldn't drive the development of 
> the spec, especially not to the point of adding a new element and all its 
> associated logic.

    Again, if the nation of WF2 is closed to immigrants, please say so.

>>If the page says I should submit using A, but I successfully submit 
>>using Z, I might assume that I can also submit with formats B through Y.
> 
> Why would you even try Z? And why would it be a problem? The moment you 
> try B or Y, it tells you it doesn't work. Where is the problem?

    Good point, other than the fact that there may be data loss in the 
process.

> No, I'm suggesting that supporting multiple formats is not a big problem, 
> in case they care enough to do so. The idea behind the date inputs is to 
> make it easier on the medium run, just like <object> makes things easier 
> on the medium run; not to solve the world's data entry problems overnight.

    You still have to overcome the problem of people not wanting to 
bother with WF2 because the cost of using exceeds the anticipated 
return. Requiring server-side alteration may be what tips the scales, 
especially when webmasters already have solutions, how ever flawed they 
may be.

> Many sites today just have a single text entry field without even 
> specifying the expected format (I listed some 30 or more a few months back 
> when we last discussed this in detail). These will be immediately helped 
> by the new input types, as the legacy case is not hurt at all, and new UAS 
> are helped.

    Actually, the easiest date entry system I could find is the three 
<select>s system, which <input type="date"> alone can't even touch. 
Plus, many of the systems that use text input supplement it with 
Javascript-based calendar widgets and the like, which will not disappear 
simply because the webmaster changed "text" to "date".

> In the middle complexity range we have sites that use groups of <select>s. 
> These are not likely to change to use the new types, as they don't offer a 
> great advantage over <select>s. Once most deployed UAs support WF2, then 
> medium-complexity sites like this may well start using the new date types.

    Assuming they bother to change at all. What reason do they have? If 
you have a <select> with values like "January", and two more <select> 
elements with two digit and four digit numbers respectively, then the 
format is obvious to anyone familiar with our 12-month calendar. 
Changing the markup would mean changing the server, and it would also 
mean a weaker legacy solution than what they already have.

> At the high end of the complexity range we have people with massively 
> complex calendar widgets. These sites mainly target only the top tier of 
> Web browsers. Once the top tier of Web browsers support WF2, or can be 
> made to support WF2 through JS or similar tools, then such sites could 
> well switch to using the new inputs, which would help users that can't use 
> non-accessible widgets like custom calendar controls.

    I don't think these sited represent the bulk of sites with date inputs.

> Authors of high-end sites won't switch to new features until they are 
> quite well understood. So immediate migration is not an issue.

    True.

> Authors of medium-complexity sites might switch earlier, but their 
> switching is not a big deal because their widgets are already pretty 
> accessible.

    Unless you make it reasonably painless to convert in the midterm.

> Authors of low-end sites might switch as soon as tutorials are updated, 
> which would give an immediate improvement.

    If they need tutorials, how are they going to alter their server 
scripts? ;)

> I don't really understand which level your <format> proposal is aimed at.

    The low-end mostly. However, I now prefer using my new version of 
<date> instead.

>>>>6) It may increase the difficulty of training people to use certain 
>>>>web apps within a corporation, because you must train them to use a 
>>>>different date format on legacy and WF2 user agents.
>>>
>>>The Web app can easily be written to use whatever format the WF2 UA 
>>>uses as its legacy format.
>>
>>You mean the server can use ISO8601 as the legacy format.
> 
> No, I mean the server can support ISO8601 and whatever the legacy format 
> is, which can be explicitly set up to be whatever the WF2 UAs display, so 
> that you don't have to train users in two different formats.

    You lost me. How does the app know what format the WF2 UAs will 
display? The whole point is that the control displays the local date format.

>>Again, you assume that the webmasters not only have access to the server 
>>configuration and scripts, but that they themselves would want to put in 
>>that kind of work just to support WF2.
> 
> The amount of work we're talking about is as much as trying to understand 
> how <format> works, along with debugging it when it is handled differently 
> in different UAs, IMHO.

    So, you mean if the UA vendors screw up their implementation, it 
will take more time for the webmasters to figure out how to get around 
the bugs. The formatting is pretty straight-forward, so implementation 
bugs are the only real issue here.

[Snipped bad multiple <format> example.]
> Um... We've gone from:
> 
>    <label>New meeting date:
>     <input type="date" name="meetdate" value="2005-01-30">
>    </label>
> 
> ...to a multiple-dozen line monster, just to support backwards 
> compatibility in a case where most authors are just going to support one 
> or the other anyway?

    That's why I like my <date> solution better.

> I'm sorry, but the extra level of complexity there is completely out of 
> proportion with the problem you are trying to solve.

    Again, see <date>.

>>But that's just it. There is no automatic support. You used JS, DOM and 
>>a <span> trick that's probably invalid under HTML 4.01 strict.
> 
> Of course it's invalid HTML4 Strict. It uses new form types.

    So "<span></span>" is valid in HTML5 Strict???

>>A hacked solution is NOT better than a markup solution, especially if it 
>>doesn't work as soon as Javascript isn't available.
> 
> It does keep working, just slightly less well.

    Only in the limited confines of your example.

> The important thing, though, is that it doesn't rely on implementors 
> having implemented the fallback element correctly.

    What about my system requires that? All they have to do is not use 
the |value| attribute of format, and it defaults back to ISO8601. In 
your system, however, they don't even have the option of another format, 
so you're using the fear of poorly written markup as an excuse to 
prevent new markup entirely.

> The point is to replace JS hacks so that in newer UAs things can work 
> declaratively. We're specifically targetting older UAs here.
> 
> It's also quite clear from the Web that using JS is not a blocking problem 
> for most authors (especially when it can be done without looking at the 
> code and without anything breaking when JS is disabled).

    What's your point?

>>>However, I don't really see how inventing a whole new element just to 
>>>have legacy UAs handled here is the way to go.
>>>
>>>Effectively, <format> is the same as <nodateinput> (c.f. <noframe>). 
>>>I've never been a fan of <noframe> (and <noscript>).
>>
>>Not true. You can use format without any contents to simply define the 
>>submission format.
> 
> If that was something we wanted to address, it would be addressed by an 
> attribute on <input>, not a new element (we don't have <min>, <max>, 
> <step>, etc, either).

    Yes, we could drop fallback formatting hints all together and add 
one more attribute to the massive pile of attributes we already have.

>>The contents are no different than the contents of <object>.
> 
> ...except that once you remove the submission format thing, which IMHO is 
> trying to solve a different problem, you end up with never using the 
> fallback in a compliant UA, and the element being effectively 
> <nodateinput>.

    That depends on the UA. If they choose to use the <format> element's 
|value| as the display format, they could still render the hint inline 
or use it as a tooltip.

> Note that while <input type="date"> is a significant step up from either 
> <input type="text"> or the complex JS-based or image-map-based calendars 
> of today, it is _not_ a significant step up from <select>-based date 
> input, at least from an accessibility point of view.

    Which is why people using <select> elements may never use <input 
type="date">...

> If you are concerned enough to target legacy UAs with a multi-control 
> solution, then just use that for WF2 UAs as well.

    What happened to local date formats? If they're so unimportant, why 
not just use |pattern| to format a textbox?

>>I notice you didn't comment on the use of <date>/<time>/<datetime>.
> 
> I think it's a good idea. It'll probably be in WA1.

    I don't think that's good enough. If you do that, WF2-compliant 
browsers that don't use WA1 may display date formats that are 
inconsistent with the local date format displayed in controls.

>>If the users see dates/times in the <input type="date"> control that 
>>conflict with their native date/time formats, won't that cause 
>>confusion?
> 
> I don't follow.

    If you have "01/05/05" in a paragraph just before a date control 
with "05/01/05", where both dates are 2005-01-05, you wouldn't find that 
confusing?

>>|   The meeting is currently being held on
>>|   <date value="2005-01-30">January 30, 2005</date>
>>|   at <time value="11:00:00.0Z">11:00 PM</time>.
> 
> That seems fine.
> 
>>| <form>
>>| <label for="meetdate">New Meeting Date: </label>
>>| <input type="date" id="meetdate" name="meetdate" value="01/30/2005"
>>| min="2005-01-25" max="2006-01-30">
>>| <format for="meetdate" value="%m/%d/%Y">Format: mm/dd/yyyy</format>
>>|
>>| <label for="meettime">New Meeting Time: </label>
>>| <input type="time" id="meettime" name="meettime" value="11:00 AM">
>>| <format for="meettime" value="%I:%M %p">Format: hh:mm AM/PM</format>
>>| </form>
> 
> Having value be in a different format that min and max seems confusing. 
> Having value not be in a single standard format seems bad (e.g. for 
> automated validation, not to mention implementation).

    This is a byproduct of using the element for both WF2 markup AND 
legacy markup, which is why I now like my new <date> better.

>>So, really, we just need to specify in the formatting hint that the 
>>meeting time is Norway local time.
> 
> Meetings should be scheduled with input="datetime", not separate date and 
> time controls.

    Fair enough.

>>| <dateinput id="date" value="2005-01-30">
>>|  <range min="2005-01-25" max="2006-01-25">
>>|  <submit name="month" format="%m">
>>|  <submit name="day" format="%d">
>>|  <submit name="year" format="%Y">
>>|  <!-- Fallback content -->
>>| </dateinput>
>>
>>   Or, for WF2-only solutions:
>>
>>| <dateinput id="date" value="2005-01-30">
>>|  <range min="2005-01-25" max="2006-01-25">
>>|  <submit name="date">
>>| </dateinput>
>>
>>This provides PERFECT fallback content, and lacks most of the 
>>disadvantages of <object> while having all its strengths. In fact, I've 
>>half talked myself into using this format just having typed it right 
>>now...
> 
> ...or, in current WF2:
> 
>    <input type="date" value="2005-01-30" min="2005-01-25" max="2006-01-25" 
>           name="date">
> 
> ...with no fallback apart from a text field prefilled with a date in the 
> expected format.
> 
> Let's please keep things at least somewhat simple.

    Your example isn't entirely the comparable:

| <input id="date" type="date" value="2005-01-30" min="2005-01-25"
|        max="2006-01-25" name="date">

    If you drop the |id| and use my new <date>, you get this:

| <date id="date" value="2005-01-30" min="2005-01-25" max="2006-01-25">
|  <submit name="date">
|  <input id="date1" name="date" value="2005-01-30">
| </date>

    Considering it has ALL the values of your <input> and can produce 
identical legacy code with minimal additional markup, it doesn't really 
look that complex to me. Drop the goodies and you get this:

| <date value="2005-01-30">
|  <submit name="date">
|  <input name="date" value="2005-01-30">
| </date>

    Is this to complicated compared to the likes of <object>?

>>Here's where we make a hard left turn into the Twilight Zone. Suppose, 
>>simply by adding a special <submit> child element, you can turn mild 
>>mannered <date> into a full-blown date control:
>>
>>| <label>Event Date: <date><submit name="date">2005-01-30</date></label>
>>
>>So if you wanted a date control with ISO8601-compliant fallback content, 
>>you'd do this:
>>
>>| <label>Event Date:
>>|  <date value="2005-01-30">
>>|   <submit name="date">
>>|   <input name="date" value="2005-01-30"><br>(Format: yyyy-mm-dd)
>>|  </date>
>>| </label>
> 
> This means authors _must_ think of fallback content, instead of the form 
> control just turning into a text field when the author forgot about the 
> users stuck with old browsers.

    Dude! This is the fallback for the above example they need to make 
it AT LEAST as powerful as <input type="date">:

|  <input name="date" value="2005-01-30">

    And what if there is no need for an |id| or default |value|?

|  <input name="date">

    And the difference here is that while the HTML4 spec doesn't define 
the type of an <input> with an invalid |type| attribute, it does define 
it for when there is no |type|: "text". If the UA drops <input> elements 
with |type| attributes it can't identify, your solution won't even work 
it that UA, in spite of the fact that it might be a perfectly compliant 
HTML4 browser.

> It also means using at least two elements over three tags instead of just 
> one with a couple of attributes.

    Considering it does significantly more, including definition of 
format, the ability to send multiple values to the server and perfect 
legacy markup, why should this be a surprise?

>>PROS:
>>* A single element is used for all dates/times in all circumstances.
> 
> I don't see why it's a good thing that inputs and outputs share one 
> element. (I originally had <input type="output">, which would have had 
> better backwards-compatibility, but now WF2 has <output> because 
> fundamentally the two things are different, even if one would be better 
> for back-compat.)

    So long as inputs have initial values, they're outputs as well. 
Besides, when something says "date", you know it's associated with date. 
  When something says "input", would you associate that with "output". 
It's a contradiction. If the inputs and outputs are all dates, then 
"date" isn't a contradiction, an you can tell them apart just by looking 
for <submit>.

>>* Near perfect graceful degradation, especially when you want multiple 
>>legacy controls.
> 
> Only if the author thinks about it. Otherwise you input control either 
> disappears or gets rendered as only text in legacy UAs.

    Exactly the same scenario with <object>. However, as I have shown, 
one simple line of legacy markup provides the same functionality as 
<input type="date">, so what you're really talking about is your fear 
that webmasters will intentionally screw legacy clients, and that would 
only really happen if WF2, and <date> by association, became popular 
enough to gain marketshare.

>>* Submission formatting for the server is highly flexible, eliminating 
>>the need for changes to the server to accommodate WF2 in most cases.
> 
> I'm not convinced that's a problem that needs solving.

    Others are not as convinced (including me). Your solution doesn't 
solve the three legacy <select> controls problem. It requires server 
alteration. It doesn't provide effective formatting hints. My solution 
solves ALL of these problems.

>>CONS:
>>* Not quite as simple as <input type="date">.
> 
> This is, IMHO, a big problem. The current solution allows type="text" to 
> be changed to type="date" easily, to address usability issues on low-end 
> sites very quickly.

    Look at my examples. If you remove the WF2-specific stuff, half the 
work is typing "<date><submit></date>" and the other half is cutting and 
pasting from the old <input>:

| <date>
|  <submit>
| </date>

    ...plus...

| <input type="text" name="date" value="2005-01-30">

    ...equals...

| <date value="2005-01-30">
|  <submit name="date">
|  <input name="date" value="2005-01-30">
| </date>

    You could write a macro to do this! Furthermore, supporting an 
existing legacy solution is cut-and-paste. The single hardest part is 
the |format| attribute, and that's only to avoid altering server-side 
scripting. And how would you do date selection for a list of dates where 
you want the dates displayed in the local format?

| <label>Event Date:
|  <date list="datelist"><submit name="date"></date>
|  <datalist id="datelist">
|   <select name="date">
|    <option selected>2005-01-28</option>
|    <option>2005-01-29</option>
|    <option>2005-01-30</option>
|   </select>
|  </datalist>
| </label>

    Versus your solution:

| <label for="date">Event Date:</label>
| <input id="date" type="date" name="date" list="datelist">
| <datalist id="datelist">
|  <select name="date">
|   <option selected>2005-01-28</option>
|   <option>2005-01-29</option>
|   <option>2005-01-30</option>
|  </select>
| </datalist>

    Nearly the same amount of markup, but my solution degrades to a 
<select>, whereas yours degrades to a <select> and an <input> with the 
<label> being associated with the textbox and not the <select>.

    Try any other problem of significant complexity and you run into a 
similar scenario: <input type="date"> can't compare to <date>.