- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 7 Feb 2005 22:35:46 +0000 (UTC)
On Mon, 7 Feb 2005, Matthew Raymond wrote:
> >
> > 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.
Yes; isn't this a safe assumption? The Web has only existed for fifteen
years. I would imagine it will continue existing for many hundreds if not
thousands of years. Obviously it's likely that at some point we will
migrate to technologies no longer based on HTML or XHTML, but I don't see
that happening any time soon. It would be a disaster on a global scale if
the digital textual output of the human race in the last fifteen years was
to outweigh digital textual output of the coming decades.
> > > > 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.
I don't see how that makes it an unfair question.
> > 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.
Of course there are cases where JS is required. There are also many where
it wouldn't be, for example in JS-driven site navigation scripts.
> > 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.
I'm sorry but I have absolutely no doubt that to most authors, there is no
difference here. It's not a matter of "lacking purity", it's a matter of
authors writing content, testing it in their browser, and assuming it
works everywhere (which indeed it should, and that is why technologies
aimed at being authored by everyone should IMHO be designed with automatic
fallback).
> > Why do they target 800x600 displays instead of being
> > device-independent?
>
> Because it's a problem not immediately obvious at the markup level,
Yes it is.
<table width="800">
...is going to cause a problem. That's as obvious as you can get. It's a
lot _more_ obvious than the fact that:
<idate/>
...has a problem.
> > 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.
Whether it's the editor's fault, or the author's fault, the result is the
same. I do not see why <idate/> would be exempt from these problems.
(For what it's worth, in my experience there is a huge amount of <font>
markup that is written by hand. The fact that it "looks like it was added
by something with the IQ of a toaster" does not imply it wasn't a human
who did it.)
> > > 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.
No, I've designed it to not replace existing adequate solutions (three
<select>s) until WF2 becomes popular. It could replace plain text inputs
with no formatting hints straight away, and could augment JS-driven
calendars as soon as the JS is updated. If the author is willing to use
some boilerplate JS and follow some simple guidelines when writing the
form, it could even replace plain text inputs with formatting hints.
> > > 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???
The form and select prefilling features have no fallback short of script.
They are unfortunate exceptions to the design principle I mentioned. I did
not see any other way to introduce those features. (replace="" is another
case, as are action="data:" and action="file:", method="put" and "delete",
and various other new features in WF2.)
> > > 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.
CNN doesn't gcareabout Lynx users (that much is obvious from trying to
read their site with Lynx). But the site still fundamentally works,
because the technology is designed to be largely device- and media-
independent, with fallback that Just Works (for example, <table>s fall
back on a jumble of text, but it's still text).
So CNN is currently at least usable in Lynx, even though the authors
clearly didn't make any effort to have it be.
With <input type="date">, this would continue. Today's Lynx today would be
able to browse a site using that feature and it would work. But with
<idate/>, if the author didn't specifically add in the legacy markup,
today's lynx would instead see nothing at all.
When we have two options, both of which have problems, but one of which
falls back poorly and the other falls back potentially not at all, it is
IMHO almost always the case that the former is the better choice.
> 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.
Tutorials often fail to provide good markup, sadly. But I agree that good
tutorials would certainly help here.
> > > > 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.
If it was in the title attribute it would appear as a tooltip. Also, the
case we are talking about here is for when there is already a value in the
control, in which case the user does have a hint, namely, the existing
value.
> > > 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.
I wouldn't recommend using HTML Tidy then. :-)
> > > 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?
I'm sorry but you are making up numbers here to make your argument sound
stronger. We're talking about less than one kilobyte of content here, for
pages that are often _hundreds_ of kilobytes long already.
> > > 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.
I've repeatedly given you problems that the <idate> proposal has, indeed
you even replied to some of them in this very e-mail. I've listed some at
the bottom of this e-mail for convenience.
> > > > 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.
I don't follow. If the question is whether it is more practical to
implement in UAs or not, then surely the fact that one proposal is simpler
is of quite large importance.
> > > 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">.
I may have lost track of the proposals you were making, but I thought
<idate> potentially had many more elements, including <submit/>s, as well
as multiple attributes to do with the formatting submission, etc.
> > > > > 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.
We're talking about a few lines of code in an existing script. There is no
significant cost to supporting imperative fallback here.
> > 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.
We're talking about less than 50 lines of very simple code, about half of
which is just to handle UAs going back to NS3 or before and to provide the
server with a timezone, something that wouldn't be necessary in most
cases. Running this code is of negligable cost to UAs. By no means is it
"clearly a good amount". The actual algorithm consists of simply checking
each <input> element in the document, a cheap process in all but the most
obscenely complicated forms. The detection is done on a per-control basis
to check that the UA supports that particular type of control, which is
the most fine-grained method.
> > 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.
No, anything inside <datalist> will execute as per normal. There's nothing
in WF2 that says that <datalist> contents don't execute -- in fact the
only things that are said are that (a) the element shouldn't be displayed,
and (b) any controls inside it must not be successful.
> > <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>.
>
> 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.
It changes a script from:
document.forms[0].elements[2].value = "2005-04-02";
...to, er. *ponders*. I actually can't work out how you would handle this.
The problem is that this (simplified markup for clarity):
<form>
<input type="date"/>
<input type="time"/>
<input type="week"/>
</form>
...can always be addressed from script by using elements[0] to
elements[2], whether the UA supports WF2 or not. But when you use <idate>,
etc, you end up with:
<form>
<idate> <input/> </idate>
<itime> <input/> </itime>
<iweek> <input/> </iweek>
</form>
...and now which index you use depends entirely on what the UA supports.
If it supports <idate> only, you have to tweak elements 0, 2 and 3. If it
supports <itime> only you have to tweak 0, 1, and 3. If it supports
<itime> and <idate> but not <iweek> you have to tweak 0, 2, and 4. And so
forth. It pretty much kills the use of indexes in the markup. Even using
names you'd have to check each case to see if it was supported or not.
Script would become significantly more complex.
(Actually, in the kind of case you're suggesting authors should use,
namely:
<form>
<idate> <select/> <select/> <select/> </idate>
<itime> <input/> </time>
<iweek> <select/> <input/> </iweek>
</form>
...you would end up with an even more complicated problem because the
numbers of the controls would differ _in a different way_ based on what
was supported -- for example, it could be 0, 4, 6 if everything in WF2 was
supported, or it could be 1-3, 4, 6-7 if only <itime> was supported, etc.)
> 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?
<datalist> is not a control, so it doesn't appear in .elements. The
contents of <datalist> always appear in .elements, so the index is the
same whether or not the element is supported.
> > 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?...
No, I mean in general. If all the controls are <input> elements,
supporting autofocus="" doesn't need to know anything except about
<input>. As it is, it already applies to <button>, <textarea>, and
<select>. Each new element increases the difficulty of implementing it,
since the implementation then needs to know about the new control.
> > 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.
Take:
<idate>
<input>
</idate>
If you have a WF2 UA you can do:
document.getElementsByTagName('idate')[0].addEventListener('change', change, false)
But if you don't you must do:
document.getElementsByTagName('input')[0].addEventListener('change', change, false)
...and in fact the former will either fail silently, or abort the script
(depending on exactly how UAs parse unknown elements).
> > > > > 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?
Cost/benefit analysis. Implementing a slew of new elements for date
controls would take a lot longer than implementing a set of new types, and
the increase in cost is not outweighed by the few benefits (which are
basically only better fallback, as far as I can tell).
> > > > 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?
This argument was more relevant against the <format> proposal.
> > > 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.
In my experience, the majority of the people don't care one iota about
standards compliance. Even most _hand authors_ don't care much about it.
There is a very vocal minority (of which I am a member!) who care about
the issue, but at the end of the day, most users care more about flashy
graphics, good advertising campaigns, slicker interfaces and less crashes
than about standards compliance.
> 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.
That's already happened (except for the stealing our ideas bit).
Microsoft's current Web strategy is based on .NET/Avalon/XAML, and they
have already standardised many aspects of their .NET framework in much
more prestigious standards organisations than the W3C.
> > > > 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?
<input type="submit"> is a mistake because when forms were originally
introduced, it should have been <button> from the start, for i18n reasons.
Sadly, at the time, i18n was of little concern to most people involved
(not through malice, but because the issue simply hadn't come up).
There was no fallback problem with <input type="submit"> though because it
was introduced at the same time as <input type="text"> and the latter was
useless without the former. If <button> had been introduced at the same
time, the same would apply there.
Of course, it wasn't, and had I been on the working group at the time
<button> was introduced I would probably have tried to find a better
solution. As you say, falling back on text is a poor solution at best.
I'm glad nobody suggested
<button><input type="submit"></button>
...though! ;-)
> > 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.
I wouldn't. :-)
The problems with what I understand of your proposal are:
* More complicated to implement:
- more elements involved
- interactions of elements and attributes that require
dynamic updates (very bug prone)
* More complicated to author for.
- more elements involved
- scripts have to be rewritten to handle the legacy content
separately from the new content (elements array is different,
event handling is different)
* Fallback needs author involvement
- easiest to simply not support legacy
- server typically needs to handle different names for controls,
not just different format
The drawback of the current proposal (new input types) is just that to get
any sort of decent fallback in legacy UAs you need to use a script;
without scripting the legacy fallback is a poor experience.
I agree that's a problem, but it's only one problem, and the solution
doesn't suffer from the other problems I listed above. Also, that script
could be prepackaged, and the demo script on the whatwg.org site certainly
could be substantially improved so that using it is a lot easier and
simpler. While the fallback is not ideal, even without JS there is still
_some_ fallback.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 7 February 2005 14:35:46 UTC