- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 31 Jan 2005 14:55:18 +0000 (UTC)
On Fri, 28 Jan 2005, Matthew Raymond wrote: > > > > 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? The same as if you need to upgrade any other aspect of the system. You bring them back in. > > 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. Implementation is a big issue here. :-) And complexity is a problem even when authors aren't required to use it -- just the fact that the documentation is complicated often scares people away. (This is why I'd like to make the repetition model stuff simpler, but unfortunately I can't really see how without losing significant features that have been requested by people writing pages with it.) > > 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. The servers are probably using time_t or similar formats, internally. That's the "appropiate type" I'm talking about. Whatever is submitted, it needs to be converted at some point into something the server can use natively, even if that is just converting a string of ASCII digits into a 32bit integer. > > 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. Now you're requiring that the implementators spend even more time trying to implement an even more bug-prone algorithm, purely so that the page will render slightly better in legacy UAs. This is a recipe for disaster. The fallback mechanism needs to be brain-dead-simple to implement, otherwise UAs _will_ get it wrong. If even a single UA gets it wrong, the entire fallback mechanism is useless for everyone, since it will no longer fall back correctly. Look at <object> for an example. <object> is basically unusable in its full nested glory, simply because WinIE6 doesn't properly support it. And <object> isn't even that hard. With your <format> idea, there are mutiple attributes and elements depending on each other. Every time the DOM is changed, the dependencies need to be rechecked. It can't easily be implemented in CSS, so there has to be code dynamically updating the styling engine as things are changed in the DOM. And so on. > > <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. Why? Do you expect authors to do that correctly? > Second, if <input> is not a type that supports <format>, then format > would be rendered as I suggested above. I hope I have explained why this, while theoretically possible, is prone with problems in practice and would not be a good design. > > 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. I meant merely the same as in the previous example, you will have UAs that support type="date" and not type="time"; or type="datetime" and not <format>, or that support a mixture in a buggy way, etc. > 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. Yes. This is what has happened for every single other specification implemented by Web browsers since before the W3C started, in every user agent, and I see no reason for that to change now. > 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? Well, I know of at least one (not yet shipped) implementation today that supports type="time", but not <format>. Even if <format> was added to the spec, there's no guarentee that the UA would support it before shipping. This isn't through malice, but simply because ship dates are not generally related to implementation status. This particular implementation is not a reason for me to be reluctant to add <format> to the spec. However, the fact that the proposal depends on correct implementation in the first release of all WF2 UAs _is_. > > 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. IMHO the two are very distinct. Changing the submission format is a totally different ball game than showing fallback hints. > 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. I don't see how this is a problem. > 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. I'm considering it, no? :-) But yes, as I mentioned last month (and as the document's status section says), we've reached the stage where final changes are being made before the spec is either submitted to a standards organisation or released as a call for implementations. > > > 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. For clients that don't support WF2, and have JS disabled, on forms where the control already has a value, the value itself is a good enough hint (since it is in the unambiguous ISO8601 format). (This is quite an edge case, btw.) > > 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? I'm just repeating that <format> is too complex to implement given that even without it, the new controls degrade acceptably. > > > > 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. I have no idea to what you refer here. > Actually, the easiest date entry system I could find is the three > <select>s system, which <input type="date"> alone can't even touch. You're assuming that we're trying to replace the three-select case. Existing Web pages that use <select> work fine. They don't have an accessibility problem, they are usable. There's no reason for Web authors to replace them. > 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". They won't disappear at all while WF2 UAs are not widely used. I wouldn't expect sites that have deployed JS calendars with hundreds of hours of testing invested in them to switch for the sake of switching, even if WF2 UAs get widely deployed. If WF2 UAs gain useful levels of marketshare, then _new_ sites may consider using type="date" etc instead, once supporting old UAs is no longer useful. > > 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? I didn't say they'd change existing sites. I meant that they may _start_ using them, in new sites. > > 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. I agree. > > 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. But the point is there is no reason for them to convert such sites at all. > > 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? ;) Same way they wrote them in the first place. More tutorials, probably. >> 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. If you are aiming at the low end, then your proposals are way too complicated, IMHO. Many of the low end pages don't even show hints at all, at the moment. I'm not sure the authors of these sites particularly care about fallback behaviour, usability, etc. > > > > > 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. We're in the context of a single corporation here, odds are very high that the format will be the same in all WF2 UAs. The IT staff just have to hard code that 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. I mostly have only been talking about implementation bugs, yes. > > > 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??? ??? It's valid in any version of HTML. I don't follow. Why wouldn't it be valid? > > 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 of it. You rely on implementations not showing <format> in some specific cases. That's the entire point of your proposal, as I understand it. The <date>/<time>/etc case with <submit> is even more complicated as far as depending upon correct implementation is concerned. > > 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">... Indeed, at least not until type="date" is very widely supported. I do not see this as a problem. We're not trying to get authors to use WF2 for the sake of using WF2. We're just trying to give authors better options for some of what they are doing. > > 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? Because type="date" etc give you a better UI. It's a better UI than three <select>s as well, where supported. However, until it is supported, the three <select>s solution is good enough, and people using it need not change. It's the people _not_ using three <select>s who are most able to benefit from type="date" etc. > > > 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. Putting it in WF2 doesn't in any way guarentee that UAs will support both type="date" and <date> at the same time. Putting <date> in WA1 doesn't guarentee that UAs that support WA1 will render <date> in any sort of localised way either, all it really does is give the CSS something to hook to when CSS is updated to support formatting date and time strings. > > > 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? I would find "01/05/05" and "05/01/05" confusing even if I found them on their own. > | <date value="2005-01-30"> > | <submit name="date"> > | <input name="date" value="2005-01-30"> > | </date> ...which is three elements for what should only need one. > Is this too complicated compared to the likes of <object>? It's probably about on par, which bodes badly given how badly <object> is implemented. > > > | <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"> ...so? Here is what you need to do the same in WF2: <input name="date" type="date"> ...including fallback and everything. Sure, it isn't perfect (it doesn't show the format, for one). If you want more, you can get more, during the (admittedly probably long) transition period, by using some JS. But once you don't care about legacy UAs, you can use very simple markup, and _it will still degrade in legacy UAs_. > 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. Thankfully, none of the UAs people actively use have that problem. (In fact I'm not aware of any UAs at all that have that problem, although I wouldn't be surprised if there were some.) > > 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? It's not a surprise. It is, however, an important downside. > > 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>. That isn't anywhere near as easy as you might imagine. For example, it requires the UAs to do a whole _bunch_ of work if someone inserts a <submit> element into the <date> element dynamically. I can guarentee you that that would be buggy in multiple UAs for some time if we went that route. Indeed you may notice that as a whole I have avoided adding any features to any of the WHATWG drafts that require that an element immediately change behaviour based on its contents changing. If there are interdependencies, they are defined in terms of algorithms that run at specific times. > > > * 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>. Or as with <img>. I think the _massive_ misuse of alt="" should raise a red flag here -- if we depend on the authors to do the fallback work, it _will_ fail. > 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. Well, we have to at least _plan_ for that eventuality... > > > * 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. I don't see that it is a problem. Why is it a problem? > It requires server alteration. If you are changing existing systems to use WF2, yes. I don't see that this is a problem, since you're going to have to change the HTML as well, not to mention the stylesheet and the JavaScript if you have any. And it is likely that the server is what is generating all these. > It doesn't provide effective formatting hints. True, to obtain formatting hints you have to use some JavaScript. > My solution solves ALL of these problems. ...and introduces a host of others: * Poor-to-nil fallback unless the authors thinks about it. * Multiple elements instead of one. * Very complex implementation with interdependencies between elements. * A requirement that WF2 UAs implement the spec correctly for fallback to work correctly. > > > 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! I could. My dad, who writes HTML forms, probably couldn't. But he could easily change "text" to "date", and he wouldn't even need to change his server-side script since all his script does is echo the values to an e-mail. > And how would you do date selection for a list of dates where > you want the dates displayed in the local format? [...] list="" is not the way to do that. list="" merely provides an autocomplete list, it doesn't restrict the values you can pick. I'd probably do it with radio buttons and <date>s for the labels. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 31 January 2005 06:55:18 UTC