- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 3 Feb 2005 18:02:56 +0000 (UTC)
On Thu, 3 Feb 2005, Matthew Raymond wrote: > > There's nothing in WF2 that requires a fundamental rewrite of existing > HTML documents. Assuming most WF2 documents will be created from scratch > is not a safe assumption. If the majority of WF2 documents are existing documents, then we will have failed. It would mean that in the lifetime of the spec, more documents were created before WF2 and then upgraded to WF2, than were created after WF2. I don't think we should be designing the spec on the assumption that nobody will use it in new documents. > > There is no existing content. Authors would just do: > > > > <idate name="date"/> > > > > ...or some such, and be done with it. > > First of all, why would they do such a thing unless they specifically > didn't care about legacy browsers? Why do authors not include alt="" text? Why do they not support browsers where JS is disabled? Why do they use IE extensions that don't work on non-IE browsers? Why do they target 800x600 displays instead of being device-independent? Why do they use <font size="5"> instead of <h1>? > Furthermore, WF2 user agents will have little initial marketshare, so > why would someone target them and leave out legacy support? We have to at least plan for the eventuality of WF2 UAs not being in the minority. Designing the language on the assumption that it won't be used much seems rather defeatist (and self-fulfilling). > Furthermore, although the markup doesn't have a built-in fallback, > neither does <datalist> or the |data| attribute. In both situations, you > can have critical content that you potentially can't use in legacy > browsers. <datalist> is never critical. It's an non-exclusive auto-complete list. Take the Google search field. Google's "suggest" version is the form with the <datalist>, Google regular is the form without. Google regular isn't missing any critical functionality. > If they're new websites, marketshare should force most webmasters to add > legacy support. Anyone remotely serious about legacy browsers is going > to put it in anyway (especially since it only takes one <input> > element). And those that aren't? (Like those that don't support Lynx, Netscape, Opera, etc, today?) > > > The only issue here is whether or not a grandfather or soccer mom > > > who knows virtually nothing about legacy support would put in the > > > proper legacy content. For these individuals, you simply write a > > > tutorial that tells them to do something like this: > > > > > > | <idate><input name="date" value="2005-01-31"></idate> > > > > > > This can be explained to the user easily enough: "Pretend you're > > > going to enter the date as text, then slap <idate> tags around it." > > > It's not rocket surgery. > > > > But it's more complicated than the current text, which works for both > > new and old browsers. > > Assuming that the default for an <input> with an unidentified |type| > attribute is text, which is not specified in the HTML 4.01 spec. So, in > theory, there may be browsers out there that will drop <input > type="date"> entirely, in which case there is no fallback. Yes, but let's concentrate on the real world instead of the theoretical. (And actually, it is defined, albeit informatively. See HTML4 B.1, third bullet point.) > > Sure, the fallback isn't as ideal when the author is trying hard to > > provide fallback, but (as described elsewhere in this thread) I simply > > don't see that these particular features (date) will be interesting to > > authors of that caliber. > > I think I can come up with a few features: > > 1) Localization - Date is always formatted in a way the user understands. > > 2) Stability - Webmasters don't have to worry about DHTML date controls > crashing on WF2 user agents. > > 3) No Javascript - The date control will still work, even when the > browser has Javascript turned off. > > 4) Speed - A hardcoded widget will work faster than a DHTML version and > require less memory on the host system. None of these would matter to a "category 1" author (those who today use a simple text field, often with no format hints), which is the context in which I wrote the above comment. > > I still don't understand what is wrong with the short amount of > > black-box JavaScript I proposed. > > Another opportunity for a list! > > 1) It didn't deal with default date values. Where would the script get > the format string from if it wasn't in |value| attribute? It could easily be adjusted, for example to take it from a title attribute or even have it hardcoded based on the type of the control. Alternatively, if you're generating the page in the first place (which you'd have to if you were going to prefill the value attribute to something) then you might as well generate different pages for HTML4 UAs as WF2 UAs. This isn't required, but is an option some authors might prefer in this context. > 2) It relied on a empty <span> element, which doesn't validate under > HTML Strict. I really have no idea where you get this from. There's nothing wrong with an empty <span> element. > 3) With Javascript turned off, you have the problem of having to select > and delete the format hint text in some situations. This is not a big deal. > 4) New webmasters, who don't understand how the script works, will > easily break it. I'm sure if they can manage 100+ line drop down menu scripts, they will be able to handle this kind of script. > 5) The script takes up nearly as much space as the HTML! Why is this a problem? (Especially considering we're talking about (a) an overly-designed script which could easily be simplified if it didn't have to be Jim-Ley-compliant, and (b) an overly-simply HTML page designed only to demo the script.) > By contrast, my modified version using <idate> probably cut the size of > the demo web page in half and supports the same features. ...with a large number of problems you have not addressed. > > It handles more cases than your proposals with no work on the UA > > implementor's behalf. > > Well, there's certainly not much of a case for that if you consider > typing to be the work in question: > > | <input type="date" name="date1"> > > | <idate><input name="date1"></idate> I said the UA implementor, not the author. > The best <input> can hope for is beating <idate> by three characters. If > you add scripting into the picture, <input type="date"> immediately > takes longer to type. Given the other problems with both proposals, the respective lengths of markup is largely irrelevant. More elements is a problem, more attributes too (although less so), but the length of tag names is irrelevant. > > Not to mention that many of the authors who fall into this "1" > > category simply don't provide formatting hints at all. > > I want to see three URLs for examples of webmasters using textboxes for > dates but not providing any kind of formatting hint anywhere on the > site. See: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/001247.html Most people do provide hints, but many don't. > > > nor did you explain how to handle legacy sites that use <input> + > > > DHTML solutions. > > > > That would be category 3 below. > > What's your point? If <idate> easily handles category 3, then it's a > more complete solution than you're offering. It doesn't. For category 3, you don't need declarative fallback, because imperative fallback works fine. > I don't feel you've made your case. It may not be as simple in the best > case scenario as <input type="date>, but it's still pretty darn simple. > It's a lot more straight-forward in handling formatting hints than your > demo script. It's a lot more effective in allowing legacy fallback. I guess I don't feel like you've made your case either. :-) > > > > 3. Complex JS widgets, for which declarative fallback is not > > > > needed. > > > > If they have complex JS widgets, they can implement the fallback in JS > > trivially. That's what I menat by "_declarative_ fallback is not > > needed". > > Javascript must be loaded and executed on all browsers unless it's > content the browser recognizes as fallback. Therefore, with <input > type="date">, a script will always have to be loaded and run regardless > of whether or not the UA supports WF2. And you yourself have shot down > any means of WF2 support detection. Detecting whether a UA supports type="date" is easy (I do so in the demo script). I don't really see what you mean here. > By contrast, <idate> can be used to prevent execution of a script: > > | <idate name="date1"> > | <script type="text/javascript" src="datepicker.js"> > | </idate> I hadn't realised that you meant <idate> to somehow affect script execution. That is definitely not happening. UA implementors have spent many an hour complaining about such required behaviour in specifications. > > > > ...not to mention the extra complexity and the implementation > > > > difficulty compared to just using a new "type". > > > > > > Elements like <idate> are identical to <input> with respect to the > > > widget they use, and they have the same attributes that <input > > > type="date"> would have without adding additional ones. > > > > Yet they have a host of differences: They don't appear in the > > .elements array in legacy clients, they don't automatically get > > support for things like autofocus when UAs implement that, all kinds > > of event handling happens differently for legacy UAs than new UAs, etc > > etc etc. > > I'm not following you. HTML 4.01 compliant legacy clients ignore > unrecognized tags. WF2 clients will still be able to perform new event > handling, et cetera, on <idate>. If <idate> isn't supported on a "WF2" > client, then attributes can still be placed on the <input> (and, in > fact, <input type="date"> could be used in fallback, with its WF2 > attributes being inherited by <idate> on fully-compliant WF2 browsers). > Can you give me a specific problem or conflict? <idate> doesn't appear in the .elements array, so index-based dereference of .elements will be different in different UAs. Not a problem if we reuse <input>. Support for new <input> attributes would be easy if all the new controls were <input> elements, yet will be hard if they are not. Event targetting and bubbling will be different if the UA supports WF2 vs supporting <idate>, so scripts will have to check which is being used before registering event handlers. And so on. > > > Could you provide a use case where implementation would be an issue? > > > > I have no idea what you mean by this. > > Can you give a specific situation where the way I've specified <idate> > would cause a problem for implementation of <idate> as part of WF2? <idate> could be _implemented_. It just would take longer. > > > If the user agent vendor doesn't want to implement the inheritance > > > part of the spec > > > > See, part of the problem is that it _has_ an "inheritance" part. It > > just isn't simple. > > How so? I could write Javascript that could copy attributes for a > child to a parent. Attribute propagation is a bitch to get right. You have to handle all kinds of dynamic updates during DOM manipulations and so on. > > > Now, I suppose a user agent might implement the non-inheritance > > > version of <idate> without rendering the legacy content for > > > inheriting markup, but why would any sane developer (aside from > > > Microsoft, perhaps) do this? (I thought about an "inherit" attribute > > > or something, but the only real use for this is to help user agents > > > without inheritance support find elements that use inheritance.) > > > > It has nothing to do with sanity. Why would any sane developer > > implement the CSS parser incorrectly? Why would any sane developer > > screw up the implementation of absolute positioning, or margin > > collapsing, or whatever? > > I was under the impression we were providing our own HTC solution for > Internet Explorer. In that case, we'd implement it correctly. Just like "we" (as in, Opera, Mozilla, and Safari implementors) have implemented CSS and HTML and DOM "correctly"? You can't assume that UAs will implement everything correctly the first time, and so you can't design fallback behaviour on the principle that the UA will not screw up something, especially when that something is complicated. > If WF2 was to become popular enough for Microsoft to consider > implementation, then breaking various sites caused by Microsoft's > incorrect implementation would either result in an outcry that would > force them to correct it, a major exodus from IE, or mass numbers of > people refusing to upgrade their browsers to the newest IE version. You have much more faith in people than I do. > It just doesn't make sense. If Microsoft wants to directly sabotage WF2, > they could just implement a slightly different competing standard, and > they would have to mess with the inheritance of <idate> at all. Nobody is talking about sabotage... > > > Perhaps the best solution is to leave <input type="[timeunit]"> in > > > the specification, add <idate> and it's siblings, and let the best > > > element win in the implementation phase. Besides, there's no reason > > > the two can't coexist, and they'd very likely share a lot of the > > > same code. > > > > That's tantamount to the way UI developers who can't make their mind > > up throw in a pref. "Let the user figure it out." > > Or perhaps it's like <input type="button> and <button>. Two similar > solutions that each have their own benefits under certain conditions. <input type="button"> is a mistake, and only supported for historical reasons. There are no historical reasons when it comes to new controls. > > > Just thought of something. In XHTML, <idate> would actually take up > > > less space than <input> when no legacy content is used: > > > > > > | <input type="date" name="date1"/> > > > > > > | <idate name="date1"/> > > > > The _huge_ difference here being that the former has legacy fallback, > > and the latter doesn't. That, for me, is a blocker. > > The problem is that the former provide next to no legacy fallback, where > as the latter can provide whatever fallback you want. Ideal fallback for > the least likely approach to date input is pointless. It's almost as bad > as introducing a new element without the ability to provide fallback. Next-to-no fallback is better than theoretically-good-yet-absent fallback. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 3 February 2005 10:02:56 UTC