[whatwg] Re: several messages

[Matthew Raymond]

Ian Hickson wrote:
> 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.

      That assumes significant continued growth of Internet content.
Perhaps you have figures I don't, but there would have to be some pretty
substantial growth to justify weak legacy support.

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

    Not a fair question, considering the ratio of <img> elements to date
inputs. Poorly designed table-based layouts can have hundreds of images
on one page.

 > Why do they not support browsers where JS is disabled?

    That's not a matter of leaving something out. That's a matter of
designing a page that requires minimal functionality. Some pages simply
can't be fully functional without Javascript. Granted, a good portion of
those pages could be made accessible with some work, but some can't. For
instance, I once saw a page where you could move a bird or the sun
around, and the shadow of the bird would change places accordingly. In
the best of circumstances, that would only be three static images on a
Javascript-disabled user agent.

 > Why do they use IE extensions that don't work on non-IE browsers?

    Similar situation to Javascript. They want a specific feature, they
learn about one in IE, and they use it because most people have IE.
That's not the same as leaving support out. No legacy content in <idate>
is a pure decision not to include content. You're trying to confuse the
issue by citing examples that lack such purity.

 > Why do they target 800x600 displays instead of being
 > device-independent?

    Because it's a problem not immediately obvious at the markup level,
and because it requires significant effort and thought on the part of
the designer in some cases. Imagine trying to convert Amazon.com into a
standards compliant page that can easily be viewed on your cell phone's
browser. Does that sound as easy as <input name="date1">? It's not even
remotely the same level of difficulty.

 > Why do they use <font size="5"> instead of <h1>?

    It's probably the editor they're using (since most of the <font>
stuff I've seen looks like it was added by something with the IQ of a
toaster). Poorly designed editing and server software is likely the
cause of most standards conformance problems on websites.

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

    But you've designed <input type="date> not be be used much until WF2 
becomes popular. The <idate> element has all the functionality of <input 
type="date">, and it was designed to be used in the majority of 
situations right now.

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

    That doesn't explain |data|. How do you propose to keep people from
using <select> elements that take all their data from a file and have no
options in markup? If the <select> is required, what happens on submit
when the user doesn't have an option to select? How are you going to
enforce restrictions on <select> to prevent that even if you put them in
the WF2 spec???

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

    I believe I answered that question in the first sentence. If most of
your visitors are going to be using legacy user agents, then anyone who
cares about the number of visitors on their site is going to include
legacy support. Those who don't care about the number of visitors
probably don't get that many visitors to begin with.

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

| * If a user agent encounters an attribute value it doesn't recognize,
|   it should use the default attribute value.

    Hmm. I would agree with your interpretation for the most part. I
would point out, though, that it says "should" and not "must".

>>>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:
[Snip!]
> 
> 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.

    My mistake. I thought you were talking about category three. I now
realize that the "caliber" comment was meant in a negative way. I would
point out, once again, that if most of the tutorials use inheritance,
then most of the bottom tier webmasters will simply copy the tutorials
and include fallback.

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

    Which means, in Javascript disabled browsers, there would be no hint
at all, even when there's no default value.

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

    How would you detect what the user agent supports? Many people 
disguise their browsers so that they can get around just such detection.

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

    HTML Tidy chokes on it.

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

    Not if there's no hint at all, no.

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

    That doesn't mean the browser won't take a performance hit loading
the script on less capable machines. There are some computers I use at
work that have trouble running Firefox at a reasonable speed.

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

    Imagine a travel web site feeding up a front page that's twice as
large as it needs to be every single time someone goes to the site.
Isn't that a roughly 2x increase in bandwidth for no reason with an
unnecessary increase in system requirements when it reaches the client?

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

    This comment is of no use to me or anyone else on this mailing list
unless you specify the nature of the problems you feel haven't been
addressed. It's just rhetoric.

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

    Perhaps the question shouldn't be whether my proposal is more
complicated or has more cases than yours. Perhaps the question is
whether it's practical to implement. If it is, then the fact that your
suggestion is simpler doesn't matter in the face of its disadvantages.

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

    It's _one_ more element, and <idate> has fewer attributes than
<input type="date">.

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

     "Many" being five from that list of several dozen, and <idate>
doesn't prevent that kind of fallback. If anything, the list proves that
the majority of webmasters that use textboxes for input WANT format
hints. Your solution would increase all their sites by several kilobytes
to give them the same solution they already have on legacy browsers.

     (Granted, that was more than three, but that really wasn't the point
anyway. The point was to show that there weren't enough sites not using
hints in proportion to those that did to justify not having a fallback
solution for it.)

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

       Except the script is still loaded and executed, slowing down the
browser. It also means additional requests for files to the server.

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

       You're cycling through all the <input> elements to find one that 
has type="date". Most of your script is involved in that very task, so 
clearly a good amount of script is loaded and executed beforehand. 
That's hardly an efficient means of detection.

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

    Wouldn't <datalist> cause the exact same problem? For that matter, 
wouldn't <object> have the same problem? Both would involve the need for 
suppression of legacy script execution.

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

| interface HTMLFormElement : HTMLElement {
|   readonly attribute HTMLCollection   elements;
|   [...]
| }

     Ah! Took me a while. My knowledge of DOM is still a bit limited. I
suppose it would be an issue for using multiple form controls within the
legacy content of <idate>, but that's going to happen in just about any
case that tries to replace a set of controls with a single date control.
Also, a simple check for <idate> can be written in to the script so that
it can select the correct index.

    Also, you have this exact same problem with <datalist>. If there's a 
<select> element that's a child of <datalist>, won't that element be 
part of the .elements collection?

> Support for new <input> attributes would be easy if all the new controls 
> were <input> elements, yet will be hard if they are not.

     I presume you mean via an HTC?...

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

     Perhaps an markup + script example is in order to show us exactly
how event targeting and bubbling cause a problem.

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

     Then, to clarify, is this about a time table or is it a cost-benefit
analysis?

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

     Interesting point. I'm not a browser programmer, so I'll leave this
to more qualified people to comment on.

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

     What exactly is it you expect them to screw up with regards to
fallback? The inheritance is the only issue I can see, and I only
introduced that to reduce the amount or redundant data. I could live
without it if I had to.

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

      No I don't. Microsoft can't afford another poor standards
implementation on top of the ones they've already screwed up. Their
credibility is at the breaking point. They have to create a near-perfect
implementation of WF2 if they're going to support it at all, or they'll
end up looking like the monopolists they are and driving people from IE
faster.

      That said, it's entirely possible they'll create a proprietary set
of tags that steal many of our ideas, then trying to push THAT through
W3C as a standard. I'm far more afraid of that happening.

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

      No, I suppose you're talking about outright incompetence. Even then,
it only remains so until they refuse to fix the bugs. Once they make a
choice to leave it that way, they've made a design choice.

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

     Curious. On browsers that don't support <button>, it degrades into
text. That's a worse fallback than <idate>, yet <input type="button"> is
a mistake?

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

      That's kinda like saying this one raisin is better than a
theoretical all-you-can-eat buffet. Even if sometimes the buffet has
been cleaned out, I'd still take my chances with it over the raisin.