From mattraymond at earthlink.net  Wed Feb  2 08:00:21 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 02 Feb 2005 11:00:21 -0500
Subject: [whatwg] [WA1] Idea for Calendar Markup
Message-ID: <4200F915.9060803@earthlink.net>

    I like the idea of a calendar in Web Applications 1.0, but I really 
hate the way they're currently implemented. For one thing, if the 
|class| attribute contains the name of a calendar attribute, how do you 
style the element? What happens if you use |class| to style something, 
and the class happens to be the name of a calendar attribute? Does it 
style that attribute.

    Nope, I prefer to stick with good old-fashioned elements. Here's an 
example of what I'd like to see, minus the fallback content:

| <calendar>
|   <cevent id="e036f260-39b4-11d9-ad3f-fc68600c1802">
|     <csummary value="That thing we did that was so fun."></csummary>
|     <cattr type="status" value="CONFIRMED"></cattr>
|     <cattr type="class" value="PRIVATE"></cattr>
|     <cattr type="categories" value="Work"></cattr>
|     <cattr type="x-mozilla-alarm-default-length" value="0"></cattr>
|     <cattr type="dtstamp" value="2005-02-02T21:00Z"></cattr>
|     <cdatetime start="2005-02-30T19:00Z" end="2005-02-30T21:00Z">
|     </cdatetime>
|   </cevent>
| </calendar>

    Basic stuff like the summary and the start and end dates are defined 
specifically. The rest of the calendar event attributes are defined with 
<cattr type="attribute-name">. A WA1-compliant UA would then assign the 
|value| attribute as the value of the calendar event attribute. If 
|value| is not specified, the child contents are used. The <cdatetime> 
element is a special case in that it requires <datetime> elements to be 
in the child contents if |value| is undefined.

    All contents inside <calendar> that are not calendar-related 
elements or the contents of calendar-related elements are ignored. As a 
result, the following would provide proper fallback content:

| <calendar>
|   <table>
|     <caption>Upcoming Events</caption>
|     <tr>
|       <th>Summary</th>
|       <th>Status</th>
|       <th>Class</th>
|       <th>Categories</th>
|       <th>Start Date</th>
|       <th>End Date</th>
|     </tr>
|     <cevent id="e036f260-39b4-11d9-ad3f-fc68600c1802">
|     <tr>
|       <td><csummary>
|         That thing we did that was so fun.
|       </calsummary></td>
|       <td><cattr type="status">CONFIRMED</cattr></td>
|       <td><cattr type="class">PRIVATE</cattr></td>
|       <td><cattr type="categories">Work</cattr></td>
|       <cattr type="x-mozilla-alarm-default-length" value="0"></cattr>
|       <cattr type="dtstamp">
|         <datetime value="2005-02-02T21:00Z"></datetime>
|       </cattr>
|       <cdatetime>
|         <td><datetime value="2005-02-30T21:00Z">
|           02/30/05 7:00 PM
|         </datetime></td>
|         <td><datetime value="2005-02-30T21:00Z">
|           02/30/05 9:00 PM
|         </datetime></td>
|       </cdatetime>
|     </tr>
|     </cevent>
|   </table>
| </calendar>

    The above should render in legacy user agents as a table, with 
values unimportant to presentation not rendered. Yet, for a WA1 UA, it 
yields the same calendar as the first example.

    Note that in both examples, if the |type| of a <cattr> element is 
unknown to the user agent, the value can simply be ignored. The <cattr> 
would have a set of standardized |type| values that all user agents 
would support, then individual user agent vendors could implement 
extensions, with the recommended nomenclature being something like this:

    x-[company or organization]-[attribute name]

    This should give us a reasonable amount of flexibility and 
extensibility without creating a complicated markup scheme. If 
necessary, <cdatetime> and <csummary> could be rolled into <cattr>, but 
I'd prefer to have these separate, since they're likely to always be used.

   That's all for now. Thoughts welcome.


From ian at hixie.ch  Thu Feb  3 05:36:54 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 13:36:54 +0000 (UTC)
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <41FE8360.6000607@yahoo.com>
References: <41FC2D55.6030608@yahoo.com>
	<Pine.LNX.4.61.0501311501020.9893@dhalsim.dreamhost.com>
	<41FE8360.6000607@yahoo.com>
Message-ID: <Pine.LNX.4.61.0502031333100.6666@dhalsim.dreamhost.com>

On Mon, 31 Jan 2005, Daniel Brooks wrote:
> 
> Ah, that makes sense. Perhaps a single sentance that states that they 
> are counted as two form controls just like is described elsewhere (with 
> a reference), but that they are otherwise skipped.

The spec says:

| For image controls, instead of using the name given by the name 
| attribute, the field's name is checked against two names, the first 
| being the value of the name attribute with the string .x appended to it, 
| and the second being the same but with .y appended instead. Thus image 
| controls are handled as if they were two controls.
|
| If the identified form control is a file upload control, a push button 
| control, or an image control, then the field element is now skipped.


> Ah, it's in the third paragraph, but now that I read it again I see that 
> it says 'from script', not 'form script', so I guess it's ok, but 'for a 
> script' or 'for scripts' would be easier to read. The whole sentance is 
> "There is no way from script to detect this situation because that would 
> open the way for some privacy or security leaks."

Done.


Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 05:59:44 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 13:59:44 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <41FF0B32.8050604@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>

On Mon, 31 Jan 2005, Matthew Raymond wrote:
>>
>> It has problems, as mentioned elsewhere in the thread:
>>
>>  * It is easy for authors to not include any fallback, which makes it
>>    worse than the <input> equivalent.
> 
> If the legacy fallback is simply an <input>, then inheritance handles it 
> nicely. If you start with this:
> 
> | <input name="date" value="2005-01-31"> Format: YYYY-MM-DD

But you don't. Many, if not most, WF2 documents will be new documents. 
There is no existing content. Authors would just do:

   <idate name="date"/>

...or some such, and be done with it.


> Therefore, I see no reason why a webmaster would choose to drop their 
> legacy content when upgrading their websites to use <idate> and its 
> siblings.

The problem is assuming the Web author is upgrading a Web site in the 
first place. It could be a new one.


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



> >  * The fallback and non-fallback controls have different names.
> 
> This is only true of the 3SC scenario, and in that situation the server 
> script can easily be rewritten to handle the situation.

I thought we had to assume the server couldn't be changed?


>>  * The datetime types don't really need comprehensive fallback, given
>>    that the three cases that they could replace are:
>>      1. Text inputs, which would be improved, not hurt, by the new
>>         types,
> 
> Except you never solved the formatting hints problem to anyone's 
> satisfaction

I still don't understand what is wrong with the short amount of black-box 
JavaScript I proposed. It handles more cases than your proposals with no 
work on the UA implementor's behalf.

Not to mention that many of the authors who fall into this "1" category 
simply don't provide formatting hints at all. The authors who are likely 
to care about fallback formatting hints simply wouldn't use text inputs in 
current pages anyway, and therefore aren't, IMHO, part of this category.



> nor did you explain how to handle legacy sites that use <input> + DHTML 
> solutions.

That would be category 3 below.


> Elements like <idate>, as seen above, solve this problem in a simple, 
> straight-forward and effective manner.

IMHO it is neither simple, nor straight-forward, nor effective, and has 
serious drawbacks, as I have described. It certainly isn't a bad solution, 
but it isn't, IMHO, any better than what we have already.


> >      2. <select> controls, which do not need to be replaced at all,
> >         and
> 
> Yes you do. In fact, if people prefer using <select> controls for legacy 
> input, then failing to support it will drive people away from WF2, at 
> least where the date/time markup is concerned.

Why would this be a problem? As I said before, we're not trying to get 
people to use WF2 for the sake of using WF2 here.


> It may even give some user agent vendors reason not to implement parts 
> of the WF2 spec.

I highly doubt that use or lack of use of type="date" on sites will affect 
whether UAs implement it or not. There are plenty of counter-examples. 
(Nobody uses XForms, yet IBM implements it in Mozilla; lots of people use 
XSLT, yet Opera isn't implementing that, etc.)


> >      3. Complex JS widgets, for which declarative fallback is not
> >         needed.
> 
> Having a consistent, localized, canned date control is something 
> webmasters are going to want even if they have complex DHTML widgets. 
> However, they're not going to want to get rid of their DHTML widgets on 
> legacy clients that are still bound to be around for many years. As a 
> result, if you make it nigh impossible for them to use their widgets as 
> a fallback, they're just going to continue using them because they know 
> they'll still work on WF2 user agents.

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


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


> Could you provide a use case where implementation would be an issue?

I have no idea what you mean by this.



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


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


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


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lachlan.hunt at iinet.net.au  Thu Feb  3 06:08:15 2005
From: lachlan.hunt at iinet.net.au (Lachlan Hunt)
Date: Fri, 04 Feb 2005 01:08:15 +1100
Subject: [whatwg] [WF2] 6.2: maxlength Defintion - Grammatical Problems
Message-ID: <4202304F.5060705@iinet.net.au>

Hi,
   In section 6.2, under the defintion of the maxlength attribute, the 
current draft states [1]:

| Authors are encouraged to use maxlength on uri and email fields only
| if the server side processor actually has a limit on the size of data
| fields it can usefully process. Valid URIs and e-mail addresses in
| particular can often be surprisingly long.

I misread that several times as I was skimming through, thinking it 
meant that using maxlength on uri and email fields was generally a good 
thing.  I suggest you reverse it so that it makes a little more sense. 
I think this would be better:

   Authors are _discouraged from using_ maxlength on uri and email fields
   _unless_ the server side processor actually has a limit on the size of
   data fields it can usefully process. Valid URIs and e-mail addresses
   in particular can often be surprisingly long.

Also, another grammatical error I came across several times throught the 
draft is whenever it says "comply to", "complies to" or any other 
variation.  The correct preposition to use is actually "with", not "to". 
  Thus, they should read "comply with", "complies with", etc.

[1] 
http://www.whatwg.org/specs/web-forms/2005-01-28-call-for-comments/#extensions0
-- 
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/    Rediscover the Web
http://SpreadFirefox.com/   Igniting the Web



From ian at hixie.ch  Thu Feb  3 06:09:07 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 14:09:07 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <41FE6E94.6070604@cam.ac.uk>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
Message-ID: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>

On Mon, 31 Jan 2005, James Graham wrote:
> > 
> > It has problems, as mentioned elsewhere in the thread:
> > 
> > * It is easy for authors to not include any fallback, which makes it 
> > worse than the <input> equivalent.
>
> In general, it is easy to make WF2 pages incompatible with older 
> browsers.

Granted, but at least it's not the default.


> > * The fallback and non-fallback controls have different names.
>
> Why is that a problem? Would it not be a simple if construct on the 
> server side to deal with the two cases?

Having two different forms (as opposed to one form with just better 
behaviour in newer UAs) is something that the current WF2 design has, by 
and large, been striving for.


> >     2. <select> controls, which do not need to be replaced at all,
> 
> If that's really true, then all the date types seem a little pointless. 
> I thought that one of the advantages of the WF2 controls was allowing 
> sites to present a consistent, OS-specific interface to form controls. 
> If multiple select controls are as good a solution, there seems little 
> point in implementing or using WF2.

Indeed. Three <select>s are reasonably good UI, although not as good as 
type="date" on a supporting UA. While WF2 UAs are not in the majority, 
there's not really a huge advantage to using the new types. (This applies 
to <idate> et all as well, by the way.)

Similarly, while XHTML is not supported in the majority of UAs, there's 
not really any reason to use XHTML. That doesn't mean that XHTML is bad, 
indeed, XHTML (and especially the ability to create compound documents by 
mixing namespaces _with_ XHTML) is great. But there's no reason to rush 
off and use XHTML in the meantime.

The difference is that if you _do_ want to use type="date", you can do so, 
and legacy UAs will still work (albeit not as user-friendlyly). With 
XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have to be 
all-or-nothing, but authors are likely to take the easy route and thus not 
provide any fallback content. (Just look at how many authors provide good 
fallback content for images.)


> >     3. Complex JS widgets, for which declarative fallback is not needed.
>
> Why not? If one is replacing a javascript control with a WF2 control, 
> one can improve the accessibility of one's page further by providing 
> simple controls for legacy clients (this would be equivalant to say, 
> producing a CSS based design and allowing old browsers to recieve 
> unstyled content v using a table based design and blocking old browsers 
> entirely).

I said _declarative_ fallback was not needed. If you're using JS, you can 
easily implement the fallback yourself using JS.


> > ...not to mention the extra complexity and the implementation 
> > difficulty compared to just using a new "type".
>
> Really? Obviously you're much more familiar with the browser engines 
> than I am but I'm not sure that this is obviously difficult to 
> implement. At least not obviously a lot more difficult than WF2 datetime 
> controls are anyway. Is there something specific that browsers will 
> struggle to cope with?

Nothing specific. Just every little added bit of complexity. I'm already 
getting requests from implementors to drop the entire repetition model, 
and to massively simplify the validity stuff, etc. And those aren't 
particularly hard to implement.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 06:53:44 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 14:53:44 +0000 (UTC)
Subject: [whatwg] [WF2] 6.2: maxlength Defintion - Grammatical Problems
In-Reply-To: <4202304F.5060705@iinet.net.au>
References: <4202304F.5060705@iinet.net.au>
Message-ID: <Pine.LNX.4.61.0502031432370.6666@dhalsim.dreamhost.com>

On Fri, 4 Feb 2005, Lachlan Hunt wrote:
>
> I misread that several times as I was skimming through, thinking it 
> meant that using maxlength on uri and email fields was generally a good 
> thing.  I suggest you reverse it so that it makes a little more sense. I 
> think this would be better:
> 
>   Authors are _discouraged from using_ maxlength on uri and email fields
>   _unless_ the server side processor actually has a limit on the size of
>   data fields it can usefully process. Valid URIs and e-mail addresses
>   in particular can often be surprisingly long.

Good idea. Done.


> Also, another grammatical error I came across several times throught the 
> draft is whenever it says "comply to", "complies to" or any other 
> variation.  The correct preposition to use is actually "with", not "to".  
> Thus, they should read "comply with", "complies with", etc.

I couldn't find any reference to back this up, but since I don't have a 
strong opinion either way, I changed them all to "with".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 07:58:34 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 15:58:34 +0000 (UTC)
Subject: [whatwg] Web Forms 2 stable draft draft
Message-ID: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>


I've added a blurb in the status section of the WF2 document listing the 
issues that I am aware of that people still are not happy with with regard 
to the current state of the WF2 draft.

What a horrible sentence.

Anyway, please let me know ASAP if I've missed an issue.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Thu Feb  3 08:17:11 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 17:17:11 +0100
Subject: [whatwg] Use IRI instead of URI
Message-ID: <42024E87.4030505@annevankesteren.nl>

Since IRI is now a RFC, shouldn't Web Forms use that term instead of URI?

(For example, in section 2.12. I guess once UAs start supporting IRIs
you want a list of IRIs there, not just URIs.)


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From fora at annevankesteren.nl  Thu Feb  3 08:21:23 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 17:21:23 +0100
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
Message-ID: <42024F83.4020904@annevankesteren.nl>

I think Web Forms 2 should refer to a dated version of HTML 4.01 (for 
example section 2.13), not to the latest version since there is a very 
small chance that the definition might change eventually.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From mattraymond at earthlink.net  Thu Feb  3 08:49:53 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 03 Feb 2005 11:49:53 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
Message-ID: <42025631.7060004@earthlink.net>

Ian Hickson wrote:
> On Mon, 31 Jan 2005, Matthew Raymond wrote:
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>> * It is easy for authors to not include any fallback, which makes it
>>>   worse than the <input> equivalent.
>>
>>If the legacy fallback is simply an <input>, then inheritance handles it 
>>nicely. If you start with this:
>>
>>| <input name="date" value="2005-01-31"> Format: YYYY-MM-DD
> 
> But you don't. Many, if not most, WF2 documents will be new documents.

    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.

> 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? Furthermore, WF2 user 
agents will have little initial marketshare, so why would someone target 
them and leave out legacy support? This is especially nonsensical when 
you notice that supporting legacy UAs in a manner similar to <input 
type="date"> really isn't that hard:

| <idate><input name="date"></idate>

    And they're going to have to know how to use <input> to create forms 
anyways. If anything, <input type="date"> is just as confusing because 
it requires you to set the |type| attribute when the webmaster may have 
only learned this:

| <input name="date">

    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.

>>Therefore, I see no reason why a webmaster would choose to drop their 
>>legacy content when upgrading their websites to use <idate> and its 
>>siblings.
> 
> The problem is assuming the Web author is upgrading a Web site in the 
> first place. It could be a new one.

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

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

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

>>> * The fallback and non-fallback controls have different names.
>>
>>This is only true of the 3SC scenario, and in that situation the server 
>>script can easily be rewritten to handle the situation.
> 
> I thought we had to assume the server couldn't be changed?

    I thought I'd already acknowledged in a previous message that most 
people on this mailing list felt client-side formatting was a bad idea. 
That's why I call it "<idate>" now instead of "<date>".

>>> * The datetime types don't really need comprehensive fallback, given
>>>   that the three cases that they could replace are:
>>>     1. Text inputs, which would be improved, not hurt, by the new
>>>        types,
>>
>>Except you never solved the formatting hints problem to anyone's 
>>satisfaction
> 
> 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?

2) It relied on a empty <span> element, which doesn't validate under 
HTML Strict.

3) With Javascript turned off, you have the problem of having to select 
and delete the format hint text in some situations.

4) New webmasters, who don't understand how the script works, will 
easily break it.

5) The script takes up nearly as much space as the HTML!

    By contrast, my modified version using <idate> probably cut the size 
of the demo web page in half and supports the same features.

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

    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.

    Furthermore, the above code doesn't require the web author to know 
anything about the attributes of <idate> unless they specifically want 
to use three <select> elements or some similar scenario. Even then, the 
attributes are the same as <input>.

    So the real question is: How does the marginal added complexity of 
<idate> offset the benefit?

> 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. All three examples of textboxes used for dates have had formatting 
hints of some kind. QJump has in recent times dropped them from their 
front page, but does include them when it asks you to verify your 
journey details. (And in other places they use <select> elements.)

 > The authors who are likely to care about fallback formatting hints
 > simply wouldn't use text inputs in current pages anyway, and therefore'
 > aren't, IMHO, part of this category.

    There are plenty of reasons for them to care, not the least of which 
is localization and client-side date validation. Plus, as I've pointed 
out in previous messages, Javascript is required for a three <select> 
solution because the number of days in a month changes month-to-month.

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

>>Elements like <idate>, as seen above, solve this problem in a simple, 
>>straight-forward and effective manner.
> 
> IMHO it is neither simple, nor straight-forward, nor effective, and has 
> serious drawbacks, as I have described. It certainly isn't a bad solution, 
> but it isn't, IMHO, any better than what we have already.

    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.

    The supposed drawbacks, in my opinion, aren't serious. People who 
can't understand the markup aren't likely to be smart enough to 
hand-code HTML anyways. For those who use editors that don't support 
WF2, it's just as easy to create a textbox control and slap two <idate> 
tags around it as it is to create a textbox control and change the 
|type| to "date". In fact, some editors can be easily configured so that 
you can simply select the <input> element and press a button.

    As for pages intentionally written without fallback, legacy browser 
users, who will remain in the majority for perhaps years to come, can 
simply elect to to visit such pages, thus decreasing their hit counts. 
So if the webmaster cares if people visit her/his site, he/she will 
support legacy clients.

>>>     2. <select> controls, which do not need to be replaced at all,
>>>        and
>>
>>Yes you do. In fact, if people prefer using <select> controls for legacy 
>>input, then failing to support it will drive people away from WF2, at 
>>least where the date/time markup is concerned.
> 
> Why would this be a problem? As I said before, we're not trying to get 
> people to use WF2 for the sake of using WF2 here.

    We want them to use it because it's a better solution. However, if 
it's a better solution only on a few new browsers, but a worse solution 
on legacy browsers, which are in the majority, that makes WF2 a worse 
solution over all.

>>It may even give some user agent vendors reason not to implement parts 
>>of the WF2 spec.
> 
> I highly doubt that use or lack of use of type="date" on sites will affect 
> whether UAs implement it or not. There are plenty of counter-examples. 
> (Nobody uses XForms, yet IBM implements it in Mozilla; lots of people use 
> XSLT, yet Opera isn't implementing that, etc.)

    XSLT is being used by Microsoft as one excuse for not supporting web 
standards. It also can just as easily be done on the server as the 
client, so there's no reason to put it in the browser. Therefore, Opera 
had a reason not to implement it.

    XForms has yet to come out of beta on the Mozilla platform, and as I 
recall, Opera isn't going to include support because it's so complex. 
That complexity has given vendors reason to delay or even decide against 
implementation.

    So I don't see how those example help your case. In both situations, 
problems with the technology limited UA support.

>>>     3. Complex JS widgets, for which declarative fallback is not
>>>        needed.
>>
>>Having a consistent, localized, canned date control is something 
>>webmasters are going to want even if they have complex DHTML widgets. 
>>However, they're not going to want to get rid of their DHTML widgets on 
>>legacy clients that are still bound to be around for many years. As a 
>>result, if you make it nigh impossible for them to use their widgets as 
>>a fallback, they're just going to continue using them because they know 
>>they'll still work on WF2 user agents.
> 
> 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.

    By contrast, <idate> can be used to prevent execution of a script:

| <idate name="date1">
|  <script type="text/javascript" src="datepicker.js">
| </idate>

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

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

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

>>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. If WF2 
was to become popular enough for Microsoft to consider implementation, 
the 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. 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.

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

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


From mattraymond at earthlink.net  Thu Feb  3 09:20:08 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 03 Feb 2005 12:20:08 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
Message-ID: <42025D48.4020709@earthlink.net>

Ian Hickson wrote:
> On Mon, 31 Jan 2005, James Graham wrote:
> 
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>>* It is easy for authors to not include any fallback, which makes it 
>>>worse than the <input> equivalent.
>>
>>In general, it is easy to make WF2 pages incompatible with older 
>>browsers.
> 
> Granted, but at least it's not the default.

    When using the inheritance feature of <idate>, incompatibility isn't 
the default either, and the only situation in which you can't use 
inheritance is when the first child control doesn't submit a complete 
date. You're arguing a "Rogue Webmaster" scenario.

>>>* The fallback and non-fallback controls have different names.
>>
>>Why is that a problem? Would it not be a simple if construct on the 
>>server side to deal with the two cases?
> 
> Having two different forms (as opposed to one form with just better 
> behaviour in newer UAs) is something that the current WF2 design has, by 
> and large, been striving for.

    I know has support for having multiple forms use the same controls, 
but what does that have to do with multiple controls being used for the 
same field?

>>>    2. <select> controls, which do not need to be replaced at all,
>>
>>If that's really true, then all the date types seem a little pointless. 
>>I thought that one of the advantages of the WF2 controls was allowing 
>>sites to present a consistent, OS-specific interface to form controls. 
>>If multiple select controls are as good a solution, there seems little 
>>point in implementing or using WF2.
> 
> Indeed. Three <select>s are reasonably good UI, although not as good as 
> type="date" on a supporting UA. While WF2 UAs are not in the majority, 
> there's not really a huge advantage to using the new types. (This applies 
> to <idate> et all as well, by the way.)

    Are you arguing against the use of <idate> or against the use of 
<input type="date">?  Most dates are entered via the three <select> 
scenario. Therefore, if there's a compelling reason to use <input> in 
those cases, then <idate> is even more compelling.

> Similarly, while XHTML is not supported in the majority of UAs, there's 
> not really any reason to use XHTML. That doesn't mean that XHTML is bad, 
> indeed, XHTML (and especially the ability to create compound documents by 
> mixing namespaces _with_ XHTML) is great. But there's no reason to rush 
> off and use XHTML in the meantime.

    I fail to see how this argument supports the use of <input 
type="date"> and doesn't support the use of <idate>.

> The difference is that if you _do_ want to use type="date", you can do so, 
> and legacy UAs will still work (albeit not as user-friendlyly).

   Same is true for <idate>, unless--EGADS!--Not the Rogue Webmaster!!!

 > With
> XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have to be 
> all-or-nothing, but authors are likely to take the easy route and thus not 
> provide any fallback content. (Just look at how many authors provide good 
> fallback content for images.)

    The difference here is that text-base browsers, so far as I know, 
where NEVER the most popular type of browser, so there was little 
incentive for fallback. Not to mention the fact that IE corrupted the 
meaning of the |alt| attribute by using it for tooltips...

>>>    3. Complex JS widgets, for which declarative fallback is not needed.
>>
>>Why not? If one is replacing a javascript control with a WF2 control, 
>>one can improve the accessibility of one's page further by providing 
>>simple controls for legacy clients (this would be equivalant to say, 
>>producing a CSS based design and allowing old browsers to recieve 
>>unstyled content v using a table based design and blocking old browsers 
>>entirely).
> 
> I said _declarative_ fallback was not needed. If you're using JS, you can 
> easily implement the fallback yourself using JS.

    The <idate> element doesn't need JS at all. You're requiring 
webmasters to either learn scripting for legacy content, or depend on 
his Javascript programmer buddy to do the work for him.

>>>...not to mention the extra complexity and the implementation 
>>>difficulty compared to just using a new "type".
>>
>>Really? Obviously you're much more familiar with the browser engines 
>>than I am but I'm not sure that this is obviously difficult to 
>>implement. At least not obviously a lot more difficult than WF2 datetime 
>>controls are anyway. Is there something specific that browsers will 
>>struggle to cope with?
> 
> Nothing specific. Just every little added bit of complexity. I'm already 
> getting requests from implementors to drop the entire repetition model, 
> and to massively simplify the validity stuff, etc. And those aren't 
> particularly hard to implement.

    The repetition model is MORE complex than <idate>. Besides, isn't 
this what the implementation phase is for? Isn't the who point of the 
implementation phase to find out what people will actually implement and 
adjust the draft accordingly? Stick <idate> in, give the draft one more 
call before the implementation phase, and if people hate it, take it out 
before the implementation phase, or if people like it, but it's too hard 
to implement, it'll get dropped in the implementation phase.


From ian at hixie.ch  Thu Feb  3 09:23:43 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 17:23:43 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42024E87.4030505@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
>
> Since IRI is now a RFC, shouldn't Web Forms use that term instead of 
> URI?
> 
> (For example, in section 2.12. I guess once UAs start supporting IRIs 
> you want a list of IRIs there, not just URIs.)

I've already updated all the cases that really matter. For the most part 
I'd like to just stick to calling things URIs since otherwise people will 
just get more and more confused (most people still think they're URLs...).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 09:24:29 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 17:24:29 +0000 (UTC)
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <42024F83.4020904@annevankesteren.nl>
References: <42024F83.4020904@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
>
> I think Web Forms 2 should refer to a dated version of HTML 4.01 (for 
> example section 2.13), not to the latest version since there is a very 
> small chance that the definition might change eventually.

Why wouldn't we want WF2 to track changes in HTML4?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Thu Feb  3 09:34:32 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 18:34:32 +0100
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>
References: <42024F83.4020904@annevankesteren.nl>
	<Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>
Message-ID: <420260A8.2070008@annevankesteren.nl>

Ian Hickson wrote:
> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> 
>> I think Web Forms 2 should refer to a dated version of HTML 4.01 
>> (for example section 2.13), not to the latest version since there 
>> is a very small chance that the definition might change eventually.
>
> Why wouldn't we want WF2 to track changes in HTML4?

Because the draft someone implements might not be stable in such cases.

Once HTML4 updates, WF2 could get an update of its own and match the 
changes in other drafts.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From fora at annevankesteren.nl  Thu Feb  3 09:42:48 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 18:42:48 +0100
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
Message-ID: <42026298.7020106@annevankesteren.nl>

Ian Hickson wrote:
> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> 
>> Since IRI is now a RFC, shouldn't Web Forms use that term instead 
>> of URI?
>> 
>> (For example, in section 2.12. I guess once UAs start supporting 
>> IRIs you want a list of IRIs there, not just URIs.)
> 
> I've already updated all the cases that really matter. For the most 
> part I'd like to just stick to calling things URIs since otherwise 
> people will just get more and more confused (most people still think
> they're URLs...).

Does that matter for a specification?

If you do it, you might want to add a line somewhere that URI and IRI
are used interchangeable.

Also, I think WF2 should refer to RFC3986 instead of RFC1738 since the
former updates the latter. RFC3986 is an internet standard and obsoletes
various other documents as well.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From jg307 at cam.ac.uk  Thu Feb  3 09:44:19 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Thu, 03 Feb 2005 17:44:19 +0000
Subject: [whatwg] Re: several messages
In-Reply-To: <42025D48.4020709@earthlink.net>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net>
Message-ID: <420262F3.7000008@cam.ac.uk>

Matthew Raymond wrote:

> Ian Hickson wrote:
>
>> On Mon, 31 Jan 2005, James Graham wrote:
>>
>>>> It has problems, as mentioned elsewhere in the thread:
>>>>
>>>> * It is easy for authors to not include any fallback, which makes 
>>>> it worse than the <input> equivalent.
>>>
>>>
>>> In general, it is easy to make WF2 pages incompatible with older 
>>> browsers.
>>
>>
>> Granted, but at least it's not the default.
>
>
>    When using the inheritance feature of <idate>, incompatibility 
> isn't the default either, and the only situation in which you can't 
> use inheritance is when the first child control doesn't submit a 
> complete date. You're arguing a "Rogue Webmaster" scenario.

To be clear, my adaptation of this model did not include any such 
inheritance (for implementation simplicity). Having said that I don't 
think that requiring authors to explicitly provide fallback content is 
such a bad thing (at least, not worse than the limited fallback options 
offered by input). But more on that later.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs



From ian at hixie.ch  Thu Feb  3 10:02:56 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 18:02:56 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42025631.7060004@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>

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.   `._.-(,_..'--(,_..'`-.;.'


From mattraymond at earthlink.net  Thu Feb  3 10:03:28 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 03 Feb 2005 13:03:28 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <420262F3.7000008@cam.ac.uk>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net> <420262F3.7000008@cam.ac.uk>
Message-ID: <42026770.3070205@earthlink.net>

James Graham wrote:
> Matthew Raymond wrote:
>>   When using the inheritance feature of <idate>, incompatibility 
>>isn't the default either, and the only situation in which you can't 
>>use inheritance is when the first child control doesn't submit a 
>>complete date. You're arguing a "Rogue Webmaster" scenario.
> 
> To be clear, my adaptation of this model did not include any such 
> inheritance (for implementation simplicity). Having said that I don't 
> think that requiring authors to explicitly provide fallback content is 
> such a bad thing (at least, not worse than the limited fallback options 
> offered by input). But more on that later.

    I could be convinced to drop inheritance if it's shown that it 
creates significant implementation problems, but unless someone can 
clearly communicate the problems involved, I still believe any potential 
feature removal should occur during the implementation phase of the spec.

    On a slightly unrelated note, I just realized a short time ago that 
the Microsoft sabotage scenario could happen just as easily if <idate>, 
or any part of it, were left out of the spec as it would be if it were 
included as-is. All Microsoft would have to do is implement flawed 
non-inheritance support (to mess up my version of <idate>), or implement 
my version in its entirety for either Ian's position or yours. So I 
don't think manipulating the markup is going to keep Microsoft from 
screwing us if it so desires...


From ian at hixie.ch  Thu Feb  3 10:05:16 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 18:05:16 +0000 (UTC)
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <420260A8.2070008@annevankesteren.nl>
References: <42024F83.4020904@annevankesteren.nl>
	<Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>
	<420260A8.2070008@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502031803500.26895@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> Ian Hickson wrote:
> > On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> > 
> > > I think Web Forms 2 should refer to a dated version of HTML 4.01 (for
> > > example section 2.13), not to the latest version since there is a very
> > > small chance that the definition might change eventually.
> > 
> > Why wouldn't we want WF2 to track changes in HTML4?
> 
> Because the draft someone implements might not be stable in such cases.

The link points to the stable URI, so it would only be the stable 
version, not work in progress drafts, that was referenced.


> Once HTML4 updates, WF2 could get an update of its own and match the 
> changes in other drafts.

Unfortunately as the CSS working group is discovering with CSS 2.1, the 
theory of "we'll update the spec when our dependencies change" does not 
really work. (Many specs reference CSS2, and few have been updated to 
point to CSS2.1.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Thu Feb  3 10:12:19 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 19:12:19 +0100
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <Pine.LNX.4.61.0502031803500.26895@dhalsim.dreamhost.com>
References: <42024F83.4020904@annevankesteren.nl>	<Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>	<420260A8.2070008@annevankesteren.nl>
	<Pine.LNX.4.61.0502031803500.26895@dhalsim.dreamhost.com>
Message-ID: <42026983.8020507@annevankesteren.nl>

Ian Hickson wrote:
> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> 
>> Ian Hickson wrote:
>> 
>>> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
>>> 
>>> 
>>>> I think Web Forms 2 should refer to a dated version of HTML
>>>> 4.01 (for example section 2.13), not to the latest version
>>>> since there is a very small chance that the definition might
>>>> change eventually.
>>> 
>>> Why wouldn't we want WF2 to track changes in HTML4?
>> 
>> Because the draft someone implements might not be stable in such
>> cases.
>
> The link points to the stable URI, so it would only be the stable 
> version, not work in progress drafts, that was referenced.

Sorry, I meant that some might implement a stable version of WF2 which 
gets updated indirect by a stable update of HTML4.


>> Once HTML4 updates, WF2 could get an update of its own and match
>> the changes in other drafts.
> 
> Unfortunately as the CSS working group is discovering with CSS 2.1,
> the theory of "we'll update the spec when our dependencies change"
> does not really work. (Many specs reference CSS2, and few have been
> updated to point to CSS2.1.)

There are both advantages and disadvantages in that I suppose.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From ian at hixie.ch  Fri Feb  4 06:53:09 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Feb 2005 14:53:09 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42025D48.4020709@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502041413260.25632@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Matthew Raymond wrote:
> > > >
> > > > * It is easy for authors to not include any fallback, which makes 
> > > > it worse than the <input> equivalent.
> > > 
> > > In general, it is easy to make WF2 pages incompatible with older 
> > > browsers.
> > 
> > Granted, but at least it's not the default.
> 
> When using the inheritance feature of <idate> [...]

Doing so is not the default. The default is for there to be no contents in 
the <idate>.


> > > > * The fallback and non-fallback controls have different names.
> > > 
> > > Why is that a problem? Would it not be a simple if construct on the 
> > > server side to deal with the two cases?
> > 
> > Having two different forms (as opposed to one form with just better 
> > behaviour in newer UAs) is something that the current WF2 design has, 
> > by and large, been striving for.
> 
> I know has support for having multiple forms use the same controls, but 
> what does that have to do with multiple controls being used for the same 
> field?

Sorry, my sentence got very confused. What I meant to say was:

Having two different forms (as opposed to one form with just better 
behaviour in newer UAs) is something that the current WF2 design has, by 
and large, been striving _to avoid_.

By "two different forms" I meant two different sets of controls for the 
same submission, based on whether you are submitting from a legacy UA or a 
WF2 UA (I am not referring to multiple <form> elements).

For example, this:

   <form>
    <input type="foo" name="s">
   </form>

...vs:

   <form>
    <foo name="s">
     <input name="s1">
     <input name="s2">
    </foo>
   </form>

In the first, the submission will always be the same, for new UAs like old 
UAs. For the second, the old UAs will submit two different values and new 
UAs will submit just one.


> > > >    2. <select> controls, which do not need to be replaced at all,
> > > 
> > > If that's really true, then all the date types seem a little 
> > > pointless. I thought that one of the advantages of the WF2 controls 
> > > was allowing sites to present a consistent, OS-specific interface to 
> > > form controls. If multiple select controls are as good a solution, 
> > > there seems little point in implementing or using WF2.
> > 
> > Indeed. Three <select>s are reasonably good UI, although not as good 
> > as type="date" on a supporting UA. While WF2 UAs are not in the 
> > majority, there's not really a huge advantage to using the new types. 
> > (This applies to <idate> et all as well, by the way.)
> 
> Are you arguing against the use of <idate> or against the use of <input 
> type="date">?  Most dates are entered via the three <select> scenario. 
> Therefore, if there's a compelling reason to use <input> in those cases, 
> then <idate> is even more compelling.

There isn't a compelling reason to move away from three <select>s 
(whatever the replacement). There are reasons (better UI, better 
validation, more semantic) but at the end of the day, three <select>s 
perform quite adequately and are quite accessible. Moving from three 
<select>s to something new would mean either:

   * more complexity on the author side (two sets of controls which must
     be maintained togother) _and_ on the server side (two codepaths to 
     receive dates), or

   * less usable interface for users of legacy UAs.

Given that the advantages are quite small in both cases, I do not see why 
most authors would want to make the switch. Given that, it is logical to 
use the simplest possible solution in WF2, namely just a new type and 
nothing more.


> > The difference is that if you _do_ want to use type="date", you can do 
> > so, and legacy UAs will still work (albeit not as user-friendlyly).
> 
> Same is true for <idate>, unless--EGADS!--Not the Rogue Webmaster!!!

You seem to be downplaying the likelihood of Web authors being, as you 
say, "rogue". However, my experience with existing Web content strongly 
supports the view that most authors would fall into that category.


> > With XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have 
> > to be all-or-nothing, but authors are likely to take the easy route 
> > and thus not provide any fallback content. (Just look at how many 
> > authors provide good fallback content for images.)
> 
> The difference here is that text-base browsers, so far as I know, where 
> NEVER the most popular type of browser, so there was little incentive 
> for fallback.

Image fallback is needed for a lot more than just text browsers: blind 
users, mobile users and users on dial-up connections (who have images 
disabled), search engines, etc.

And yet it is still inadequately catered for by authors.


> Not to mention the fact that IE corrupted the meaning of the |alt| 
> attribute by using it for tooltips...

This is another very good example of why we have to be _very_ wary of UA 
implementors when designing fallback mechanisms, by the way.


> > > > 3. Complex JS widgets, for which declarative fallback is not 
> > > > needed.
> > > 
> > > Why not? If one is replacing a javascript control with a WF2 
> > > control, one can improve the accessibility of one's page further by 
> > > providing simple controls for legacy clients (this would be 
> > > equivalant to say, producing a CSS based design and allowing old 
> > > browsers to recieve unstyled content v using a table based design 
> > > and blocking old browsers entirely).
> > 
> > I said _declarative_ fallback was not needed. If you're using JS, you 
> > can easily implement the fallback yourself using JS.
> 
> The <idate> element doesn't need JS at all. You're requiring webmasters 
> to either learn scripting for legacy content, or depend on his 
> Javascript programmer buddy to do the work for him.

Here, we're talking about a case where the author _already uses 
JavaScript_. So requiring JS is not a problem.


> > > > ...not to mention the extra complexity and the implementation 
> > > > difficulty compared to just using a new "type".
> > > 
> > > Really? Obviously you're much more familiar with the browser engines 
> > > than I am but I'm not sure that this is obviously difficult to 
> > > implement. At least not obviously a lot more difficult than WF2 
> > > datetime controls are anyway. Is there something specific that 
> > > browsers will struggle to cope with?
> > 
> > Nothing specific. Just every little added bit of complexity. I'm 
> > already getting requests from implementors to drop the entire 
> > repetition model, and to massively simplify the validity stuff, etc. 
> > And those aren't particularly hard to implement.
> 
> The repetition model is MORE complex than <idate>.

I beg to differ. The repetition model, to implement, requires very little 
except a few click event handlers and a modest DOM API. As far as I can 
tell implementing it is little more than translating the spec's text into 
C++ or whatever the UA is written in.

On the other hand, <idate> has element interdependencies. Change an 
attribute here, and something else has to change, etc. Move an element, 
and the entire validity of the control might change. Based on how UAs have 
screwed up this kind of thing before, I would say it is *significantly* 
harder to implement.


> Besides, isn't this what the implementation phase is for? Isn't the who 
> point of the implementation phase to find out what people will actually 
> implement and adjust the draft accordingly?

No. The implementation phase is to have people implement the spec. 
Ideally, without the spec changing at all, so that all implementations can 
then ship to consumers. If the implementation phase was guarenteed to 
result in the spec changing, then there would be no incentive in investing 
the scarce resources involved, since it would be risking that the code 
would have to be thrown out.


> Stick <idate> in, give the draft one more call before the implementation 
> phase, and if people hate it, take it out before the implementation 
> phase, or if people like it, but it's too hard to implement, it'll get 
> dropped in the implementation phase.

<idate> has at least as many problems as <input type="date">, and in my 
opinion the problems are worse on several fronts. I do not see it being 
worth adding to the spec, sorry.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Fri Feb  4 07:16:19 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Feb 2005 15:16:19 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42026298.7020106@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> > >
> > > Since IRI is now a RFC, shouldn't Web Forms use that term instead of 
> > > URI?
> > > 
> > > (For example, in section 2.12. I guess once UAs start supporting 
> > > IRIs you want a list of IRIs there, not just URIs.)
> > 
> > I've already updated all the cases that really matter. For the most 
> > part I'd like to just stick to calling things URIs since otherwise 
> > people will just get more and more confused (most people still think 
> > they're URLs...).
> 
> Does that matter for a specification?

Yes. :-)


> If you do it, you might want to add a line somewhere that URI and IRI 
> are used interchangeable.

Hm, could do.

Actually, I just went through the entire spec and made sure that every 
reference to URI is correct and every reference to IRI is correct. Let me 
know if you spot any cases that say URI when they should said IRI. I think 
they are all now correct, though.

(Also, if someone could look through section "5.6. Submitting the encoded 
form data set" and tell me which of the table cells in there aren't clear 
from a conformance point of view, that would be great. I can't see the 
wood for the trees in that section anymore.)


> Also, I think WF2 should refer to RFC3986 instead of RFC1738 since the 
> former updates the latter. RFC3986 is an internet standard and obsoletes 
> various other documents as well.

I'd updated all the relevant reference, I think. Did you see some I 
missed?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Fri Feb  4 07:20:18 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Feb 2005 15:20:18 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42026770.3070205@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net> <420262F3.7000008@cam.ac.uk>
	<42026770.3070205@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502041518120.25632@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Matthew Raymond wrote:
> 
> On a slightly unrelated note, I just realized a short time ago that the 
> Microsoft sabotage scenario could happen just as easily if <idate>, or 
> any part of it, were left out of the spec as it would be if it were 
> included as-is. All Microsoft would have to do is implement flawed 
> non-inheritance support (to mess up my version of <idate>), or implement 
> my version in its entirety for either Ian's position or yours. So I 
> don't think manipulating the markup is going to keep Microsoft from 
> screwing us if it so desires...

The odds of anyone intentionally "sabotaging" a standard or proposal in 
this way is basically zero, and not really worth any thought, IMHO.

As far as I am aware, every occurance of a "sabotage" in the Web world in 
the past 15 years has been due to misunderstandings, an accident, 
oversight, or plain stupidity, and none were intentional or malicious.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From steele at laszlosystems.com  Fri Feb  4 07:48:32 2005
From: steele at laszlosystems.com (Oliver Steele)
Date: Fri, 4 Feb 2005 10:48:32 -0500
Subject: [whatwg] drawing API
Message-ID: <82e5f4ef63edc67859055d6ceee3685e@laszlosystems.com>

Hello.  I'm new to the list, but I've looked over the archives and it 
looked like this was the right place to raise discuss this.  Apologies 
in advance if this is off topic.

I am involved with a proposal to add a procedural drawing API to the 
Laszlo RIA platform, a corporate-sponsored open source project hosted 
at http://openlaszlo.org.  We are planning to use, to the extent 
possible, a subset of that WHAT-WG graphics API 
<http://www.whatwg.org/specs/web-apps/current-work/#graphics>, for a 
variety of reasons described on the Drawing API proposal page 
<http://openlaszlo.org/wiki/Drawing_API>.

In looking over the drawing API, I found these names confusing:
   void quadraticCurveTo(in float cpx, in float cpy, in float x, in 
float y);
   void bezierCurveTo(in float cp1x, in float cp1y, in float cp2x, in 
float cp2y, in float x, in float y);
The reason is that (I assume) they both add bezier curves to the open 
path; but only one incorporates "bezier" in its name, and only one 
encodes the order of the bezier curve in its name: the names differ 
differ in that the first is "quadratic" and the second is "bezier", but 
the functionality differs in that the first is quadratic and the second 
is cubic.

A cursory scan of other modern graphics systems (Java2D, Cairo) 
indicates that they have a single curveTo() method, which takes 6 
parameters and specifies a cubic "bezier".  You can specify a quadratic 
"bezier" by using the same value for both control points. This is 
pretty inconvenient in my experience: specification of a quadratic 
bezier is actually a pretty common case.  (It's easier for programmers 
to specify; it's the common case in interactive drawing; and it's the 
only supported bezier order for some systems such as TrueType, the 
Flash rendering engine, and historical systems that have a fond place 
in my heart such as Quickdraw GX and the Alphamask Graphics Library.)

How about using a single variadic curveTo() method?:
   void curveTo(in float cpx, in float cpy, in float x, in float y); // 
quadratic bezier
   void curveTo(in float cp1x, in float cp1y, in float cp2x, in float 
cp2y, in float x, in float y); // cubic bezier
A JavaScript implementation of curveTo could distinguish these based on 
the value of arguments.length.

This would be the most convenient to users of the API, but I don't know 
what your conventions are on variadic methods and whether this has 
implications for non-JavaScript language bindings.  If this is 
unacceptable, what do you about changing the names to be parallel, and 
leaving it implicit that they're bezier's?  (I think all curveTo 
commands in modern vector graphics libraries are beziers.)
   void quadraticCurveTo(in float cpx, in float cpy, in float x, in 
float y);
   void cubicCurveTo(in float cp1x, in float cp1y, in float cp2x, in 
float cp2y, in float x, in float y);

Best,
Oliver

--
Oliver Steele
Chief Software Architect
Laszlo Systems, Inc.



From christoph.paeper at tu-clausthal.de  Fri Feb  4 08:30:33 2005
From: christoph.paeper at tu-clausthal.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Fri, 04 Feb 2005 17:30:33 +0100
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
Message-ID: <opslolg7jwofh7fl@crissov>

*Ian Hickson* <ian at hixie.ch>:
> On Mon, 31 Jan 2005, James Graham wrote:
>
>>>     2. <select> controls, which do not need to be replaced at all,
>>
>> If that's really true, then all the date types seem a little pointless.
>> I thought that one of the advantages of the WF2 controls was allowing
>> sites to present a consistent, OS-specific interface to form controls.
>> If multiple select controls are as good a solution, there seems little
>> point in implementing or using WF2.
>
> Indeed. Three <select>s are reasonably good UI,

They are easy for the programmer, but ask any usability expert: he will  
(perhaps even strongly) advice against them, because (alpha-)numerical  
input into /one/ field in ones accustomed format is much faster and  
easier. A (very) good online ticketing PoS date/time input thus has to  
understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" =  
"034" = "first Thursday in February", "next Thursday afternoon", "2nite",  
"asap" etc.p.p. (in an English speaking environment; defaulting to the  
next possible year, month, week, day, hour).

> although not as good as type="date" on a supporting UA.

Those calendar-datepickers, which are probably the expected GUI component,  
are also slower and usually not as flexible as a simple text string.  
Better than three selects at the client-side and easier to handle on the  
server-side, though.

> While WF2 UAs are not in the majority,
> there's not really a huge advantage to using the new types.

ACK, server-side intelligence is still the best. A scaled-down client-side  
version can help to avoid unnecessary requests.



From ian at hixie.ch  Mon Feb  7 06:28:16 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 14:28:16 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <opslolg7jwofh7fl@crissov>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
Message-ID: <Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>

On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
> > 
> > Indeed. Three <select>s are reasonably good UI,
> 
> They are easy for the programmer, but ask any usability expert: he will 
> (perhaps even strongly) advice against them, because (alpha-)numerical 
> input into /one/ field in ones accustomed format is much faster and 
> easier. A (very) good online ticketing PoS date/time input thus has to 
> understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" = 
> "034" = "first Thursday in February", "next Thursday afternoon", 
> "2nite", "asap" etc.p.p. (in an English speaking environment; defaulting 
> to the next possible year, month, week, day, hour).

And a mind-reading UI that can tell the user's intent without the user 
having to explicitly put it into words would presumably be even better.

Authors cannot be expected to implement everything you just described, 
especially because it is in fact impossible to determine the intent 
sometimes (for example, what date is 05/02/07?).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From fora at annevankesteren.nl  Mon Feb  7 07:03:17 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Mon, 07 Feb 2005 16:03:17 +0100
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
Message-ID: <42078335.6030705@annevankesteren.nl>

Ian Hickson wrote:
> Hm, could do.
> 
> Actually, I just went through the entire spec and made sure that 
> every reference to URI is correct and every reference to IRI is 
> correct. Let me know if you spot any cases that say URI when they 
> should said IRI. I think they are all now correct, though.

2.5. Extensions to existing attributes

Under 'maxlength': "Valid URIs and e-mail addresses in particular can
often be surprisingly long."

I guess that should be IRI since it refers to the value |type="uri"| can
have.


2.12. The datalist element and the list attribute

It could be that the UA has listed some IRIs as well though I may be
nitpicking here.


2.16. Extensions to the form element

Not sure about this. If it is an empty string, should it really be
relative to the base URI? I can remember a discussion in Bugzilla about
same-document references where there still isn't a conclusion about
this. (Among other things with regard to this.)

Or does this update the RFC in question?


6.1. Filling select elements

Why URI or IRI? IRI covers both. Same for other sections where this is
used. (See for another example 6.2.)


A. XHTML module definition

A lot of attribute can only contain URIs where it would make sense to
allow IRIs.


>> Also, I think WF2 should refer to RFC3986 instead of RFC1738 since 
>> the former updates the latter. RFC3986 is an internet standard and 
>> obsoletes various other documents as well.
> 
> I'd updated all the relevant reference, I think. Did you see some I 
> missed?

I was wondering why you were pointing to RFC1738 as well as pointing to
RFC3986. However, as you explained on IRC RFC3986 only updates the
specification it does not obsolete it.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From mattraymond at earthlink.net  Mon Feb  7 08:09:02 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 11:09:02 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
Message-ID: <4207929E.7090402@earthlink.net>

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.


From mattraymond at earthlink.net  Mon Feb  7 08:15:54 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 11:15:54 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
Message-ID: <4207943A.7050107@earthlink.net>

Ian Hickson wrote:
> On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
> 
>>>Indeed. Three <select>s are reasonably good UI,
>>
>>They are easy for the programmer, but ask any usability expert: he will 
>>(perhaps even strongly) advice against them, because (alpha-)numerical 
>>input into /one/ field in ones accustomed format is much faster and 
>>easier. A (very) good online ticketing PoS date/time input thus has to 
>>understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" = 
>>"034" = "first Thursday in February", "next Thursday afternoon", 
>>"2nite", "asap" etc.p.p. (in an English speaking environment; defaulting 
>>to the next possible year, month, week, day, hour).
> 
> And a mind-reading UI that can tell the user's intent without the user 
> having to explicitly put it into words would presumably be even better.
 >
> Authors cannot be expected to implement everything you just described, 
> especially because it is in fact impossible to determine the intent 
> sometimes (for example, what date is 05/02/07?).

    First of all, you need to apologize to Christoph for your sarcastic 
tone. It is inappropriate and unprofessional for the spokesman of WHATWG 
to be addressing a potential contributer in this manner.

    Second, you missed what he's trying to say. He's saying that people 
use the three select solution not because it's more usable, but because 
it's a pain to deal with input from a textbox. Webmasters will want to 
move to a datepicker because it provides better usability than the three 
<select> elements while offering similar usability to a textbox. 
However, they won't want the fallback to be a textbox because of the 
programming difficulties in specific situations. So the very solution 
that solves their usability problems, <input type="date">,  burns them 
in the legacy scenario.


From jim.ley at gmail.com  Mon Feb  7 08:18:29 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Mon, 7 Feb 2005 16:18:29 +0000
Subject: [whatwg] Re: several messages
In-Reply-To: <4207929E.7090402@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
	<4207929E.7090402@earthlink.net>
Message-ID: <851c8d31050207081850746a37@mail.gmail.com>

On Mon, 07 Feb 2005 11:09:02 -0500, Matthew Raymond
<mattraymond at earthlink.net> wrote:

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

It's also not a successful means of detection, it _DOES NOT_ detect
suppot for input type=date, and in the previous discussion (before I
gave up listing the flaws in the script, of which there are still
many) I mentioned the fact along with the some cases where it fails.

Please Ian, stop saying that script is perfect when it is so clearly
not.  It's obvious you've decided the input type=date stays, and as
you're the only person who has change control on the specification
your decision is final, the fact that no-one else supports you is
completely irrelevant, but please don't use that script to create
pretend justification of the degradability of input type=date.

Jim.


From mattraymond at earthlink.net  Mon Feb  7 08:19:20 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 11:19:20 -0500
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42078335.6030705@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>	<42026298.7020106@annevankesteren.nl>	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl>
Message-ID: <42079508.4090306@earthlink.net>

Anne van Kesteren wrote:
> 2.5. Extensions to existing attributes
> 
> Under 'maxlength': "Valid URIs and e-mail addresses in particular can
> often be surprisingly long."
> 
> I guess that should be IRI since it refers to the value |type="uri"| can
> have.

    Should that be |type="iri"|??? Perhaps we should have both, with 
"uri" being an alias.



From hsivonen at iki.fi  Mon Feb  7 08:47:46 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 7 Feb 2005 18:47:46 +0200
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42079508.4090306@earthlink.net>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl>
	<42079508.4090306@earthlink.net>
Message-ID: <5581891207a1c6391619906e9bf9df84@iki.fi>

On Feb 7, 2005, at 18:19, Matthew Raymond wrote:

> Should that be |type="iri"|??? Perhaps we should have both, with "uri" 
> being an alias.

Aliases are annoying from the implementation point of view. I once 
tried supporting attributes in no namespace and attributes in the 
namespace of the element at the same time. Not fun.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/



From jg307 at cam.ac.uk  Mon Feb  7 08:55:52 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Mon, 07 Feb 2005 16:55:52 +0000
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
Message-ID: <42079D98.1000304@cam.ac.uk>

Ian Hickson wrote:

>On Mon, 31 Jan 2005, James Graham wrote:
>  
>
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>>* It is easy for authors to not include any fallback, which makes it 
>>>worse than the <input> equivalent.
>>>      
>>>
>>In general, it is easy to make WF2 pages incompatible with older 
>>browsers.
>>    
>>
>
>Granted, but at least it's not the default.
>  
>
True and I'll grant that such a situation is less than ideal. But given 
the high penetration of non-WF2 browsers, it is unlikely that anyone 
will be producing WF2-only content for some considerable time to come. 
Comparisons with missing alt-text and with sites requiring javascript 
are rather misleading. Alt text suffers because graphical browsers have 
such high penetration that many designers believe that everyone will see 
their graphics (and at the 98 or 99% level, they are probably right). 
Good alt text is also *very* hard (and sometimes impossible) to write 
since one has to replace the often complex content of a picture with a 
few words. There is also the historic problem of alt-text-as-tooltips 
which produced significant confusion as to the point of alt text. With 
WF2 date types, none of these points apply.
Javascript is also a poor comparison since javascript allows 
fundamentally new features to be implemented by the website compared to 
those allowed with pure markup. This means it is often difficult for 
designers to envision how their carfully designed interaction model for 
a site should work without the extra scripting features. Then since the 
javascript-enabled population is currently a significant majority of web 
users.

>>>* The fallback and non-fallback controls have different names.
>>>      
>>>
>>Why is that a problem? Would it not be a simple if construct on the 
>>server side to deal with the two cases?
>>    
>>
>
>Having two different forms (as opposed to one form with just better 
>behaviour in newer UAs) is something that the current WF2 design has, by 
>and large, been striving for.
>  
>
Which is easy to achieve when the WF2 control is well represented as a 
single HTML4 control. There seems to be some agreement that this isn't 
the case for date controls (single textboxes are much harder than 
necessary to use). It seems a shame to sacrifice a useful feature for a 
design ideal that is of limited practical benefit.

>
>  
>
>>>    2. <select> controls, which do not need to be replaced at all,
>>>      
>>>
>>If that's really true, then all the date types seem a little pointless. 
>>I thought that one of the advantages of the WF2 controls was allowing 
>>sites to present a consistent, OS-specific interface to form controls. 
>>If multiple select controls are as good a solution, there seems little 
>>point in implementing or using WF2.
>>    
>>
>
>Indeed. Three <select>s are reasonably good UI, although not as good as 
>type="date" on a supporting UA. While WF2 UAs are not in the majority, 
>there's not really a huge advantage to using the new types. (This applies 
>to <idate> et all as well, by the way.)
>  
>
So are we planning to suggest that people not use the new date types 
until the uptake of WF2 reaches some magic value (what value?). I think 
taking the position that people should hold off using new features until 
they are supported everywhere rather diminishes the point of having 
backward compatibility, considering the extra trauma that specifying a 
backward compatible syntax for everything creates. It also ignores the 
feedback between users and UA authors. Opera are implementing 
XmlHttpRequest as a direct result of a site (GMail) using a feature that 
they didn't support. Mozilla dropped MNG because it wasn't being used 
anywhere (if MNG was used on even 1% of websites, the codesize issue 
would never have come up). One can't simply wait on all browser makers 
to implement something and then certify it as OK for general use. One 
needs actual adoption on the real web to force browser makers to 
implement something.

Given that the new date types will produce a significant improvement in 
UI, I want every site to be using them as soon as possible - long before 
WF2 browsers have 99% of the market. If they're designed in such a way 
that the fallback content is a much worse UI than whatever those sites 
are using at the moment, that won't happen and browser makers will be 
much slower to implement the types at-all.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs



From ian at hixie.ch  Mon Feb  7 08:59:19 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 16:59:19 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42078335.6030705@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502071655070.24987@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, Anne van Kesteren wrote:
> > 
> > Actually, I just went through the entire spec and made sure that every 
> > reference to URI is correct and every reference to IRI is correct. Let 
> > me know if you spot any cases that say URI when they should said IRI. 
> > I think they are all now correct, though.
> 
> 2.5. Extensions to existing attributes
> 
> Under 'maxlength': "Valid URIs and e-mail addresses in particular can 
> often be surprisingly long."
> 
> I guess that should be IRI since it refers to the value |type="uri"| can 
> have.

I left that one because the term "URI" is more likely to be understood 
than "IRI", and that sentence is aimed at explaining a conformance 
criteria to authors. (Note that that sentence is not itself a conformance 
criteria but a statement.)


> 2.12. The datalist element and the list attribute
> 
> It could be that the UA has listed some IRIs as well though I may be
> nitpicking here.

Again, the occurances here are either in explanatory text or in examples, 
which are themselves non-normative by definition.


> 2.16. Extensions to the form element
> 
> Not sure about this. If it is an empty string, should it really be
> relative to the base URI? I can remember a discussion in Bugzilla about
> same-document references where there still isn't a conclusion about
> this. (Among other things with regard to this.)
> 
> Or does this update the RFC in question?

The Bugzilla discussion to which you refer was regarding fragment 
identifiers; there are none in this case.


> 6.1. Filling select elements
> 
> Why "URI or IRI"? IRI covers both. Same for other sections where this is 
> used. (See for another example 6.2.)

Again, because the term "URI" is much more likely to be understood than 
"IRI". Mentioning both means that the conformance criteria is exact while 
still making the intent clear.


> A. XHTML module definition
> 
> A lot of attribute can only contain URIs where it would make sense to
> allow IRIs.

AIUI, we are restricted by XHTML M12N here.


> > > Also, I think WF2 should refer to RFC3986 instead of RFC1738 since 
> > > the former updates the latter. RFC3986 is an internet standard and 
> > > obsoletes various other documents as well.
> > 
> > I'd updated all the relevant reference, I think. Did you see some I 
> > missed?
> 
> I was wondering why you were pointing to RFC1738 as well as pointing to 
> RFC3986. However, as you explained on IRC RFC3986 only updates the 
> specification it does not obsolete it.

Indeed.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From olav at olav.dk  Mon Feb  7 09:50:07 2005
From: olav at olav.dk (=?ISO-8859-1?Q?Olav_Junker_Kj=E6r?=)
Date: Mon, 07 Feb 2005 18:50:07 +0100
Subject: [whatwg] Web Forms 2 stable draft draft
In-Reply-To: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>
Message-ID: <4207AA4F.5050704@olav.dk>

You write:
 > The model used by the validity  DOM attribute is not very clean, and
 > may deserve to be replaced with something that has been thought
 > through with more care

Perhaps the bit field interface could be left out. The only thing that 
can't be done through the properties, is easily checking if the field is 
valid or not, like:
   if (field1.validity) ...
This could be supported by having the validity attribute return null 
when the field is valid. The ValidityState object would then alway be 
the description of an error.
This may be a bad idea though, since code like:

   if (field1.validity.isPatternMismatch) ...

would generate an error when the field is valid.
A better solution would perhaps be to add an attribute, "isValid" to 
ValidationState. So you could write:

  if (field1.validity.isValid) ...

Only problem is that the naming seems a bit strange. "validityState" 
would be clearer than "validity", but also a bit more cumbersome.

Anyway, it seems a bit redundant to support both the bit field and 
property interfaces.

regards
Olav Junker Kj?r


From ian at hixie.ch  Mon Feb  7 14:35:46 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 22:35:46 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <4207929E.7090402@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
	<4207929E.7090402@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>

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.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Mon Feb  7 14:44:55 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 22:44:55 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <4207943A.7050107@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, Matthew Raymond wrote:
> Ian Hickson wrote:
> > On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
> > 
> > > > Indeed. Three <select>s are reasonably good UI,
> > > 
> > > They are easy for the programmer, but ask any usability expert: he 
> > > will (perhaps even strongly) advice against them, because 
> > > (alpha-)numerical input into /one/ field in ones accustomed format 
> > > is much faster and easier. A (very) good online ticketing PoS 
> > > date/time input thus has to understand "2/3" = "3.2." = "Feb 3rd" = 
> > > "3 Feb." = "02-03" = "w05-4" = "034" = "first Thursday in February", 
> > > "next Thursday afternoon", "2nite", "asap" etc.p.p. (in an English 
> > > speaking environment; defaulting to the next possible year, month, 
> > > week, day, hour).
> > 
> > And a mind-reading UI that can tell the user's intent without the user 
> > having to explicitly put it into words would presumably be even 
> > better.
> >
> > Authors cannot be expected to implement everything you just described, 
> > especially because it is in fact impossible to determine the intent 
> > sometimes (for example, what date is 05/02/07?).
> 
> First of all, you need to apologize to Christoph for your sarcastic tone.

Apologies.


> Second, you missed what he's trying to say. He's saying that people use 
> the three select solution not because it's more usable, but because it's 
> a pain to deal with input from a textbox.

That certainly isn't what I understood from his message.

I disagree that that is the reason <select>s are used for date input.

I disagree with the assertion that text input is more accessible and 
usable than three <select>s. Indeed, if it was, I wouldn't be worried 
about the fact that type="date" has poor fallback, since by that argument 
it would in fact have good fallback.

A simple text box is IMHO hard to use because, without a suggested format, 
the user has no guidance as to what to enter. Since users have been 
conditioned to only provide data in the Correct Format, the user is more 
likely to be confused by an empty text field than by three clear drop-down 
widgets containing what are obviously days, months and years.


> Webmasters will want to move to a datepicker because it provides better 
> usability than the three <select> elements while offering similar 
> usability to a textbox.
> However, they won't want the fallback to be a textbox because of the 
> programming difficulties in specific situations.

Handling free-form input for dates isn't that hard if you are willing to 
reject anything that doesn't match a given format. You can even suggest 
one format and accept a number of other popular formats, assuming that you 
only accept unambiguous formats.

It is extremely hard to do, however, if you are not willing to reject 
data, since then you have to be able to determine the meaning of dates 
like 05-02-07 (this is an actual date).


> So the very solution that solves their usability problems, <input 
> type="date">, burns them in the legacy scenario.

I agree that <input type="date"> has a poor fallback story. I just haven't 
seen any proposals that have fewer problems.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Mon Feb  7 14:47:48 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 22:47:48 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42079508.4090306@earthlink.net>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl> <42079508.4090306@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502072245230.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, Matthew Raymond wrote:
> Anne van Kesteren wrote:
> > 2.5. Extensions to existing attributes
> > 
> > Under 'maxlength': "Valid URIs and e-mail addresses in particular can
> > often be surprisingly long."
> > 
> > I guess that should be IRI since it refers to the value |type="uri"| can
> > have.
> 
> Should that be |type="iri"|??? Perhaps we should have both, with "uri" 
> being an alias.

I believe type="uri" would be a lot easier for authors to understand. I 
generally would suggest we stay away from aliases unless we have very 
specific needs for them, because they are an implementation nightmare 
(you have to deal with obscure problems like "what does the DOM |type| 
attribute return?" and "how do you canonicalise the document?").

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From gkilwein at fbsdata.com  Mon Feb  7 15:03:40 2005
From: gkilwein at fbsdata.com (Greg Kilwein)
Date: Mon, 07 Feb 2005 17:03:40 -0600
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>
	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>
Message-ID: <4207F3CC.9070508@fbsdata.com>


>The problems with what I understand of your proposal are:
>
>[snip]
> * Fallback needs author involvement
>    - easiest to simply not support legacy
>    - server typically needs to handle different names for controls,
>      not just different format
>
I'll add one more problem - the author cannot easily test the fallback 
content in the UA of <idate/> if the author doesn't have a legacy UA 
available.  If the author can't easily test it, the odds of the fallback 
content being missing or broken are higher.

Greg



From ian at hixie.ch  Mon Feb  7 15:15:26 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 23:15:26 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42079D98.1000304@cam.ac.uk>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42079D98.1000304@cam.ac.uk>
Message-ID: <Pine.LNX.4.61.0502072248470.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, James Graham wrote:
>
> True and I'll grant that such a situation is less than ideal. But given 
> the high penetration of non-WF2 browsers, it is unlikely that anyone 
> will be producing WF2-only content for some considerable time to come. 

Sure. But when they do, we don't want them to be encouraged to drop 
support for the then-minority browsers.


> > > > * The fallback and non-fallback controls have different names.
> > >
> > > Why is that a problem? Would it not be a simple if construct on the 
> > > server side to deal with the two cases?
> > 
> > Having two different forms (as opposed to one form with just better 
> > behaviour in newer UAs) is something that the current WF2 design has, 
> > by and large, been striving for
>
> Which is easy to achieve when the WF2 control is well represented as a 
> single HTML4 control. There seems to be some agreement that this isn't 
> the case for date controls (single textboxes are much harder than 
> necessary to use). It seems a shame to sacrifice a useful feature for a 
> design ideal that is of limited practical benefit.

I don't think it's that limited. In fact I think that given the knock-on 
effects (different names on the server, different code paths in scripts, 
multiple variants to test, etc) it is quite important, at least as 
important as having a good legacy fallback story.


> > Indeed. Three <select>s are reasonably good UI, although not as good 
> > as type="date" on a supporting UA. While WF2 UAs are not in the 
> > majority, there's not really a huge advantage to using the new types. 
> > (This applies to <idate> et all as well, by the way.)
> 
> So are we planning to suggest that people not use the new date types 
> until the uptake of WF2 reaches some magic value (what value?). I think 
> taking the position that people should hold off using new features until 
> they are supported everywhere rather diminishes the point of having 
> backward compatibility, considering the extra trauma that specifying a 
> backward compatible syntax for everything creates.

It depends what people would be using instead. If they would just be using 
a single text field (as many are) then using type="date" gives an 
immediate benefit. Similarly, if they are currently using complex 
JavaScript, then it makes sense to use type="date" and then have some 
script that detects whether or not that is supported (by comparing the 
input element's |type| DOM attribute to the value "date") and if it isn't, 
replacing it with what is being used today.

And other types -- type="time", "number", "uri", etc -- make sense today 
as well, with or without UA support. It's only really "date", "datetime", 
"datetime-local", and "range" that have poor fallback.


> It also ignores the feedback between users and UA authors. Opera are 
> implementing XmlHttpRequest as a direct result of a site (GMail) using a 
> feature that they didn't support.

But DOM3 Load and Save was implemented first, despite that not being used 
anywhere.


> Mozilla dropped MNG because it wasn't being used anywhere (if MNG was 
> used on even 1% of websites, the codesize issue would never have come 
> up).

The reasons for dropping MNG are far more complex than that.


> One can't simply wait on all browser makers to implement something and 
> then certify it as OK for general use. One needs actual adoption on the 
> real web to force browser makers to implement something.

Not always. Opera, Mozilla and Safari all support XHTML, but there's 
basically no real use of XHTML on the Web. Mozilla supports MathML, and 
there's even less MathML than XHTML. There's now an XForms plugin for 
Mozilla, and there's no XForms content.

Yet the same browsers don't support ActiveX, despite that being heavily 
used. Opera doesn't support XSLT, yet there is author demand for that 
(misguided as it may be).

In fact, I would say that in general, it is much more often the case that 
the UAs have to implement something before the authors use it. It's only 
when one UA is lagging behind on one particular feature that the authoring 
community can push for that UA to implement something (XmlHttpRequest 
being a good recent example here -- Opera was only forced to implement it 
because everyone else already had implemented it.)


> Given that the new date types will produce a significant improvement in 
> UI, I want every site to be using them as soon as possible - long before 
> WF2 browsers have 99% of the market. If they're designed in such a way 
> that the fallback content is a much worse UI than whatever those sites 
> are using at the moment, that won't happen and browser makers will be 
> much slower to implement the types at-all.

Since most of the new types do not have this problem, I do not think that 
you need worry.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From stuartp at gmail.com  Mon Feb  7 15:16:14 2005
From: stuartp at gmail.com (Stuart Parmenter)
Date: Mon, 7 Feb 2005 15:16:14 -0800
Subject: [whatwg] drawing API
In-Reply-To: <82e5f4ef63edc67859055d6ceee3685e@laszlosystems.com>
References: <82e5f4ef63edc67859055d6ceee3685e@laszlosystems.com>
Message-ID: <a8d4ef520502071516284b02c4@mail.gmail.com>

On Fri, 4 Feb 2005 10:48:32 -0500, Oliver Steele
<steele at laszlosystems.com> wrote:
> How about using a single variadic curveTo() method?:
>    void curveTo(in float cpx, in float cpy, in float x, in float y); //
> quadratic bezier
>    void curveTo(in float cp1x, in float cp1y, in float cp2x, in float
> cp2y, in float x, in float y); // cubic bezier
> A JavaScript implementation of curveTo could distinguish these based on
> the value of arguments.length.

Using varargs should be avoided in IDL if possible as it is a language
specific feature.  There are also people shipping with the above API
so I'd prefer to not see it change.  Cubic may have been a better name
than bezier for it, but I think it is minor.

stuart


From ian at hixie.ch  Mon Feb  7 15:20:49 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 23:20:49 +0000 (UTC)
Subject: [whatwg] Web Forms 2 stable draft draft
In-Reply-To: <4207AA4F.5050704@olav.dk>
References: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>
	<4207AA4F.5050704@olav.dk>
Message-ID: <Pine.LNX.4.61.0502072315510.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, [ISO-8859-1] Olav Junker Kj?r wrote:
> You write:
> > The model used by the validity  DOM attribute is not very clean, and
> > may deserve to be replaced with something that has been thought
> > through with more care
> 
> Perhaps the bit field interface could be left out.

Yeah, I'm considering it. My main reason not to just do it is that it 
would require _massive_ changes to the draft (everything is currently 
defined in terms of the bit masks, and the object is then defined in 
terms of that).


> A better solution would perhaps be to add an attribute, "isValid" to 
> ValidationState. So you could write:
> 
>  if (field1.validity.isValid) ...
> 
> Only problem is that the naming seems a bit strange. "validityState" 
> would be clearer than "validity", but also a bit more cumbersome.

That's pretty much the line of thought I had on the matter.


> Anyway, it seems a bit redundant to support both the bit field and 
> property interfaces.

I agree. Hence the comment in the status section. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From rimantas at gmail.com  Mon Feb  7 16:03:55 2005
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Tue, 8 Feb 2005 02:03:55 +0200
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net> <41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
	<Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
Message-ID: <5ccfb3340502071603daa4931@mail.gmail.com>

<...>
Looks like Cristoph really does know this stuff (I mean usability),
and I am with him
on this one.

> I disagree that that is the reason <select>s are used for date input.
> 
> I disagree with the assertion that text input is more accessible and
> usable than three <select>s. Indeed, if it was, I wouldn't be worried
> about the fact that type="date" has poor fallback, since by that argument
> it would in fact have good fallback.

I have seen enough recommendations "use drop-down list to prevent
invalid date entries",
to believe, that this is main reason for using <select>.
As user I hate those triplets, they require too much manipulation and
I am afraid even to think how does it feel for someone with motoric
disabilities.

To enter some date you must: Click on the year drop-down. Scroll to
the right item. Click on it (and be sure not to miss). Repeat for the
month. Repeat for the day.
I am unfortunate to be born at the end of the year so I almost always
forced to scroll those lists. Text field does not require any
jumping/tabbing/scrolling/clicking.

> A simple text box is IMHO hard to use because, without a suggested format,
> the user has no guidance as to what to enter. Since users have been
> conditioned to only provide data in the Correct Format, the user is more
> likely to be confused by an empty text field than by three clear drop-down
> widgets containing what are obviously days, months and years.

User obviously does know what date he want to enter, so why to be
afraid of text box?
What IS confusing is to guess which is the Correct Format. There is no
de facto standard
on this, so forcing some format on the user will break the main
usability principle: "don't make me think" (or do not make me feel
stupid). Hints like DD-MM-/YYYY (and especially MM/DD/YY ones) are not
of much help, because you still have to decipher and parse them in
your head (that is - think).
 
> > Webmasters will want to move to a datepicker because it provides better
> > usability than the three <select> elements while offering similar
> > usability to a textbox.
> > However, they won't want the fallback to be a textbox because of the
> > programming difficulties in specific situations.
> 
> Handling free-form input for dates isn't that hard if you are willing to
> reject anything that doesn't match a given format. You can even suggest
> one format and accept a number of other popular formats, assuming that you
> only accept unambiguous formats.

To quote Donald Norman (http://www.jnd.org/GoodDesign.html):
---
Hurrah for Microsoft! Too many companies force you to enter dates in
their preferred format (and often they only tell you after you do it
wrong. In Outlook calendar, you can type almost anything, and it is
interpreted properly. For example, "tomorrow," "day after tomorrow,"
"next day," Wednesday," Wed." Oct. 24, 24 Oct, 14/10, 10/14, etc.
Kudos to Microsoft
---
 
> It is extremely hard to do, however, if you are not willing to reject
> data, since then you have to be able to determine the meaning of dates
> like 05-02-07 (this is an actual date).

Cristoph has suggested how to deal with this: next possible date,
context depended, of course.

If you buy a ticket to the cinema online, if would be 2005-02-07,
cause you cannot buy tickets to the cinema in year 2002, or 2007,
2005-07-02 does not make much sense either.
Sure, there will be tough cases, but "probability vs. possibility"
principle still does apply.

>From the usability point of view my vote would be text box with
capabilities which Norman describes (so you can just type 'tonight')
and date-picker component beside.(like
http://www.dynarch.com/demos/jscalendar/).

Regards,
Rimantas
--
http://rimantas.com/


From ian at hixie.ch  Mon Feb  7 16:40:48 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 8 Feb 2005 00:40:48 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <5ccfb3340502071603daa4931@mail.gmail.com>
References: <41F659E0.1040709@earthlink.net> <41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
	<Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
	<5ccfb3340502071603daa4931@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0502080018000.27753@dhalsim.dreamhost.com>

On Tue, 8 Feb 2005, Rimantas Liubertas wrote:
> 
> To enter some date you must: Click on the year drop-down. Scroll to the 
> right item. Click on it (and be sure not to miss). Repeat for the month. 
> Repeat for the day.

(Just FYI, you can actually use the keyboard as well: click the first 
control, then start typing, then press tab, type, tab, type. Most UAs jump 
to the right item in the drop down when you start typing in one.)


> User obviously does know what date he want to enter, so why to be afraid 
> of text box? What IS confusing is to guess which is the Correct Format. 
> There is no de facto standard on this, so forcing some format on the 
> user will break the main usability principle: "don't make me think" (or 
> do not make me feel stupid). Hints like DD-MM-/YYYY (and especially 
> MM/DD/YY ones) are not of much help, because you still have to decipher 
> and parse them in your head (that is - think).

Well, if text fields represent good UI for date inputs, then the current 
fallback for <input type="date"> seems fine. People were arguing that it 
wasn't good UI, and that therefore it wasn't fine.


> > > Webmasters will want to move to a datepicker because it provides 
> > > better usability than the three <select> elements while offering 
> > > similar usability to a textbox. However, they won't want the 
> > > fallback to be a textbox because of the programming difficulties in 
> > > specific situations.
> > 
> > Handling free-form input for dates isn't that hard if you are willing 
> > to reject anything that doesn't match a given format. You can even 
> > suggest one format and accept a number of other popular formats, 
> > assuming that you only accept unambiguous formats.
> 
> To quote Donald Norman (http://www.jnd.org/GoodDesign.html):
> ---
> Hurrah for Microsoft! Too many companies force you to enter dates in
> their preferred format (and often they only tell you after you do it
> wrong. In Outlook calendar, you can type almost anything, and it is
> interpreted properly. For example, "tomorrow," "day after tomorrow,"
> "next day," Wednesday," Wed." Oct. 24, 24 Oct, 14/10, 10/14, etc.
> Kudos to Microsoft
> ---

Yeah, that's the best. It's also the hardest to implement! :-) But authors 
are certainly free to implement that, as are Web Browser implementors.


> From the usability point of view my vote would be text box with 
> capabilities which Norman describes (so you can just type 'tonight') and 
> date-picker component beside.(like 
> http://www.dynarch.com/demos/jscalendar/).

Yup, that's definitely an allowed way of implementing type="date".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From christoph.paeper at tu-clausthal.de  Mon Feb  7 18:40:19 2005
From: christoph.paeper at tu-clausthal.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 08 Feb 2005 03:40:19 +0100
Subject: [whatwg] Re: several messages
In-Reply-To: <4207943A.7050107@earthlink.net>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
Message-ID: <opsluxphesofh7fl@crissov>

*Matthew Raymond* <mattraymond at earthlink.net>:
> Ian Hickson wrote:
>> On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
>>
>>>> Indeed. Three <select>s are reasonably good UI,
>>>
>>> They are easy for the programmer, but ask any usability expert: he  
>>> will (perhaps even strongly) advice against them, because  
>>> (alpha-)numerical input into /one/ field in ones accustomed format is  
>>> much faster and easier.

Three 'input' are yet another case, btw.

>>> A (very) good online ticketing PoS date/time input thus has to  
>>> understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" =  
>>> "034" = "first Thursday in February", "next Thursday afternoon",  
>>> "2nite", "asap" etc.p.p. (in an English speaking environment; 
>>> defaulting to the next possible year, month, week, day, hour).
>>
>>  And a mind-reading UI that can tell the user's intent without the user  
>> having to explicitly put it into words would presumably be even better.

Sure, the perfect human machine input device. (I'm not sure I would want  
to use the output device using a reverse technology.) I actually expect to  
see such a thing in my lifetime, although towards the statistical end of  
it and not in every home.

>> Authors cannot be expected to implement everything you just described,

At least not everyone by himself, each time.

>> especially because it is in fact impossible to determine the intent  
>> sometimes (for example, what date is 05/02/07?).

If it's a form on an English site for an international audience requesting  
dates in the future, it's very likely May 2nd, 2007, because I would then  
consider USAn style the default when the separator is '/'. In other  
_contexts_ it might be just yesterday (in my timezone). Of course you  
don't accept ambiguous input data without the user having check and  
acknowledge it. '<input type="date">' can help to avoid that step, because  
the UA either offers a GUI that produces valid dates only or does the  
checking of textual input without the need for author action. The  
remaining problem would be HTML UAs.

> First of all, you need to apologize to Christoph for your sarcastic tone.

Actually, I don't mind.

>     Second, you missed what he's trying to say. He's saying that people  
> use the three select solution not because it's more usable, but because  
> it's a pain to deal with input from a textbox.

That is what I was saying.

> However, [webmasters] won't want the fallback to be a textbox because of  
> the programming difficulties in specific situations.

A simple 'text' 'input' has the advantage that it generates only one  
parameter to be handled by the server (and an optional client-side  
validation script), just like the 'date' 'input' does. The most basic  
handling would be to reject anything that is not an ISO?8601 conformant  
string (in the valid time frame), requiring the user to resubmit. From  
there on you can get as complex guessing as you want. Unambiguous, valid  
inputs are (silently) accepted, others rejected. Rejection on ambiguity  
should include showing the user the guessed likeliest value in an  
unambiguous format, so he hopefully just has to accept without further  
changing. The lesser advanced the guess script, the more important it is  
to inform the user of the expected input style.

 From the point of usability I wouldn't want '<input type="date">' to fall  
back to anything but '<input type="text">'. Neither from the point of  
marking-up and styling. In this case the programmer has to swallow the  
bitter pill, IMVHO. After all it's a recurring problem for which he has to  
find or write a solution only once (at least in theory).


From mattraymond at earthlink.net  Mon Feb  7 18:44:33 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 21:44:33 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <4207F3CC.9070508@fbsdata.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>
	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>
	<4207F3CC.9070508@fbsdata.com>
Message-ID: <42082791.6070104@earthlink.net>

Greg Kilwein wrote:
> I'll add one more problem - the author cannot easily test the fallback 
> content in the UA of <idate/> if the author doesn't have a legacy UA 
> available.  If the author can't easily test it, the odds of the fallback 
> content being missing or broken are higher.

    Who are you kidding? To test <idate>, you just comment out the 
"<idate>" tags:

| <!-- <idate> -->
|  <input name="date1">
| <!-- </idate> -->

    Or you write the fallback and test it before adding the date-related 
WF2 markup.


From mattraymond at earthlink.net  Tue Feb  8 05:30:55 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 08 Feb 2005 08:30:55 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<opslolg7jwofh7fl@crissov>	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>	<4207943A.7050107@earthlink.net>
	<Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
Message-ID: <4208BF0F.6080404@earthlink.net>

Ian Hickson wrote:
> On Mon, 7 Feb 2005, Matthew Raymond wrote:
>>First of all, you need to apologize to Christoph for your sarcastic tone.
> 
> Apologies.

   Thank you.

>>Second, you missed what he's trying to say. He's saying that people use 
>>the three select solution not because it's more usable, but because it's 
>>a pain to deal with input from a textbox.
> 
[Snip!]
> I disagree with the assertion that text input is more accessible and 
> usable than three <select>s. Indeed, if it was, I wouldn't be worried 
> about the fact that type="date" has poor fallback, since by that argument 
> it would in fact have good fallback.

    Not really. Three selects eliminates date formatting and parsing 
from the equation. That's why webmasters like it. It means that they 
don't have to think about how to handle the date input and the user 
doesn't have to know how to type the date in properly. It's a system 
with fewer points of failure.

> A simple text box is IMHO hard to use because, without a suggested format, 
> the user has no guidance as to what to enter.

    The vast majority of people using text boxes for date input provide 
formatting hints.

 > Since users have been
> conditioned to only provide data in the Correct Format, the user is more 
> likely to be confused by an empty text field than by three clear drop-down 
> widgets containing what are obviously days, months and years.

    This can be true under specific circumstances. It is not true for a 
date picker, which can use built-in browser format parsing (or enforce a 
native date format) and provide optional calendar selection. So you a 
date control give you both improved reliability and improved usability. 
It can even provide you with a combination of drop-down lists and text 
entry, if the user agent vendor so chooses.

> Handling free-form input for dates isn't that hard if you are willing to 
> reject anything that doesn't match a given format. You can even suggest 
> one format and accept a number of other popular formats, assuming that you 
> only accept unambiguous formats.

    Which, in the case of <input type="date">, requires more scripting 
than a legacy text box because you have to not only code for the 
different formats but you have to have scripting that implants 
formatting hints into the DOM.

> It is extremely hard to do, however, if you are not willing to reject 
> data, since then you have to be able to determine the meaning of dates 
> like 05-02-07 (this is an actual date).

    Which is exactly why you need formatting hints.


From mattraymond at earthlink.net  Tue Feb  8 06:22:42 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 08 Feb 2005 09:22:42 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502072248470.27753@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<42079D98.1000304@cam.ac.uk>
	<Pine.LNX.4.61.0502072248470.27753@dhalsim.dreamhost.com>
Message-ID: <4208CB32.6020305@earthlink.net>

Ian Hickson wrote:
> On Mon, 7 Feb 2005, James Graham wrote:
>>True and I'll grant that such a situation is less than ideal. But given 
>>the high penetration of non-WF2 browsers, it is unlikely that anyone 
>>will be producing WF2-only content for some considerable time to come. 
> 
> Sure. But when they do, we don't want them to be encouraged to drop 
> support for the then-minority browsers.

    Why would we care??? ;)

>>>>>* The fallback and non-fallback controls have different names.
>>>>
>>>>Why is that a problem? Would it not be a simple if construct on the 
>>>>server side to deal with the two cases?
>>>
>>>Having two different forms (as opposed to one form with just better 
>>>behaviour in newer UAs) is something that the current WF2 design has, 
>>>by and large, been striving for
>>
>>Which is easy to achieve when the WF2 control is well represented as a 
>>single HTML4 control. There seems to be some agreement that this isn't 
>>the case for date controls (single textboxes are much harder than 
>>necessary to use). It seems a shame to sacrifice a useful feature for a 
>>design ideal that is of limited practical benefit.
> 
> I don't think it's that limited. In fact I think that given the knock-on 
> effects (different names on the server, different code paths in scripts, 
> multiple variants to test, etc) it is quite important, at least as 
> important as having a good legacy fallback story.

    It's far easier to get reliable scripting on the server than on a 
client, since the clients are varied and unlimited in number, whereas 
the server is not. Therefore, while there may be some small additional 
overhead in dealing with dates, it's far easier to handle that 
server-side than try to get the client to behave as you would like.

>>>Indeed. Three <select>s are reasonably good UI, although not as good 
>>>as type="date" on a supporting UA. While WF2 UAs are not in the 
>>>majority, there's not really a huge advantage to using the new types. 
>>>(This applies to <idate> et all as well, by the way.)
>>
>>So are we planning to suggest that people not use the new date types 
>>until the uptake of WF2 reaches some magic value (what value?). I think 
>>taking the position that people should hold off using new features until 
>>they are supported everywhere rather diminishes the point of having 
>>backward compatibility, considering the extra trauma that specifying a 
>>backward compatible syntax for everything creates.
> 
> It depends what people would be using instead. If they would just be using 
> a single text field (as many are) then using type="date" gives an 
> immediate benefit.

    Only if they solve the formatting problem, and only if their server 
is set up to handle ISO 8601 formatted date strings.

> Similarly, if they are currently using complex 
> JavaScript, then it makes sense to use type="date" and then have some 
> script that detects whether or not that is supported (by comparing the 
> input element's |type| DOM attribute to the value "date") and if it isn't, 
> replacing it with what is being used today.

    Or, assuming what they have fulfills their needs, they could stick 
with what they have and avoid adding the extra "code paths in scripts" 
on the client, which may have varying levels of Javascript compliance 
depending on the user agent.

> And other types -- type="time", "number", "uri", etc -- make sense today 
> as well, with or without UA support.  It's only really "date", "datetime",
> "datetime-local", and "range" that have poor fallback.

    Actually, "time" has several different formats, as does "week" and 
"month".

>>It also ignores the feedback between users and UA authors. Opera are 
>>implementing XmlHttpRequest as a direct result of a site (GMail) using a 
>>feature that they didn't support.
> 
> But DOM3 Load and Save was implemented first, despite that not being used 
> anywhere.

    I presume you mean on Opera, because I'm pretty sure Mozilla hasn't 
implemented it yet, although they implemented something with similar 
functionality.

>>Mozilla dropped MNG because it wasn't being used anywhere (if MNG was 
>>used on even 1% of websites, the codesize issue would never have come 
>>up).
> 
> The reasons for dropping MNG are far more complex than that.

    Not really. There were many suggestions on how to reduce the size of 
MING support in Mozilla, and they managed to reduce file size 
significantly and even produce a number of potential compromises that 
would have brought the file size down farther. Unfortunately, there 
seems to be a great deal of apathy with regards to all suggestions put 
forward, and I can only attribute that to the fact that there wasn't 
strong demand for MNG on the part of webmasters.

    Pity. Animations with JPEG compressed RGBA images are pretty cool.

>>One can't simply wait on all browser makers to implement something and 
>>then certify it as OK for general use. One needs actual adoption on the 
>>real web to force browser makers to implement something.
> 
> Not always. Opera, Mozilla and Safari all support XHTML, but there's 
> basically no real use of XHTML on the Web. Mozilla supports MathML, and 
> there's even less MathML than XHTML. There's now an XForms plugin for 
> Mozilla, and there's no XForms content.

    Minority browsers will always be inclined to add standards that 
aren't necessarily used on the majority of websites. It allows them 
greater access to niche markets, where minority software tend to do the 
best.

> Yet the same browsers don't support ActiveX, despite that being heavily 
> used.

    That's because Microsoft could simply make ActiveX a moving target 
like they did with a number of other products. Why add a technology that 
has a fundamentally flawed security model when you can't even ensure 
that Microsoft won't introduce a new incompatible version tomorrow?

 > Opera doesn't support XSLT, yet there is author demand for that
> (misguided as it may be).

    Due to the fact that Opera is designed to run on small devices, 
where supporting XSLT may not be desirable, Opera's somewhat of a 
special case.

> In fact, I would say that in general, it is much more often the case that 
> the UAs have to implement something before the authors use it.

    That's more the case with plug-ins, I would think.

 > It's only
> when one UA is lagging behind on one particular feature that the authoring 
> community can push for that UA to implement something (XmlHttpRequest 
> being a good recent example here -- Opera was only forced to implement it 
> because everyone else already had implemented it.)

    XmlHttpRequest, as I recall, was put into IE first. Because of IE's 
marketshare, all the other browser makers had to follow suit. It's not 
like people suddenly started using it when there was no browser out 
there supporting it.

>>Given that the new date types will produce a significant improvement in 
>>UI, I want every site to be using them as soon as possible - long before 
>>WF2 browsers have 99% of the market. If they're designed in such a way 
>>that the fallback content is a much worse UI than whatever those sites 
>>are using at the moment, that won't happen and browser makers will be 
>>much slower to implement the types at-all.
> 
> Since most of the new types do not have this problem, I do not think that 
> you need worry.

    I do. I can easily see a scenario where some of the WF2 stuff is 
added, but the date/time stuff is left out. For instance, why does one 
need <input type="date"> when one can do this:

| <label for="date1">Date: </label>
| <input type="text" id="date1" name="date1" pattern="[date format]">
| Format: [date format]

    The date gets formatted in WF2 clients in the same way is it's 
specified in the formatting hint, and it gets submitted to the server 
that way, so the webmaster doesn't have to change anything on the 
server. So I'd take a good, hard look at how you support legacy fallback...


From gkilwein at fbsdata.com  Tue Feb  8 06:36:29 2005
From: gkilwein at fbsdata.com (Greg Kilwein)
Date: Tue, 08 Feb 2005 08:36:29 -0600
Subject: [whatwg] Re: several messages
In-Reply-To: <42082791.6070104@earthlink.net>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>	<4207F3CC.9070508@fbsdata.com>
	<42082791.6070104@earthlink.net>
Message-ID: <4208CE6D.6020804@fbsdata.com>

Matthew Raymond wrote:

> Greg Kilwein wrote:
>
>> I'll add one more problem - the author cannot easily test the 
>> fallback content in the UA of <idate/> if the author doesn't have a 
>> legacy UA available.  If the author can't easily test it, the odds of 
>> the fallback content being missing or broken are higher.
>
>    Who are you kidding? To test <idate>, you just comment out the 
> "<idate>" tags:
>
> | <!-- <idate> -->
> |  <input name="date1">
> | <!-- </idate> -->
>
>    Or you write the fallback and test it before adding the 
> date-related WF2 markup.

The key is _easily_ test the fallback content.  For those authors who 
just don't care, there's no default fallback content, which I think is 
worse than none at all.  Besides, if the upper-end authors really want 
to replace <input type="date"> with three select boxes in legacy UAs, it 
can be done with some script without imposing some sort of 
comment/uncomment testing method on lower-end authors who just don't 
know or care.

Greg



From mattraymond at earthlink.net  Tue Feb  8 07:12:17 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 08 Feb 2005 10:12:17 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <4208CE6D.6020804@fbsdata.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>	<4207F3CC.9070508@fbsdata.com>
	<42082791.6070104@earthlink.net> <4208CE6D.6020804@fbsdata.com>
Message-ID: <4208D6D1.4070009@earthlink.net>

Greg Kilwein wrote:
> The key is _easily_ test the fallback content.  For those authors who 
> just don't care, there's no default fallback content, which I think is 
> worse than none at all.  Besides, if the upper-end authors really want 
> to replace <input type="date"> with three select boxes in legacy UAs, it 
> can be done with some script without imposing some sort of 
> comment/uncomment testing method on lower-end authors who just don't 
> know or care.

    The easy way to test pages for legacy fallback is to use a legacy 
UA, but you were specifically asking how someone would test markup in a 
_WF2_ user agent. In the end, the only way to know for sure that 
something degrades gracefully on a legacy browser is to check it with a 
legacy browser. For instance, you would not be able to test if your 
client or server-side validation of the date works on a legacy browser 
by testing it in a WF2 browser unless the WF2 browser had a feature for 
turning WF2 off, in which case <idate> would benefit in a similar manner.


From ian at hixie.ch  Wed Feb  9 07:21:41 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Feb 2005 15:21:41 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <opsluxphesofh7fl@crissov>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net> <opsluxphesofh7fl@crissov>
Message-ID: <Pine.LNX.4.61.0502091520140.1757@dhalsim.dreamhost.com>

On Tue, 8 Feb 2005, [iso-8859-1] Christoph P?per wrote:
>
> A simple 'text' 'input' has the advantage that it generates only one 
> parameter to be handled by the server (and an optional client-side 
> validation script), just like the 'date' 'input' does. The most basic 
> handling would be to reject anything that is not an ISO?8601 conformant 
> string (in the valid time frame), requiring the user to resubmit. From 
> there on you can get as complex guessing as you want. Unambiguous, valid 
> inputs are (silently) accepted, others rejected. Rejection on ambiguity 
> should include showing the user the guessed likeliest value in an 
> unambiguous format, so he hopefully just has to accept without further 
> changing. The lesser advanced the guess script, the more important it is 
> to inform the user of the expected input style.
> 
> From the point of usability I wouldn't want '<input type="date">' to 
> fall back to anything but '<input type="text">'. Neither from the point 
> of marking-up and styling. In this case the programmer has to swallow 
> the bitter pill, IMVHO. After all it's a recurring problem for which he 
> has to find or write a solution only once (at least in theory).

I agree.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From mattraymond at earthlink.net  Wed Feb  9 08:06:21 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 09 Feb 2005 11:06:21 -0500
Subject: [whatwg] [WF2] The <icomplex> element
Message-ID: <420A34FD.5040705@earthlink.net>

INTRO:

    Ian had some interesting points about element counts, dynamic issues 
involving inheritance and the potential for empty legacy content in 
previous messages regarding <idate>. While I don't entirely agree with 
him, I feel it's better to change the concept to address some of his 
concerns than trying to convert him to my own opinions. Thus, I'm making 
the following changes to the <idate> concept:

1) I'm introducing a |type| attribute and combining all the various 
chronological elements (<idate>, <idatetime>, <itime>, <iweek>, et 
cetera) into a single element <icomplex>.

2) The new <icomplex> element will have all non-depreciated <input> 
attributes.

3) The <icomplex> element will now only be used in cases involving 
complex fallback (that is, situations where <input> can't effectively 
provide the desired fallback).

4) Inheritance is dropped.

5) Opening and closing tags should be required in both HTML and XHTML.

6) Suppression of Javascript within <icomplex> is not required. Controls 
within <icomplex>, however, will not be successful for submission.

    These changes reduce complexity for use as well as implementation, 
help prevent inappropriate use and provide a more general method of 
providing fallback that can be extended to non-chronological inputs and 
input types that don't even exist yet.

OUTDATED CONCEPTS:

    Note that all of the following concepts are outdated:

  * <format>
  * <date> (and it's siblings, AS A CONTROL)
  * <idate> (and it's siblings)

EXAMPLES:

    Here's a simple example for the three <select> scenario:

| <icomplex type="date" id="d1" name="d1" value="2005-02-09">
|  <select name="d1_day"><!-- Options --></select> /
|  <select name="d1_month"><!-- Options --></select> /
|  <select name="d1_year"><!-- Options --></select>
| </icomplex>

    Here's an example for users of jscalendar:

| <icomplex type="date" id="sel1_WF2" name="date1">
|  <input type="text" id="sel1" name="date1" size="30">
|  <input type="reset" value=" ... "
|   onclick="return showCalendar('sel1', '%Y-%m-%d');" >
|  YYYY-MM-DD
| </icomplex>

ISSUES RESOLVED:

    Ian brought up some issues in a previous message regarding <idate>. 
Let's take a look.

 >  * More complicated to implement:
 >     - more elements involved
 >     - interactions of elements and attributes that require
 >       dynamic updates (very bug prone)

    The number of elements has been reduced to one, and that element has 
a nearly identical list of attributes to <input>. The lack of 
inheritance prevents problems with dynamic updates. So unless you're 
really against adding a single additional element to HTML, this section 
is no longer an issue.

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

    As previously stated, there is now only one additional element, and 
it's only used when complex legacy support is needed.

    If scripting using the form .elements collection is a problem for 
webmasters, they have the option of falling back to <input>, but since 
webmasters can either use getElementById or cycle through the elements 
until an |id| is found (for DOM1 browsers), this largely looks like a 
non-issue. Suggestions for improvement are welcome, of course.

 >  * Fallback needs author involvement
 >     - easiest to simply not support legacy
 >     - server typically needs to handle different names for controls,
 >       not just different format

    Since <icomplex> is a compliment to <input>, and has the same 
attributes but requires a closing tag, <input> will still be preferred 
by webmasters that don't want to include fallback. The server handling 
is a red herring, because <input> doesn't address the problem of 
fallback to multiple controls.

    So it looks like nearly all of his concerns have been addressed. Let 
me know if there are any other concerns to address.


From hallvors at online.no  Thu Feb 10 03:35:32 2005
From: hallvors at online.no (Hallvord Reiar Michaelsen Steen)
Date: Thu, 10 Feb 2005 12:35:32 +0100
Subject: [whatwg] [WF2] The <icomplex> element
In-Reply-To: <420A34FD.5040705@earthlink.net>
Message-ID: <420B5514.9827.7CF51ED@localhost>

On 9 Feb 2005 at 11:06, Matthew Raymond wrote:
> it's only used when complex legacy support is needed.
<X>
> <input> will still be preferred by webmasters that don't want to 
> include fallback. 

You can neither dictate nor predict such things. 
Authors are going to use it however they like (not to mention that 
their WYSIWYG editor will do things that they are not even aware of) 
;)

>  Let me know if there are any other concerns to address. 

Not the prettiest tag name :)

The .elements problem is not solved, since the indexes will still be 
different depending on what type of UA you deal with. It is more 
common to access elements by name but in this scenario we are dealing 
with legacy content possibly including older scripts that do not use 
getElementById et al.

A DOM scripting issue if you want to add a new HTML element: what do 
browsers do if you do document.createElement('icomplex') ? Will any 
browsers choke and throw errors? If an element is created, can the 
script reliably detect if the created element is the element type 
they expect?
-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/

Note: mail to hallvors at online.no will still be read but you may want to start using 
hallvord at hallvord.com instead

-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/

Note: mail to hallvors at online.no will still be read but you may want to start using 
hallvord at hallvord.com instead



From mattraymond at earthlink.net  Thu Feb 10 06:47:33 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 10 Feb 2005 09:47:33 -0500
Subject: [whatwg] [WF2] The <icomplex> element
In-Reply-To: <420B5514.9827.7CF51ED@localhost>
References: <420B5514.9827.7CF51ED@localhost>
Message-ID: <420B7405.6080301@earthlink.net>

Hallvord Reiar Michaelsen Steen wrote:
> On 9 Feb 2005 at 11:06, Matthew Raymond wrote:
>>it's only used when complex legacy support is needed.
> 
> <X>

"<X>"???

    I was referring to how it would be presented in the spec. I don't 
expect we can enforce a specific use in any way. However, I don't think 
such enforcement is needed. See below.

>><input> will still be preferred by webmasters that don't want to 
>>include fallback. 
> 
> You can neither dictate nor predict such things. 
> Authors are going to use it however they like (not to mention that 
> their WYSIWYG editor will do things that they are not even aware of) 
> ;)

    True, but if you were used to using <input>, would you use a tag 
with  then same attributes but a longer name and a required closing tag 
to do the exact same thing? Especially if the specs say to use <input> 
in simple cases? Take a look:

| <input type="date" name="date1" value="2005-02-10">

| <icomplex type="date" name="date1" value="2005-02-10"></icomplex>

    So it's not a certainty, but it's pretty close. As for the editor, 
they can simply use <input> by default and give a warning before saving 
if <icomplex> has no contents. (Can we require contents??? My first 
guess would be no, but maybe someone knows more than I.)

>> Let me know if there are any other concerns to address. 
> 
> Not the prettiest tag name :)

    Other suggestions are welcome. Some possibilities:

  * <inputcomplex>
  * <inputc>
  * <cinput>
  * <ci>
  * <input1>
  * <ic>
  * <ilegacy>

> The .elements problem is not solved, since the indexes will still be 
> different depending on what type of UA you deal with. It is more 
> common to access elements by name but in this scenario we are dealing 
> with legacy content possibly including older scripts that do not use 
> getElementById et al.

    Well, one solution would be to provide an optional attribute that 
can exclude <icomplex> from the .elements collection:

| <icomplex domcloak="true" name="hideMe"><!-- Contents. --></icomplex>

    I'm not sure I like that solution though, and I'm almost certain Ian 
won't like it. Another solution would be that <icomplex> would never be 
included in the .elements collection at all. That seems like a better 
solution, and since the WF2 DOM extensions depend on DOM2 and 
getElementById is well supported. So there's no issues of being able to 
get a specific <icomplex> element on WF2 UAs.

> A DOM scripting issue if you want to add a new HTML element: what do 
> browsers do if you do document.createElement('icomplex')?  Will any
 > browsers choke and throw errors?

    This isn't actually a problem specific to <icomplex>. Elements such 
as <datalist>, <output> and any other new elements we introduce could 
have this problem. If this can't be addressed, it may be a serious 
problem for any WHATWG specification.

> If an element is created, can the script reliably detect if the
 > created element is the element type they expect?

    /me shrugs and offers this:

| if (myIcomplexElement.type) // Does the object has a .type property?

    Yeah, assuming an unrecognized element doesn't automatically have 
properties that aren't on most elements, I'd say that's pretty safe. 
Remember, though that IANAJSG. (Guess the acronym!) ;)

    Is it just me, or are there holes in the Javascript and DOM specs 
that you can drive a truck through?


From michael at quuxo.com  Thu Feb 10 19:34:26 2005
From: michael at quuxo.com (Michael Gratton)
Date: Fri, 11 Feb 2005 14:04:26 +1030
Subject: [whatwg] default action/button for forms
Message-ID: <1108092866.4753.40.camel@wintermute>

Hi guys,

After looking through the archives, surprised to find that there has
been no mention of some way to specify the default button/action for a
form.

Most browsers behave as the Web Forms 2.0 spec specifies in section 2.3,
"Changes to existing controls". That is, the first button is used as the
default. But this is pretty annoying behaviour. In a large form, it is
common to have several submit buttons and is is just as likely as it is
not that the first button should be the default.

As a result, web application developers generally resort to one of two
kluges: adding a hidden submit button to the form or using JavaScript to
trap key events or the form submission event.

For me is is also a problem because <troll>like today's common usable
desktop environments (Mac OS, GNOME, etc),</troll> I design forms so
that the default button is to the right of any additional action
buttons.

It would be great to see some way of specifying the default button for
the form in Web Forms 2.0, or some later revision. One way of
implementing this (and the way I would do it if I was fixing the problem
using JavaScript) would be to add a "default-action" attribute or
similar to the form element. This would be an IDREF that specifies the
id of the default submit button. Eg:

  <form action="bofh" method="post" default-action="lart">
    <input type="text" name="who">
    <input type="submit" id="ignore" name="action" value="Ignore">
    <input type="submit" id="lart" name="action" value="LART">
  </form>

What do you think?

/Mike

-- 
Michael Gratton, Software Architect.
Quuxo Software <http://web.quuxo.com/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20050211/295fe386/attachment.pgp>

From mattraymond at earthlink.net  Fri Feb 11 08:52:55 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Fri, 11 Feb 2005 11:52:55 -0500
Subject: [whatwg] default action/button for forms
In-Reply-To: <1108092866.4753.40.camel@wintermute>
References: <1108092866.4753.40.camel@wintermute>
Message-ID: <420CE2E7.6010405@earthlink.net>

Michael Gratton wrote:
> After looking through the archives, surprised to find that there has
> been no mention of some way to specify the default button/action for a
> form.
> 
> Most browsers behave as the Web Forms 2.0 spec specifies in section 2.3,
> "Changes to existing controls". That is, the first button is used as the
> default. But this is pretty annoying behaviour. In a large form, it is
> common to have several submit buttons and is is just as likely as it is
> not that the first button should be the default.

    Good point.

> As a result, web application developers generally resort to one of two
> kluges: adding a hidden submit button to the form or using JavaScript to
> trap key events or the form submission event.

    Neither ideal, since it's best to have solutions that don't CSS or 
JS support.

[Snip!]

> It would be great to see some way of specifying the default button for
> the form in Web Forms 2.0, or some later revision. One way of
> implementing this (and the way I would do it if I was fixing the problem
> using JavaScript) would be to add a "default-action" attribute or
> similar to the form element. This would be an IDREF that specifies the
> id of the default submit button. Eg:
> 
>   <form action="bofh" method="post" default-action="lart">
>     <input type="text" name="who">
>     <input type="submit" id="ignore" name="action" value="Ignore">
>     <input type="submit" id="lart" name="action" value="LART">
>   </form>
> 
> What do you think?

    I'd prefer something like this:

| <form action="http://somesite.com/prog/adduser" method="post">
|   <input type="text" name="who">
|   <input type="submit" name="action" value="Remove">
|   <input default type="submit" name="action" value="Add">
| </form>


From fora at annevankesteren.nl  Sat Feb 12 16:37:38 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 13 Feb 2005 01:37:38 +0100
Subject: [whatwg] [wf2] type="url"
Message-ID: <420EA152.7090100@annevankesteren.nl>

After thinking about it. Having |type="url"| instead of |type="uri"| or 
|type="iri"| might not be so bad.

It would also be compatible with CSS, which is the main advantage.

Furthermore, URL does not really mean anything anymore on todays web 
though it is widely understood.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From michael at quuxo.com  Sat Feb 12 17:55:15 2005
From: michael at quuxo.com (Michael Gratton)
Date: Sun, 13 Feb 2005 12:25:15 +1030
Subject: [whatwg] default action/button for forms
In-Reply-To: <420CE2E7.6010405@earthlink.net>
References: <1108092866.4753.40.camel@wintermute>
	<420CE2E7.6010405@earthlink.net>
Message-ID: <1108259715.20772.61.camel@wintermute>

On Fri, 2005-02-11 at 11:52 -0500, Matthew Raymond wrote:
> 
>     I'd prefer something like this:
> 
> | <form action="http://somesite.com/prog/adduser" method="post">
> |   <input type="text" name="who">
> |   <input type="submit" name="action" value="Remove">
> |   <input default type="submit" name="action" value="Add">
> | </form>

Sounds reasonable, it does allow some ambiguity however (what happens if
there a multiple defaults in one form?) and the default button to my
mind seems more like a property of the form then a control.

But hey, I'd be happy with either.

/Mike

-- 
Michael Gratton, Software Architect.
Quuxo Software <http://web.quuxo.com/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20050213/2764b123/attachment.pgp>

From hsivonen at iki.fi  Sun Feb 13 01:29:47 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 13 Feb 2005 11:29:47 +0200
Subject: [whatwg] [wf2] type="url"
In-Reply-To: <420EA152.7090100@annevankesteren.nl>
References: <420EA152.7090100@annevankesteren.nl>
Message-ID: <91ba2235e5546f4383f2b14e550e3c10@iki.fi>

On Feb 13, 2005, at 02:37, Anne van Kesteren wrote:

> Furthermore, URL does not really mean anything anymore on todays web

IMO, that stance is both impractical and revisionist.

Quoting RFC 3986, section 1.1.3.:
"A URI can be further classified as a locator, a name, or both.  The 
term 'Uniform Resource Locator' (URL) refers to the subset of URIs 
that, in addition to identifying a resource, provide a means of 
locating the resource by describing its primary access mechanism (e.g., 
its network 'location')."

The practical matter is that the URL subset of URIs is the subset that 
actually works. I think it is rather silly to talk about URIs in 
contexts where everyone knows that the URI needs to be dereferencable 
and only URLs (or only HTTP URLs) actually work.

As for identifiers, character to character comparison works much better 
for identifier equality comparison that full-blown scheme-aware URI 
comparison.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/



From hsivonen at iki.fi  Sun Feb 13 02:18:38 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 13 Feb 2005 12:18:38 +0200
Subject: [whatwg] default action/button for forms
In-Reply-To: <420CE2E7.6010405@earthlink.net>
References: <1108092866.4753.40.camel@wintermute>
	<420CE2E7.6010405@earthlink.net>
Message-ID: <5710727973deb3ed87041d93285ae979@iki.fi>

On Feb 11, 2005, at 18:52, Matthew Raymond wrote:

> <input default type="submit" name="action" value="Add">

As a practical matter, it would be better to avoid new minimized 
attributes in order to avoid changes to tag soup processors that handle 
a closed list of attributes as special minimized cases.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/



From fora at annevankesteren.nl  Sun Feb 13 02:26:08 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 13 Feb 2005 11:26:08 +0100
Subject: [whatwg] [wf2] type="url"
In-Reply-To: <91ba2235e5546f4383f2b14e550e3c10@iki.fi>
References: <420EA152.7090100@annevankesteren.nl>
	<91ba2235e5546f4383f2b14e550e3c10@iki.fi>
Message-ID: <420F2B40.9030406@annevankesteren.nl>

Henri Sivonen wrote:
> On Feb 13, 2005, at 02:37, Anne van Kesteren wrote:
> 
>> Furthermore, URL does not really mean anything anymore on todays web
>
> IMO, that stance is both impractical and revisionist.
> 
> Quoting RFC 3986, section 1.1.3.:
> "A URI can be further classified as a locator, a name, or both.  The 
> term 'Uniform Resource Locator' (URL) refers to the subset of URIs that, 
> in addition to identifying a resource, provide a means of locating the 
> resource by describing its primary access mechanism (e.g., its network 
> 'location')."
> 
> The practical matter is that the URL subset of URIs is the subset that 
> actually works. I think it is rather silly to talk about URIs in 
> contexts where everyone knows that the URI needs to be dereferencable 
> and only URLs (or only HTTP URLs) actually work.

IIRC URLs do not include #foo, which is quite a practical thing and 
heavily used on todays web.

Agreed that I should have dropped that last sentence.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From mattraymond at earthlink.net  Sun Feb 13 04:14:18 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Sun, 13 Feb 2005 07:14:18 -0500
Subject: [whatwg] default action/button for forms
In-Reply-To: <1108259715.20772.61.camel@wintermute>
References: <1108092866.4753.40.camel@wintermute>	<420CE2E7.6010405@earthlink.net>
	<1108259715.20772.61.camel@wintermute>
Message-ID: <420F449A.1080903@earthlink.net>

Michael Gratton wrote:
> On Fri, 2005-02-11 at 11:52 -0500, Matthew Raymond wrote:
>>    I'd prefer something like this:
>>
>>| <form action="http://somesite.com/prog/adduser" method="post">
>>|   <input type="text" name="who">
>>|   <input type="submit" name="action" value="Remove">
>>|   <input default type="submit" name="action" value="Add">
>>| </form>
> 
> Sounds reasonable, it does allow some ambiguity however (what happens if
> there a multiple defaults in one form?)

    I just assumed we'd handle it the same way as |autofocus|:

| Authors should avoid setting the autofocus attribute on multiple
| enabled elements in a document. If multiple elements with the
| autofocus attribute set are  inserted into a document, each one will
| be processed as described above, as they are inserted. This means that
| during document load, for example, the last focusable form control in
| document order with the attribute set will end up with the focus.

    So the last button of the form set as the default would be default.

 > and the default button to my
> mind seems more like a property of the form then a control.

    I disagree. In Visual Basic, for instance, the value is set on the 
button, not the form. (Although, in VB, the environment automatically 
sets the value of the |default| property on all other buttons to false. 
I suppose HTML editors could follow suit.) Furthermore, HTML has a 
history of putting mutually exclusive values on items rather than the 
container of the items (see <option selected> and <input type="radio" 
checked>).

    Also, in WA1, the <command> element has an attribute of the same 
name that does roughly the same thing.

> But hey, I'd be happy with either.

    Good to know. :)

Henri Sivonen wrote:
 > On Feb 11, 2005, at 18:52, Matthew Raymond wrote:
 >>| <input default type="submit" name="action" value="Add">
 >
 > As a practical matter, it would be better to avoid new minimized
 > attributes in order to avoid changes to tag soup processors that
 > handle a closed list of attributes as special minimized cases.

    Yeah, WA1 does the same thing with <command>, so we can just fall in 
line:

| <input default="default" type="submit" name="action" value="Add">

    Hmm. On a side note: What was our motivation for making people put 
the name of the property as the value in these cases? Why not just 
"true"? Not that important, though...


From mattraymond at earthlink.net  Sun Feb 13 11:26:54 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Sun, 13 Feb 2005 14:26:54 -0500
Subject: [whatwg] [WF2] <icomplex> Recap
Message-ID: <420FA9FE.6030709@earthlink.net>

    Here's a quick recap of <icomplex>...


QUICK DESCRIPTION:

    It's just like <input>, with three exceptions:

  * It doesn't have the depreciated attributes.
  * It should contain alternative contents for legacy support.
  * It requires a closing tag ("</icomplex>").


EXAMPLES:

     Here's a simple example for the three <select> scenario:

| <icomplex type="date" id="d1" name="d1" value="2005-02-09">
|  <select name="d1_day"><!-- Options --></select> /
|  <select name="d1_month"><!-- Options --></select> /
|  <select name="d1_year"><!-- Options --></select>
| </icomplex>

     Here's an example for users of jscalendar:

| <icomplex type="date" id="sel1_WF2" name="date1">
|  <input type="text" id="sel1" name="date1" size="30">
|  <input type="reset" value=" ... "
|   onclick="return showCalendar('sel1', '%Y-%m-%d');" >
|  YYYY-MM-DD
| </icomplex>


PROS:

1) The <icomplex> element can allow for a far greater range of legacy 
fallback than <input>.

2) Because the |type| is defined in an attribute, <icomplex> can be used 
for input types in later specifications, or for vendor-specific input types.

3) The element is designed in both semantics and structure to encourages 
the use of <input> in simple cases where legacy fallback needs are minimal.

4) The element is designed only to prevent the presentation of its child 
elements. It does not require user agents to delete contents from the 
DOM or suppress Javascript execution.

5) Because it has the same attributes as <input>, there's nothing new to 
learn except the inclusion of fallback content.

CONS:

1) The size of a form's elements collection in Javascript may differ 
between user agents.

2) There may be legacy Javascript issues that cause script failure when 
generating unrecognized elements.

3) When creating an <icomplex> element, you should be able to test for 
the correct element type by checking to see if it has a .type property, 
but I can't be 100% certain.

4) Some unneeded Javascript overhead on WF2 clients.

5) CSS styling for <icomplex> can't be done directly because user agents 
that support unrecognized elements may use the styling instead of 
ignoring the <icomplex> as intended.

6) The name sucks?


SOLUTIONS FOR CONS:

1) We could just define <icomplex> as never showing up in the .elements 
collection, or provide an attribute to that effect. Neither are ideal, 
but if most of the WF2 content will be written from scratch, then 
.elements is only an issue for those trying to support browsers without 
support for getElementById.

2) This is a general issue affecting all new elements we introduce.

3) May not be an issue, but I'd like to hear from an expert.

4) Ian seems to feel this is a non-issue, so I won't argue with him.

5) Simply style <icomplex type="something"> as if it were <input 
type="something"> in WF2 user agents. Therefore, on a system that uses 
the following CSS...

| input[type=date] { /* Some styling here. */ }

...The above styling would apply to both <input type="date"> and 
<icomplex type="date">.

6) Someone should suggest a new name if they don't like the current one.


From mpt at myrealbox.com  Mon Feb 14 06:02:11 2005
From: mpt at myrealbox.com (Matthew Thomas)
Date: Mon, 14 Feb 2005 16:02:11 +0200
Subject: [whatwg] [WF2] <icomplex> Recap
In-Reply-To: <420FA9FE.6030709@earthlink.net>
References: <420FA9FE.6030709@earthlink.net>
Message-ID: <ef32a544f7c9df731555bd6b1f11bed0@myrealbox.com>

On 13 Feb, 2005, at 9:26 PM, Matthew Raymond wrote:
> ...
> CONS:
> ...
> 6) The name sucks?
> ...
> 6) Someone should suggest a new name if they don't like the current 
> one.

<entry>.

-- 
Matthew Thomas
http://mpt.net.nz/



From mattraymond at earthlink.net  Mon Feb 14 07:21:23 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 14 Feb 2005 10:21:23 -0500
Subject: [whatwg] [WF2] <icomplex> Recap
In-Reply-To: <ef32a544f7c9df731555bd6b1f11bed0@myrealbox.com>
References: <420FA9FE.6030709@earthlink.net>
	<ef32a544f7c9df731555bd6b1f11bed0@myrealbox.com>
Message-ID: <4210C1F3.3010501@earthlink.net>

Matthew Thomas wrote:
> On 13 Feb, 2005, at 9:26 PM, Matthew Raymond wrote:
>>6) Someone should suggest a new name if they don't like the current 
>>one.
> 
> <entry>.

    There are a few problems with this name:

1) An <entry> element could easily be confused for being an entry in a 
weblog or similar document. It could also be confused for being some 
kind of entry point for something, like insertion of content. It just 
doesn't have a very clear meaning. In fact, if you go here...

    http://thesaurus.reference.com/search?q=input

...you'll notice that entry isn't even listed as a synonym of input.

2) There's nothing about the name "entry" that allows people to 
associate it with the <input> element (which it's modeled on).

3) There's nothing about the name "entry" that people can associate with 
legacy content.

    I could live with _<dataentry>_, though. That's very clearly an 
input element, and it has a mild phonetic association with <datalist>, 
which itself supports legacy content. (My only issue is that it's a 
little on the long side, but then to a lesser extent so is <icomplex>.)


From mattraymond at earthlink.net  Fri Feb 18 05:07:40 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Fri, 18 Feb 2005 08:07:40 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
Message-ID: <4215E89C.70303@earthlink.net>

    I've been pondering my earlier post regarding calendars in WA1:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003046.html

    While I like the idea, it seems to introduce too many tags, so I've 
simplified things a bit. The element <cattr> will now be called <vattr> 
and will be used in place of <cdatetime> and <csummary>. This may seem 
to general, but if you look at a vCalendar example, it's pretty straight 
forward. Here's a vCalendar from the hCalendar spec 
(http://developers.technorati.com/wiki/hCalendar):

| BEGIN:VCALENDAR
| PRODID:-//XYZproduct//EN
| VERSION:2.0
| BEGIN:VEVENT
| URL:http://www.web2con.com/
| DTSTART:20041005
| DTEND:20041007
| SUMMARY:Web 2.0 Conference
| END:VEVENT
| END:VCALENDAR

    Now here's how I propose we handle the same information in WA1 markup:

| <vcalendar>
|   <vattr name="prodid" value="-//XYZproduct//EN"
|   <vattr name="version" value="2.0"></vattr>
|   <vevent>
|     <vattr name="url" value="http://www.web2con.com/"></vattr>
|     <vattr name="dtstart" value="2004-10-05"></vattr>
|     <vattr name="dtend" value="2004-10-07"></vattr>
|     <vattr name="summary" value="Web 2.0 Conference"></vattr>
|   </vevent>
| </vcalendar>

    It's fairly simple, and it can be transformed directly into a 
vCalendar and back. The idea is quite similar for vCards. Let's look at 
and example from the hCard spec 
(http://developers.technorati.com/wiki/hCard):

| BEGIN:VCARD
| VERSION:3.0
| N:?elik;Tantek
| FN:Tantek ?elik
| URL:http://tantek.com
| END:VCARD

    This translates into the following markup:

| <vcard>
|   <vattr name="version" value="3.0"></vattr>
|   <vattr name="n" value="?elik;Tantek"></vattr>
|   <vattr name="fn" value="Tantek ?elik"></vattr>
|   <vattr name="url" value="http://tantek.com"></vattr>
| </vcard>

    As you can see, the markup structure mirrors the vCard structure and 
contains the same attribute names and information. It would be trivial 
to parse this information and convert it to vCard format.

    Here's the same two examples with fallback content:

| <vcalendar>
|   <table>
|     <caption>Upcoming Events</caption>
|     <tr>
|       <th>URL</th>
|       <th>Start Date</th>
|       <th>End Date</th>
|       <th>Summary</th>
|     </tr>
|     <vevent>
|     <tr>
|       <td><vattr name="url">http://www.web2con.com/</vattr></td>
|       <td><vattr name="dtstart">2004-10-05</vattr></td>
|       <td><vattr name="dtend">2004-10-07</vattr></td>
|       <td><vattr name="summary">Web 2.0 Conference</vattr></td>
|     </tr>
|     </vevent>
|   </table>
| </vcalendar>

| <vcard>
|   <vattr name="version" value="3.0"></vattr>
|   <vattr name="n" value="?elik;Tantek"></vattr>
|   <div id="tc" class="vcard">
|     <p><vattr name="fn">Tantek ?elik</vattr></p>
|     <a href="http://tantek.com">
|      <vattr name="url">http://tantek.com</vattr>
|     </a>
|     <button type="button" onclick="return addContact('tc')">
|       Add to contact list...
|     </button>
|   </div>
| </vcard>

    Comments welcome.


From ian at hixie.ch  Fri Feb 18 05:43:44 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 18 Feb 2005 13:43:44 +0000 (UTC)
Subject: [whatwg] Status Update
Message-ID: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>


If you've sent feedback on the Web Apps spec in the past few months, 
please do not think it has been ignored. I will be getting to it 
eventually. At the moment I am writing large chunks of spec in sections 1 
and 2 (recently added were the conformance requirements and the sections 
defining the <html>, <head>, <body>, <base>, etc, elements). Those 
sections are still under heavy development so while comments are welcome, 
don't be too quick to complain. ;-) However, since I'm writing these 
sections I've not had time to reply to comments.

I will be returning to Web Forms comments in due course as well, don't 
think that I'm ignoring those either!

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jim.ley at gmail.com  Fri Feb 18 07:35:05 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Fri, 18 Feb 2005 15:35:05 +0000
Subject: [whatwg] Status Update
In-Reply-To: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>
Message-ID: <851c8d31050218073550ce7f7b@mail.gmail.com>

On Fri, 18 Feb 2005 13:43:44 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 
> If you've sent feedback on the Web Apps spec in the past few months,
> please do not think it has been ignored. I will be getting to it
> eventually. 

As you're months behind by your own admission, maybe it would be a
good idea if some of the other members of the working group started
actually responding to issues too.  Why do they not, why does the
WHAT-WG have a single point of failure, are the other members not
really interested in contributing to this work?

One of the big themes coming from the Web Applications workshop in San
Jose was that the W3 was a bad place to do this work due to the
incredible slowness and a small outside organisation could do it so
much faster, indeed the original discussion on this list was for
implementations to be in the wild for Christmas, we're still a long
way from even having a spec, let alone a call for implementations.

Maybe a little more speed from the WHAT WG members (not criticising
you individually Ian, you obviously spend an awful lot of time on
this) would mean we'd actually have something worth using.

Jim.


From jim.ley at gmail.com  Fri Feb 18 08:45:41 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Fri, 18 Feb 2005 16:45:41 +0000
Subject: [whatwg] Re: [off-list] Status Update
In-Reply-To: <Pine.LNX.4.61.0502181552510.8897@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>
	<851c8d31050218073550ce7f7b@mail.gmail.com>
	<Pine.LNX.4.61.0502181552510.8897@dhalsim.dreamhost.com>
Message-ID: <851c8d3105021808456681a813@mail.gmail.com>

On Fri, 18 Feb 2005 16:00:04 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 18 Feb 2005, Jim Ley wrote:
> > As you're months behind by your own admission, maybe it would be a good
> > idea if some of the other members of the working group started actually
> > responding to issues too.
> 
> More people responding would not make things go faster. 

Of course it does, one of the continual problems on this is your
(comparitively) limited experience of script, therefore it takes
people a long time to explain to you why your "it's all solved with
script" is simply not true.  If the issue is addressed and resolved by
someone with lots of  script experience those delays simply would not
happen.

>The problem with
> many W3C committees that I'm directly familiar with is in fact that there
> are too many people responding to issues, not too few.

So you would say that 1 and just 1 person is the appropriate number
(no other member of the WHAT-WG has responded to an issue that you've
not also responded too)  I'm afraid I cannot agree with that, and
whilst I would agree that lots of people is bad the sweet spot is not
1.  What's the point of all the other members if they don't do
anything - I find it difficult to believe they're even reading the
list.

> > are the other members not really interested in contributing to this
> > work?
> 
> While it may not be in the form of heavy volume posting to the WHATWG
> list, I can assure you that the other members are doing their part.

Rather than "assure me" could you point to some concrete things that
they're doing?  They're not responding to issues, they're providing
text, they're not providing input, what exactly is their part?  Simply
trying to give this body some credibility by lending their names to
it?  If that is the case then yes, I guess they are "doing their part"
 but I'd like to see that made clear.

> I don't recall speed ever being an issue that was raised related to doing
> the WF2 and WA1 work in the WHATWG instead of the W3C. The W3C is not
> necessarily slow.

I certainly recall speed being one of the main motivators, and urls like
http://www.mozillazine.org/talkback.html?article=4816  "many feel that
formal standards bodies move too slowly " reflect that.

> The WF2 spec is basically done. Implementation work has started.

What?  before a "call for implementation", that's scary, I understood
you'd previously argued that this was a bad thing?  The spec is
clearly not finished, there are big unresolved issues (particularly
the date fallback and icomplex type proposals)

Jim.


From bkn3 at columbia.edu  Fri Feb 18 11:29:23 2005
From: bkn3 at columbia.edu (Brad Neuberg)
Date: Fri, 18 Feb 2005 11:29:23 -0800
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <4215E89C.70303@earthlink.net>
References: <4215E89C.70303@earthlink.net>
Message-ID: <6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>

Have you seen Tantek's work with hCalendar, which is basicly the iCal 
standard translated into XHTML? It's very clean and seems like a nice 
ancillary standard that could be included with WA:

http://developers.technorati.com/wiki/hCalendar

At 05:07 AM 2/18/2005, Matthew Raymond wrote:
>    I've been pondering my earlier post regarding calendars in WA1:
>
>http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003046.html
>
>    While I like the idea, it seems to introduce too many tags, so I've 
> simplified things a bit. The element <cattr> will now be called <vattr> 
> and will be used in place of <cdatetime> and <csummary>. This may seem to 
> general, but if you look at a vCalendar example, it's pretty straight 
> forward. Here's a vCalendar from the hCalendar spec 
> (http://developers.technorati.com/wiki/hCalendar):
>
>| BEGIN:VCALENDAR
>| PRODID:-//XYZproduct//EN
>| VERSION:2.0
>| BEGIN:VEVENT
>| URL:http://www.web2con.com/
>| DTSTART:20041005
>| DTEND:20041007
>| SUMMARY:Web 2.0 Conference
>| END:VEVENT
>| END:VCALENDAR
>
>    Now here's how I propose we handle the same information in WA1 markup:
>
>| <vcalendar>
>|   <vattr name="prodid" value="-//XYZproduct//EN"
>|   <vattr name="version" value="2.0"></vattr>
>|   <vevent>
>|     <vattr name="url" value="http://www.web2con.com/"></vattr>
>|     <vattr name="dtstart" value="2004-10-05"></vattr>
>|     <vattr name="dtend" value="2004-10-07"></vattr>
>|     <vattr name="summary" value="Web 2.0 Conference"></vattr>
>|   </vevent>
>| </vcalendar>
>
>    It's fairly simple, and it can be transformed directly into a 
> vCalendar and back. The idea is quite similar for vCards. Let's look at 
> and example from the hCard spec (http://developers.technorati.com/wiki/hCard):
>
>| BEGIN:VCARD
>| VERSION:3.0
>| N:?elik;Tantek
>| FN:Tantek ?elik
>| URL:http://tantek.com
>| END:VCARD
>
>    This translates into the following markup:
>
>| <vcard>
>|   <vattr name="version" value="3.0"></vattr>
>|   <vattr name="n" value="?elik;Tantek"></vattr>
>|   <vattr name="fn" value="Tantek ?elik"></vattr>
>|   <vattr name="url" value="http://tantek.com"></vattr>
>| </vcard>
>
>    As you can see, the markup structure mirrors the vCard structure and 
> contains the same attribute names and information. It would be trivial to 
> parse this information and convert it to vCard format.
>
>    Here's the same two examples with fallback content:
>
>| <vcalendar>
>|   <table>
>|     <caption>Upcoming Events</caption>
>|     <tr>
>|       <th>URL</th>
>|       <th>Start Date</th>
>|       <th>End Date</th>
>|       <th>Summary</th>
>|     </tr>
>|     <vevent>
>|     <tr>
>|       <td><vattr name="url">http://www.web2con.com/</vattr></td>
>|       <td><vattr name="dtstart">2004-10-05</vattr></td>
>|       <td><vattr name="dtend">2004-10-07</vattr></td>
>|       <td><vattr name="summary">Web 2.0 Conference</vattr></td>
>|     </tr>
>|     </vevent>
>|   </table>
>| </vcalendar>
>
>| <vcard>
>|   <vattr name="version" value="3.0"></vattr>
>|   <vattr name="n" value="?elik;Tantek"></vattr>
>|   <div id="tc" class="vcard">
>|     <p><vattr name="fn">Tantek ?elik</vattr></p>
>|     <a href="http://tantek.com">
>|      <vattr name="url">http://tantek.com</vattr>
>|     </a>
>|     <button type="button" onclick="return addContact('tc')">
>|       Add to contact list...
>|     </button>
>|   </div>
>| </vcard>
>
>    Comments welcome.

Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html. 



From mattraymond at earthlink.net  Mon Feb 21 04:58:11 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 21 Feb 2005 07:58:11 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
Message-ID: <4219DAE3.8080604@earthlink.net>

Brad Neuberg wrote:
> Have you seen Tantek's work with hCalendar, which is basicly the iCal 
> standard translated into XHTML? It's very clean and seems like a nice 
> ancillary standard that could be included with WA:
> 
> http://developers.technorati.com/wiki/hCalendar
[Snip!]
> At 05:07 AM 2/18/2005, Matthew Raymond wrote:
[Snip!]
>>(http://developers.technorati.com/wiki/hCalendar):

    So, as you can see above, the answer to that question would be yes.

    There are several problems with hCalendar (and in turn, vCard):

1) There is no way for some reading the markup to tell if a class name
is the name of an attribute or simply the name of a class used for styling.

2) As a result of the above, user agents would not be able to reliably
allow users to access extension properties such as
"x-mozilla-alarm-default-length" (which is an actual extension used in
Sunbird).

3) Other than Ian's <calendar> addition, there's no actual semantic
markup for calendars or business cards.

4) What happens if I use a class inside <calendar> when I don't want the
element I use it on to be a property of the calendar? What happens if
the class is used both inside and outside <calendar>?

5) What do I do if I want to add styling to a group of calendar events,
especially if the calendar contains dynamic content? Styling a long list
of IDs through the use of dynamically generated CSS doesn't sound all
that appealing.

6) What do you do if you don't want the calendar or card to show up on
legacy user agents, or what if you don't want specific properties to
show up? hCalendar and hCard require you to use CSS to hide markup in
legacy user agents.

7) The use of <abbr> for dates is incorrect. "August 5th, 2004" is not
the abbreviation of 2004-09-05. In fact, the opposite is closer to the
truth. So, what would be a semantically correct method for storing
separate values for legacy UAs and WA1 UAs?

8) If we're going to use title for separation of content for differing
user agents, what happens when we want tooltips on certain items for
legacy user agents? For that matter, how do we use those tooltips on WA1
user agents?

9) What element is most appropriate in specific circumstances? Would the
use of <acronym> for DTSTART be just as good as <abbr>??? What happens
if a browser doesn't support either <acronym> or <abbr> with respect to
calendars?

    So, effectively, for hCard and hCalendar, you have to create a
complex set of rules for all possible uses of legacy markup within
<calendar> which can easily be implemented incorrectly, and even then
you still have styling and tooltip issues that are unresolved. By
contrast, my system had a clear separation between legacy markup and WA1
markup. My system also works on a simple set of rules that don't change
or overload any existing elements, and it does so without adding
complicated markup. Compare the following:

| <calendar>
|  <span class="vevent">
|   <a class="url" href="http://www.web2con.com/">
|    <abbr class="dtstart" title="20041005">October 5</abbr>-
|    <abbr class="dtend" title="20041007">7</abbr>
|    <span class="summary">Web 2.0 Conference</span>
|   </a>
|  </span>
| </calendar>

| <vcalendar>
|  <vevent>
|   <a href="http://www.web2con.com/">
|    <vattr name="url" value="http://www.web2con.com/"></vattr>
|    <vattr name="dtstart" value="20041005">October 5</vattr>-
|    <vattr name="dtend" value="20041007">7</vattr>
|    <vattr name="summary">Web 2.0 Conference</vattr>
|   </a>
|  </vevent>
| </vcalendar>

    They're very similar, but only the first overloads |class| and
|title|. Only the hCalendar example uses multiple elements to define
calendar properties. Granted, you save an element, but at the cost of
diluting the meaning of <a>.

    Not that I don't see the advantage and flexibility of the
hCard/hCalendar system. You can use multiple class names to declare
redundant attributes in a single element. You can also nest
calendar/card attributes. (Then again, you could theoretically do the
same with <vattr>.)

    The problem is that, for all the creative ways you can use
hCalendar/hCard, it's more complicated for webmasters to read and
understand and more complicated for developers to implement. 
Furthermore, I dislike the entire system of using class names as markup. 
Class names should be reserved for user-defined semantics.


From ian at hixie.ch  Mon Feb 21 11:53:12 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 21 Feb 2005 19:53:12 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <4219DAE3.8080604@earthlink.net>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>

On Mon, 21 Feb 2005, Matthew Raymond wrote:
> 
> There are several problems with hCalendar (and in turn, vCard): [...]

Tantek has asked me to point people to:

  http://developers.technorati.com/wiki/hCalendarFAQ
  http://developers.technorati.com/wiki/hCalendarIssues

Please discuss hCalendar and hCard issues with Tantek; I'm not planning on 
touching the relevant sections of WA1 until Tantek's drafts are much more 
stable. Unless there are good reasons not to do so, I plan to just take 
his specs wholesale (either by reference or by inclusion), when they are 
ready. There's not really any point in several different versions of these 
things being done at the same time!

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From mw at mattwright.com  Mon Feb 21 13:47:24 2005
From: mw at mattwright.com (Matt Wright)
Date: Mon, 21 Feb 2005 14:47:24 -0700
Subject: [whatwg] required attribute for checkbox/select
Message-ID: <000001c5185e$ee430810$6a00a8c0@msa>

Sorry if these items have already been discussed on the mailing list, but I
searched the archives and didn't see anything. I had a couple suggestions
for the required attribute (section 2.7) in Web Forms 2.0.

1) For checkboxes, wouldn't it would make more sense from a web applications
standpoint if this applied to a checkbox group like radio buttons currently
does?

	OLD: "For checkboxes, the required attribute shall only be satisfied
when the checkbox is checked."

	NEW: "For checkboxes, the required attribute shall only be satisfied
when one or more of the checkboxes in that checkbox group is checked."

If authors want the behavior currently specified in the draft, they simply
name that checkbox something different from all other fields in the form.

2) Why can't the required attribute apply to a select field?  It is common
for application designers to want to force the user to manually select an
option.  They will do something like <option value="">Please select a valid
option</option>. You could easily word the document to say that:

	NEW: "For select, the required attribute shall only be satisfied
when a non-empty option value is selected."

Or, you may not even need to re-word the document, but just remove select
from the list of unsupported controls, since the final catch-all of this
section explains "Any non-empty value satisfies the required condition,
including a simple whitespace character."

Thanks,

Matt Wright



From thingol at mail.ru  Mon Feb 21 14:37:15 2005
From: thingol at mail.ru (Roman Ivanov)
Date: Tue, 22 Feb 2005 01:37:15 +0300
Subject: [whatwg] Web Forms 2.0
Message-ID: <421A629B.2040409@mail.ru>

Hello.

I think that web developers really need a standard on working with 
selection in textarea and input type=text fields.

Now there's no standard that describes how to get starting point of 
selection, ending point of selection, and cursor position.
Also there's no standard that describes how to set selection and cursor 
position.

Now it can be done in Mozilla and MSIE but neither in Opera nor in Safari.

We'll make a great step into compatibility if Web Forms will contain 
such standard.

Thank you very much.

-- 
Roman Ivanov


From olav at olav.dk  Tue Feb 22 02:45:24 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 22 Feb 2005 11:45:24 +0100
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421A629B.2040409@mail.ru>
References: <421A629B.2040409@mail.ru>
Message-ID: <421B0D44.9040904@olav.dk>

Roman Ivanov wrote:
> I think that web developers really need a standard on working with 
> selection in textarea and input type=text fields.

Yes, that would be nice.
It has been discussed before:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001996.html

I think the best way would be if the value attribute of an input field 
could be treated as if it were text content of the element. Then the DOM 
Range spec (perhaps with some extensions) would cover how selections are 
treated.

Also, this would make editing input and textarea elements consistent 
with contentEditable, where the contents of an element is made directly 
editable.

Olav Junker Kj?r


From mattraymond at earthlink.net  Tue Feb 22 05:59:28 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 22 Feb 2005 08:59:28 -0500
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421B0D44.9040904@olav.dk>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
Message-ID: <421B3AC0.2020805@earthlink.net>

Olav Junker Kj?r wrote:
> Roman Ivanov wrote:
>>I think that web developers really need a standard on working with 
>>selection in textarea and input type=text fields.
> 
> Yes, that would be nice.
> It has been discussed before:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001996.html

    Let's take a look:

| function getcaretpos(inp)
| {
|     // for mozilla
|     if(inp.selectionEnd)
|       return inp.selectionEnd;
|
|     // for IE
|     if(inp.createTextRange)
|     {
|       var docrange = document.selection.createRange();
|       var inprange = inp.createTextRange();
|       inprange.setEndPoint('EndToStart', docrange);
|       return inprange.text.length;
|     }
|
|     return inp.value.length; // other browsers don't provide a method 
|                              // that I know of
| }

    Man, what were the IE developers smoking when they came up with 
that?  The Mozilla method is waaaaaaaaaaaay easier.

> I think the best way would be if the value attribute of an input field 
> could be treated as if it were text content of the element. Then the DOM 
> Range spec (perhaps with some extensions) would cover how selections are 
> treated.

    Then you wouldn't be able to determine the original value of the 
|value| attribute, not to mention the fact that the value couldn't be 
restored to the default when you hit a reset button...

 From http://www.w3.org/TR/html4/interact/forms.html#reset-button:
| # reset buttons: When activated, a reset button resets all controls to
|   their initial values.

 From http://www.w3.org/TR/html4/interact/forms.html#initial-value:
| ...a control's "initial value" may be specified with the control
| element's value attribute.

    So, messing with the DOM wouldn't be smart.

    Another problem, though, is the fact that user agents would have to 
support Document Object Model Range. That may be assumed as a result of 
the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
that requires DOM Range.

    Another thing is that I don't like the idea of changing the behavior 
of a specific attribute based on the value of another attribute (type), 
especially when the behavior is already defined by previous specifications.

> Also, this would make editing input and textarea elements consistent 
> with contentEditable, where the contents of an element is made directly 
> editable.

    I think I know where you're going with this one. In theory, we could 
change the behavior based on the value of a new attribute like 
|contentEditable|. I'm not sure I like this solution for simple text 
selection, though. Mozilla's method is just so darn easy. Just 
.selectionStart and .selectionEnd. Easy as cake.


From olav at olav.dk  Tue Feb 22 07:26:39 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 22 Feb 2005 16:26:39 +0100
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421B3AC0.2020805@earthlink.net>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net>
Message-ID: <421B4F2F.2000100@olav.dk>

 >    So, messing with the DOM wouldn't be smart.

Yeah, it was probably a bad idea anyway. I just thought it would be 
consistent if editing always happened on element contents rather than on 
an attribute value. Especially in the case of textarea it seems a little 
unintuitive that it's the contents of the value attribute that is 
edited, rather than the element contents. But it would probably be a 
mess to try to change now.

Olav Junker Kj?r


From olav at olav.dk  Tue Feb 22 07:54:08 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 22 Feb 2005 16:54:08 +0100
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421B3AC0.2020805@earthlink.net>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net>
Message-ID: <421B55A0.6080401@olav.dk>

Matthew Raymond wrote:
>    Another problem, though, is the fact that user agents would have to 
> support Document Object Model Range. That may be assumed as a result of 
> the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
> that requires DOM Range.

I thought that selectionStart, selectionEnd and setSelectionRange() were 
part of the DOM Range, but they seem to be Mozilla-specific?

That means we have three different models for working with selections in 
input fields: the IE way, the Mozilla way, and DOM Range.

Since DOM Range is already a standard there seems to be no point in 
defining yet another standard in WHAT (except perhaps if the point was 
to standardize on the IE way for backwards compatibility?)

Anyway, I dont think selections should be part of WF2, but rather WA1 
where editing is defined, and I certainly think that the same interface 
should be used for handling editing in form controls and in elements 
with contentEditable.

Olav Junker Kj?r


From mattraymond at earthlink.net  Tue Feb 22 07:54:33 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 22 Feb 2005 10:54:33 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
Message-ID: <421B55B9.4050007@earthlink.net>

Ian Hickson wrote:
> On Mon, 21 Feb 2005, Matthew Raymond wrote:
>>There are several problems with hCalendar (and in turn, vCard): [...]
> 
> Tantek has asked me to point people to:
>   http://developers.technorati.com/wiki/hCalendarFAQ
>   http://developers.technorati.com/wiki/hCalendarIssues

    I appreciate his quick response to my email.

> Please discuss hCalendar and hCard issues with Tantek;

    Why? I have no intention of developing a Calendar/Card system for 
HTML5 outside of a public forum, and the Wikis are outside of my 
control. (Not that I question Tantek's integrity and dedication to 
standards. I just think it's a poor precedent to redirect conversations 
about WHATWG specifications to area's outside the control of WHATWG.) 
Furthermore, if you haven't noticed with some of Jim Ley's messages, 
there would be questions about fairness and tampering with the Wiki even 
if everything was on the up-and-up.

> I'm not planning on 
> touching the relevant sections of WA1 until Tantek's drafts are much more 
> stable.

    Why are we holding up the Calendar/Card portion of WA1 based 
entirely on the work of a single individual who is not a member of 
WHATWG? Granted, he's vastly more qualified than I am, but with regards 
to the WHATWG charter, he has no more authority than I do. Are we going 
to start carving up WHATWG specs and handing out pieces to specific 
individuals outside of the WHATWG for them to control?!? If someone who 
worked on Browser-X comes up with a menu system for WA1, do we just put 
everything on hold until he finishes that draft?!? Can't wait 'til Jim 
replies to this one!

> Unless there are good reasons not to do so, I plan to just take 
> his specs wholesale (either by reference or by inclusion), when they are 
> ready. There's not really any point in several different versions of these 
> things being done at the same time!

    Excuse me? There will always be several versions. It's called a 
difference of opinion. The whole point is to debate who's opinion is 
more valid until a clear, well-thought-out decision can be made. If you 
don't have that, then you have a specification developed by one, and 
WHATWG will quickly loose legitimacy.

    Might I also point out that the wikis you posted URLs to have NO 
COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
TECHNORATI. Who's to say his company won't just turn around and claim 
copyrights and patents to the whole mess?

    If you and Tantek want hCalendar and hCard as part of a WHATWG 
specification, you should post material here and allow people to comment 
on it publicly. A specific solution should not get special treatment 
regardless of who came up with it. I wouldn't mind seeing Tantek as a 
member of WHATWG personally, but freezing a portion of the spec so that 
a single individual can work on it completely outside of this working 
group is just wrong.

P.S.: I will be directing all my comments and ideas with regards to 
Calendar/Card markup to this mailing list only. I invite Tantek to do 
the same.


From ian at hixie.ch  Tue Feb 22 08:42:01 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 22 Feb 2005 16:42:01 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <421B55B9.4050007@earthlink.net>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>

On Tue, 22 Feb 2005, Matthew Raymond wrote:
>> 
>> Please discuss hCalendar and hCard issues with Tantek;
> 
> Why?

Because Tantek is the editor of those specs.


> I have no intention of developing a Calendar/Card system for HTML5 
> outside of a public forum, and the Wikis are outside of my control.

Neither do I. I don't intend to develop a Calendar/Card system for HTML5 
at all, in fact, since someone else is already working on a system for 
this. When it comes to editing that part of the WA1 spec, if there exist 
proposals that can just be imported wholesale, I would much rather do that 
than come up with yet another way of doing things.


> > I'm not planning on touching the relevant sections of WA1 until 
> > Tantek's drafts are much more stable.
> 
> Why are we holding up the Calendar/Card portion of WA1 based entirely on 
> the work of a single individual who is not a member of WHATWG?

We're not. WA1 is likely to become a huge spec. I expect to be quite busy 
doing lots of WA1 work for months. I hope that hCalendar and hCard will be 
stable once most of the rest of the WA1 spec is ready; if it is, then we 
will be able to re-use that work and save ourselves a lot of time and 
effort.


> Granted, he's vastly more qualified than I am, but with regards to the 
> WHATWG charter, he has no more authority than I do. Are we going to 
> start carving up WHATWG specs and handing out pieces to specific 
> individuals outside of the WHATWG for them to control?!? If someone who 
> worked on Browser-X comes up with a menu system for WA1, do we just put 
> everything on hold until he finishes that draft?!?

There's no "carving up" here; it's just a matter of not reinventing the 
wheel. You'll notice that the <canvas> part of WA1 is almost identical to 
the Apple implementation in early Tiger betas. This is not coincidental. 
Similarly, we're reusing much of the work that the HTML and DOM working 
groups have done over the past few years in terms of HTML and DOM errata. 
And we're using suggestions from www-html, Slashdot, and bug systems; not 
just in this mailing list.

I'm not saying that your suggestions on <calendar> aren't welcome; quite 
the opposite. However, at the moment, your suggestions would be best given 
to Tantek, since Tantek is actively working on this kind of work, and has 
studied the requirements in detail. I myself will not be working on the 
calendar and business card parts of the spec for a long time.

You are of course more than welcome to make independent proposals for 
including calendar data and "business card" data in HTML(5). If your 
proposals are technically superior to other proposals, then, once it comes 
to including a calendar mechanism in the WA1 spec, the WHATWG members 
(probably represented by me) will use your proposals.


> Might I also point out that the wikis you posted URLs to have NO 
> COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
> COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
> TECHNORATI. Who's to say his company won't just turn around and claim 
> copyrights and patents to the whole mess?

All good points to raise with Tantek.


> If you and Tantek want hCalendar and hCard as part of a WHATWG 
> specification, you should post material here and allow people to comment 
> on it publicly. A specific solution should not get special treatment 
> regardless of who came up with it. I wouldn't mind seeing Tantek as a 
> member of WHATWG personally, but freezing a portion of the spec so that 
> a single individual can work on it completely outside of this working 
> group is just wrong.

I hope this e-mail has clarified any misunderstandings; specifically, that 
comments are indeed welcome here, that Tantek's proposals aren't getting 
special treatment, and that the relevant parts of the spec aren't frozen.


> P.S.: I will be directing all my comments and ideas with regards to 
> Calendar/Card markup to this mailing list only. I invite Tantek to do 
> the same.

Tantek's proposals are also, as I understand it, aimed at areas that are 
out of scope for WHATWG, such as adding calendar metadata to existing 
HTML4 documents that can be processed by Web crawlers such as 
Technorati's. Thus I wouldn't be surprised if he did not feel it 
appropriate to do the work in this forum.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From bkn3 at columbia.edu  Tue Feb 22 14:39:47 2005
From: bkn3 at columbia.edu (Brad Neuberg)
Date: Tue, 22 Feb 2005 14:39:47 -0800
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
Message-ID: <6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>

At 11:53 AM 2/21/2005, Ian Hickson wrote:
>On Mon, 21 Feb 2005, Matthew Raymond wrote:
> >
> > There are several problems with hCalendar (and in turn, vCard): [...]
>
>Tantek has asked me to point people to:
>
>   http://developers.technorati.com/wiki/hCalendarFAQ
>   http://developers.technorati.com/wiki/hCalendarIssues
>
>Please discuss hCalendar and hCard issues with Tantek; I'm not planning on
>touching the relevant sections of WA1 until Tantek's drafts are much more
>stable. Unless there are good reasons not to do so, I plan to just take
>his specs wholesale (either by reference or by inclusion), when they are
>ready. There's not really any point in several different versions of these
>things being done at the same time!

Does this mean that you are thinking about possibily including hCalendar 
and hCard with the WA1 standard as a linked standard?

Best,
   Brad



>Cheers,
>--
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html. 



From ian at hixie.ch  Tue Feb 22 15:26:05 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 22 Feb 2005 23:26:05 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>
Message-ID: <Pine.LNX.4.61.0502222322560.19631@dhalsim.dreamhost.com>

On Tue, 22 Feb 2005, Brad Neuberg wrote:
> 
> Does this mean that you are thinking about possibily including hCalendar 
> and hCard with the WA1 standard as a linked standard?

Yeah; as the spec mentions, in fact:

   http://whatwg.org/specs/web-apps/current-work/#calendars
   http://whatwg.org/specs/web-apps/current-work/#business

But of course if other proposals come along, those will be considered as 
well.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From mattraymond at earthlink.net  Wed Feb 23 08:53:43 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 23 Feb 2005 11:53:43 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
	<Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
Message-ID: <421CB517.1030307@earthlink.net>

Ian Hickson wrote:
> On Tue, 22 Feb 2005, Matthew Raymond wrote:
>>>Please discuss hCalendar and hCard issues with Tantek;
>>
>>Why?
> 
> Because Tantek is the editor of those specs.

     I fail to see how I could have a reasonable debate over whether
hCalendar/hCard should be included in a WHATWG spec without actually
holding such a discussion on the mailing list. Remember, I'm proposing a 
complete alternative to hCalendar and hCard, not a modification of it. A 
debate over competing proposals is outside the scope of any one proposal.

>>I have no intention of developing a Calendar/Card system for HTML5 
>>outside of a public forum, and the Wikis are outside of my control.
> 
> Neither do I. I don't intend to develop a Calendar/Card system for HTML5 
> at all, in fact, since someone else is already working on a system for 
> this. When it comes to editing that part of the WA1 spec, if there exist 
> proposals that can just be imported wholesale, I would much rather do that 
> than come up with yet another way of doing things.

     Why use it at all? If you want others to do the development of
calender/card markup for you, why not just drop it from WA1 entirely? 
The only thing WA1 introduces on top of hCalendar/hCard are the 
<calendar> and <card> container elements. Otherwise, it's pretty much 
straight from Tantek's spec, and there are no obvious dependencies in 
other parts of the WA1 spec. (Not that I don't think including 
calendar/card markup in WA1 is a good idea...)

    Alternatively, why not just break WA1 into sections or modules (i.e. 
"Web Applications 1.0 - iCalendar Mappings"), sorta like CSS3, and 
develop each module individually? (I'll leave it up to you as to how to 
submit WA1 to standards organizations. You may want to submit all 
sections together to avoid breaking dependencies between them, or 
perhaps one at a time so that any one has a better chance of getting 
through.)

>>>I'm not planning on touching the relevant sections of WA1 until 
>>>Tantek's drafts are much more stable.
>>
>>Why are we holding up the Calendar/Card portion of WA1 based entirely on 
>>the work of a single individual who is not a member of WHATWG?
> 
> We're not. WA1 is likely to become a huge spec. I expect to be quite busy 
> doing lots of WA1 work for months. I hope that hCalendar and hCard will be 
> stable once most of the rest of the WA1 spec is ready; if it is, then we 
> will be able to re-use that work and save ourselves a lot of time and 
> effort.

    Reuse is fine so long as everyone agrees that a particular solution 
is the best or most practical. What concerns me is that I don't have a 
nice little wiki to post my ideas to or organize my thoughts with, 
whereas Tantek has his company's developer site, so I'm at a 
disadvantage. Since I and other WHATWG contributors don't have our own 
wiki, even if myself and other contributers find a better solution, you 
aren't going to put it into the WA1 spec until Tantek says he's done 
with his project.

    A good example are those two links you posted:

    http://developers.technorati.com/wiki/hCalendarFAQ
    http://developers.technorati.com/wiki/hCalendarIssues

    In both, Tantek is directly replying to a message I posted in this 
list, and he can add and change material over time to better support his 
position. Not that I think he shouldn't be able to do this. In fact, 
I've been asking for a WHATWG wiki for quite some time. Right now, 
sadly, the "XUL Alliance" does a better job of providing such resources.

    Anyone know a good free Wiki site, by the way?

    Oh, one other thing. If you're going to like to a spec, the page 
should be static, not a wiki. Otherwise, you could inadvertently allow 
anyone and their mother to change part of a WHATWG spec at will.

>>Granted, he's vastly more qualified than I am, but with regards to the 
>>WHATWG charter, he has no more authority than I do. Are we going to 
>>start carving up WHATWG specs and handing out pieces to specific 
>>individuals outside of the WHATWG for them to control?!? If someone who 
>>worked on Browser-X comes up with a menu system for WA1, do we just put 
>>everything on hold until he finishes that draft?!?
> 
> There's no "carving up" here; it's just a matter of not reinventing the 
> wheel. You'll notice that the <canvas> part of WA1 is almost identical to 
> the Apple implementation in early Tiger betas. This is not coincidental. 
> Similarly, we're reusing much of the work that the HTML and DOM working 
> groups have done over the past few years in terms of HTML and DOM errata. 
> And we're using suggestions from www-html, Slashdot, and bug systems; not 
> just in this mailing list.

    Much of the stuff you just mentioned was already implemented in a 
browser of some sort or approved by a standards organization. Tantek is 
not a standards organization, and as far as I know, hCalendar and hCard 
have not been implemented in a browser. In fact, after reading the spec 
more closely, it looks more like it's designed for automated extraction 
of information by webcrawlers rather than for actual calender controls 
and the like.

> I'm not saying that your suggestions on <calendar> aren't welcome; quite 
> the opposite. However, at the moment, your suggestions would be best given 
> to Tantek, since Tantek is actively working on this kind of work, and has 
> studied the requirements in detail. I myself will not be working on the 
> calendar and business card parts of the spec for a long time.

    Actually, you gave a specific time you'd be working on it...

    "I'm not planning on touching the relevant sections of WA1 until 
Tantek's drafts are much more stable."

    So if the above is the case, I wouldn't be able to get anything 
regarding calendars or cards considered for inclusion in the 
specification until Tantek decides to complete his hCalendar and hCard 
specs, both of which date back to mid October of last year.

> You are of course more than welcome to make independent proposals for 
> including calendar data and "business card" data in HTML(5).

    Why would anyone do that if the guy editing the target spec is going 
to ignore them for a period of time determined by a third party? It's 
one thing to be too busy to work on it at a given moment, but it's 
another thing to say that you definitely WON'T work on it until someone 
else is ready.

 > If your
> proposals are technically superior to other proposals, then, once it comes 
> to including a calendar mechanism in the WA1 spec, the WHATWG members 
> (probably represented by me) will use your proposals.

    When will that be? When you're ready, or when Tantek is? (No offense 
to Tantek. This is an argument of procedure rather than character.)

>>Might I also point out that the wikis you posted URLs to have NO 
>>COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
>>COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
>>TECHNORATI. Who's to say his company won't just turn around and claim 
>>copyrights and patents to the whole mess?
> 
> All good points to raise with Tantek.

    Not if you're linking to them through the WA1 spec. Once something 
becomes part of a WHATWG spec, these concerns become _your_ problem. 
(Although, if anything Tantek posts on the wiki becomes part of the 
WHATWG spec, there's the same issue, since he's already posted it... Has 
nothing to do with my method, though, since I use a different approach.)

>>If you and Tantek want hCalendar and hCard as part of a WHATWG 
>>specification, you should post material here and allow people to comment 
>>on it publicly. A specific solution should not get special treatment 
>>regardless of who came up with it. I wouldn't mind seeing Tantek as a 
>>member of WHATWG personally, but freezing a portion of the spec so that 
>>a single individual can work on it completely outside of this working 
>>group is just wrong.
> 
> I hope this e-mail has clarified any misunderstandings; specifically, that 
> comments are indeed welcome here, that Tantek's proposals aren't getting 
> special treatment, and that the relevant parts of the spec aren't frozen.

    If you're waiting on Tantek to finish his spec BEFORE working on the 
Calendar/Card section of WA1, that's special treatment. I doubt I could 
hold up portions of a WHATWG specification in a similar way.

>>P.S.: I will be directing all my comments and ideas with regards to 
>>Calendar/Card markup to this mailing list only. I invite Tantek to do 
>>the same.
> 
> Tantek's proposals are also, as I understand it, aimed at areas that are 
> out of scope for WHATWG, such as adding calendar metadata to existing 
> HTML4 documents that can be processed by Web crawlers such as 
> Technorati's. Thus I wouldn't be surprised if he did not feel it 
> appropriate to do the work in this forum.

    Actually, I was wondering if that was the case earlier, and looking 
at the spec now, I'm even more inclined to believe that...

    Hmm. I'm wondering if a calendar control might not be in order. 
Something like this:

| <input type="calendar" name="calendar1" data="myCalendar.ics">

    ..And for a version with fallback (just to annoy you ;) )...

| <dataentry type="calendar" name="calendar1" data="myCalendar.ics">
|  <div class="vcalendar">
|   <div class="vevent" id="events" repeat="template">
|    <p>
|     <label>URL:
|      <input type="text" class="url"
|             name="calendar1.event[events].url"
|             value="http://www.web2con.com/">
|     </label><br>
|     <label>Start Date:
|      <input type="text" class="dtstart"
|             name="calendar1.event[events].dtstart" value="2005-10-05">
|     </label><br>
|      <label>End Date:
|      <input type="text" class="dtend"
|             name="calendar1.event[events].dtend" value="2005-10-07">
|     </label><br>
|     <label>Summary:
|      <input type="text" class="summary"
|             name="calendar1.event[events].summary"
|             value="Web 2.0 Conference">
|     </label>
|    </p>
|    <p><button type="remove">Remove Event</button></p>
|   </div>
|   <p><button type="add" template="event">Add Event</button></p>
|   <p><button type="submit">Submit</button></p>
|  </div>
| </dataentry>

    The above degrades into WF2, and then into HTML 4.01, while using 
hCalendar.

    Not sure we need something as specific as a calendar control, 
though. There may not be a use case for it. Then again, if webmail 
programs become more like Outlook and combine scheduling with email, 
there may be a significant use case for this.


From olav at olav.dk  Wed Feb 23 12:24:09 2005
From: olav at olav.dk (=?ISO-8859-1?Q?Olav_Junker_Kj=E6r?=)
Date: Wed, 23 Feb 2005 21:24:09 +0100
Subject: [whatwg] WF2 section A
In-Reply-To: <Pine.LNX.4.61.0502222322560.19631@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>	<4219DAE3.8080604@earthlink.net>	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>	<6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>
	<Pine.LNX.4.61.0502222322560.19631@dhalsim.dreamhost.com>
Message-ID: <421CE669.6030209@olav.dk>

A few more editorial nits concerning WF2 section A:

- it does not say that "onformchange" and "onforminput" attributes are 
added to the "form" element, but I assume that this is the case?

- it says that the "oninvalid" attribute is added to all form controls 
except "output" elements. This implies that it is added to "button" 
elements, which I assume is a bug (since "button" elements can't be 
invalid)?

In section 7.12 it says
 > the changed event fired by the dispatchFormChanged() method...
I assume this should be "the *change* event..."


The HTMLFormElement has the dispatchFormChange() method while the 
corresponding method on form controls is called dispatchFormChanged() 
(with a "d"). However in section 7.12 the method on HTMLFormElement is 
called dispatchFormChanged() (with a "d").

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Wed Feb 23 14:18:11 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 23 Feb 2005 17:18:11 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421B55A0.6080401@olav.dk>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net> <421B55A0.6080401@olav.dk>
Message-ID: <421D0123.8050202@earthlink.net>

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
> 
>>   Another problem, though, is the fact that user agents would have to 
>>support Document Object Model Range. That may be assumed as a result of 
>>the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
>>that requires DOM Range.
> 
> I thought that selectionStart, selectionEnd and setSelectionRange() were 
> part of the DOM Range, but they seem to be Mozilla-specific?

     Looks like it. I'd prefer the Mozilla method for form controls, though.

> That means we have three different models for working with selections in 
> input fields: the IE way, the Mozilla way, and DOM Range.

     Yeah, but from the little bit I've read of the IE method, I hear it
sucks.

> Since DOM Range is already a standard there seems to be no point in 
> defining yet another standard in WHAT (except perhaps if the point was 
> to standardize on the IE way for backwards compatibility?)

    DOM Range doesn't appear to have anything to do with actual GUI 
selection. It merely states that you can use a Range DOM object to 
represent the selection. From 
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html:

    "The term 'selecting' does not mean that every Range corresponds to 
a selection made by a GUI user; however, such a selection can be 
returned to a DOM user as a Range."

    So you see, if we want to establish a GUI selection interface for 
DOM/Javascript, we can use DOM Range as PART of the interface, but we 
still have to define some way of getting the current selection and 
setting the user selection. I'm thinking something like this:

| var myRange = document.getSelection();

    The above gets the current selection within the document. If the 
document doesn't have a selection, it returns document.createRange(). 
Similarly, there will be a setSelection method:

| document.setSelection(myRange);

    If you wish to deselect everything in the document, you could do the 
following:

| document.removeSelection();

    If you want to select a specific element, you'd do something like this:

| var myRange = document.createRange();
| var myElement = document.getElementById('myID');
|
| myRange.selectNode(myElement);
| document.setSelection(myRange);

    Do we need a way of maintaining multiple user selections? I don't 
think IE supports this. Also, do we need execCommand if we're using DOM 
Range? It would seem to me that you could just use surroundContents, 
etc. for something for some of this stuff, but that might get 
complicated. If anyone wants to chime in on these issues, feel free.

     Near as I can determine, though, DOM Range can't change attributes,
so it would be useless for use with <input>, even if the |value| 
attribute was always equal to the .value property. It doesn't really 
matter, though. With the Mozilla method, you need only find the <input> 
node and set two values to set the selection. In DOM Range, you have to 
create a Range object, feed the element node to .selectNodeContents, 
then change the start and end offsets, so you have two extra steps. 
Therefore, the Mozilla method would win even if the text was in the DOM.

> Anyway, I dont think selections should be part of WF2, but rather WA1 
> where editing is defined,

     Agreed.

 > and I certainly think that the same interface
> should be used for handling editing in form controls and in elements 
> with contentEditable.

    No. The whole idea behind |contentEditable| is that you're changing 
the DOM. The values of <input> and <textarea> may be copies of values 
set in markup, but the actual value in a control is never truly in the 
DOM. For controls like <input> and <textarea>, I prefer the Mozilla 
method anyways. It's much simpler and people don't have to understand 
DOM Range to use it, which is good in situations like this since dealing 
with selections within controls is more common.

    Question: Should any element with |contentEditable| be submitted if 
it's within a <form> and has a |name| attribute?


From mpt at myrealbox.com  Wed Feb 23 16:10:51 2005
From: mpt at myrealbox.com (Matthew Thomas)
Date: Wed, 23 Feb 2005 19:10:51 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D0123.8050202@earthlink.net>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net> <421B55A0.6080401@olav.dk>
	<421D0123.8050202@earthlink.net>
Message-ID: <f9dcd5f7b0d1d6986b7dbdded3698d80@myrealbox.com>

On 23 Feb, 2005, at 5:18 PM, Matthew Raymond wrote:
> ...
>    So you see, if we want to establish a GUI selection interface for 
> DOM/Javascript, we can use DOM Range as PART of the interface, but we 
> still have to define some way of getting the current selection and 
> setting the user selection. I'm thinking something like this:
>
> | var myRange = document.getSelection();

That seems harmless ...

>    The above gets the current selection within the document. If the 
> document doesn't have a selection, it returns document.createRange(). 
> Similarly, there will be a setSelection method:
>
> | document.setSelection(myRange);
>
>    If you wish to deselect everything in the document, you could do 
> the following:
>
> | document.removeSelection();
> ...

.... But those two, unfortunately, seem more likely to be abused than 
usefully used. Annoying authors would repeatedly clear any selection in 
a misguided attempt to prevent people from copying text, more often 
than application authors would use those functions for legitimate 
purposes. (Yes, you could work around this by turning off JavaScript, 
but that would work only for the small proportion of users who 
understand what's causing the problem.)

I know that authors can be annoying no matter what you give them (for 
example, displaying text as graphics), but I think this would make 
being annoying far too easy.

-- 
Matthew Thomas
http://mpt.net.nz/



From olav at olav.dk  Wed Feb 23 16:33:15 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 01:33:15 +0100
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D0123.8050202@earthlink.net>
References: <421A629B.2040409@mail.ru>
	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>
	<421B55A0.6080401@olav.dk> <421D0123.8050202@earthlink.net>
Message-ID: <421D20CB.3070009@olav.dk>

Matthew Raymond wrote:
 > So you see, if we want to establish a GUI selection interface for
 > DOM/Javascript, we can use DOM Range as PART of the interface, but we
 > still have to define some way of getting the current selection and
 > setting the user selection.

Okay. I get it. Mozilla seem to support something similar (also 
non-standard) to get from a selection to a DOM range:
http://www.mozilla.org/docs/dom/domref/dom_window_ref24.html#1000044
While I like your proposal, I think we should choose one of the 
currently implemented methods (IE's or Mozillas) unless they have 
serious shortcomings.

 > Yeah, but from the little bit I've read of the IE method, I hear it
 > sucks.

Well, it doesn't provide a way to get the start or end points of a 
selection, which is what the original poster wanted.
It works like this: the document has a "selection" property which 
represents the current selection. On the selection object you can call 
createRange() to create a TextRange object which is more or less similar 
to a DOM Range object (although more limited). Also, you can turn a 
TextRange into the current selected by calling the select() method on it.
It works the same way for input values, textarea values, and ordinary 
content.

 > Near as I can determine, though, DOM Range can't change attributes,
 > so it would be useless for use with <input>, even if the |value|
 > attribute was always equal to the .value property.

The DOM Range spec claims that it works on Attr-nodes also.

 > Do we need a way of maintaining multiple user selections? I don't
 > think IE supports this.

The API suggest that it does (there is a createRangeCollection() 
method), but I'm not sure this actually works.

 > Also, do we need execCommand if we're using DOM Range?

The important thing is to have contentEditable and an interface to 
manipulate the current selection. Then execCommand can be built on top 
of that in script. (The execCommand interface in IE is cool though, 
because it supports undo. Except that the undo history is cleared when 
any DOM manipulation is done using any other method than execCommand, 
which limits its usefulness).

 > I prefer the Mozilla
 > method anyways. It's much simpler and people don't have to understand
 > DOM Range to use it, which is good in situations like this since
 > dealing with selections within controls is more common.

But one interface is simpler that two interfaces, and we need DOM Range 
(or something similar) anyway to do rich editing, which is arguably just 
as common an use case.

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Wed Feb 23 20:10:40 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 23 Feb 2005 23:10:40 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D20CB.3070009@olav.dk>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>
	<421D0123.8050202@earthlink.net> <421D20CB.3070009@olav.dk>
Message-ID: <421D53C0.6040209@earthlink.net>

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
>  > So you see, if we want to establish a GUI selection interface for
>  > DOM/Javascript, we can use DOM Range as PART of the interface, but we
>  > still have to define some way of getting the current selection and
>  > setting the user selection.
> 
> Okay. I get it. Mozilla seem to support something similar (also 
> non-standard) to get from a selection to a DOM range:
> http://www.mozilla.org/docs/dom/domref/dom_window_ref24.html#1000044
> While I like your proposal, I think we should choose one of the 
> currently implemented methods (IE's or Mozillas) unless they have 
> serious shortcomings.

    The Mozilla getSelection method doesn't actually return a DOM Range, 
though, so I'm inclined to pass on it, even though we're introducing 
window in WA1. It just strikes me as too complicated; it introduces a 
completely new selection object, multiple ranges, et cetera...

    Then again, if you have a really good argument for it, I'm willing 
to  hear it.

>  > Yeah, but from the little bit I've read of the IE method, I hear it
>  > sucks.
> 
> Well, it doesn't provide a way to get the start or end points of a 
> selection, which is what the original poster wanted.
> It works like this: the document has a "selection" property which 
> represents the current selection. On the selection object you can call 
> createRange() to create a TextRange object which is more or less similar 
> to a DOM Range object (although more limited). Also, you can turn a 
> TextRange into the current selected by calling the select() method on it.
> It works the same way for input values, textarea values, and ordinary 
> content.

    Matthew Thomas was worried that allowing webmasters to alter 
selections with setSelection or removeSelection would create situations 
where webmasters would intentionally prevent users from selecting stuff. 
As a result, I think he'd oppose a model that supports setting the 
selection outside a control, which makes the IE selection model not 
terribly useful.

>  > Near as I can determine, though, DOM Range can't change attributes,
>  > so it would be useless for use with <input>, even if the |value|
>  > attribute was always equal to the .value property.
> 
> The DOM Range spec claims that it works on Attr-nodes also.

    /me shrugs.

    Okay. I just skimmed the spec, so maybe it does. Doesn't really 
matter, though, because the .value property is still not the same as the 
|value| attribute or the contents of a <textarea> element, and changing 
that would break the specification of the reset button. (In theory, you 
may actually want to change the initial value of a control in the DOM so 
that when someone hits a reset button, the new initial value is put into 
the control instead of the old one, so saving the initial value outside 
the DOM may not be an option.)

    Then again, there's a .defaultValue property. Form reset could be 
defined in such a way as to use that property as the initial value 
instead of the contents of the DOM. However, the DOM content is defined 
as the initial value in the HTML 4.01 spec, so does changing the DOM in 
some browsers change the corresponding value of .defaultValue???

    What's certain is that linking the .value property with the markup 
for the initial value would directly contradict portions of the DOM2 spec.

 From http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485:

    "Changing this attribute changes the contents of the form control, 
but does not change the value of the HTML value attribute of the element."

 From http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-70715579:

    "Changing this attribute changes the contents of the form control, 
but does not change the contents of the element."

    So would this be considered breaking backwards compatibility, since 
the opposite of the proposed behavior is defined in the spec?

>  > Do we need a way of maintaining multiple user selections? I don't
>  > think IE supports this.
> 
> The API suggest that it does (there is a createRangeCollection() 
> method), but I'm not sure this actually works.

    Perhaps we should change getSelection to getSelections and have it 
return a collection of ranges... Hmm...

>  > Also, do we need execCommand if we're using DOM Range?
> 
> The important thing is to have contentEditable and an interface to 
> manipulate the current selection. Then execCommand can be built on top 
> of that in script. (The execCommand interface in IE is cool though, 
> because it supports undo. Except that the undo history is cleared when 
> any DOM manipulation is done using any other method than execCommand, 
> which limits its usefulness).

    Well, the question, though, is whether or not DOM Range provides 
enough of an interface. In theory, you could do everything you need to, 
but in reality the scripting could get so complex that you're rather 
just use a built-in method like execCommand.

>  > I prefer the Mozilla
>  > method anyways. It's much simpler and people don't have to understand
>  > DOM Range to use it, which is good in situations like this since
>  > dealing with selections within controls is more common.
> 
> But one interface is simpler that two interfaces, and we need DOM Range 
> (or something similar) anyway to do rich editing, which is arguably just 
> as common an use case.

    The real problem is that DOM Range is largely useless for selections 
that consist entirely of a string of text obtained through the .value 
property. All I need to know is the start and end points within the 
string and I can make any changes I want using simple string 
manipulation. So there's really never a situation where you NEED 
something as complicated as DOM Range for a simple text control. Never 
mind the fact that the value you're talking about doesn't exist in the 
DOM in the first place. There's also the problem of DOM Ranges requiring 
Nodes to define their start and end points. If .value isn't in the DOM, 
what would the parent node be?

    No, better to have two systems, since we're essentially dealing with 
two kinds of content. DOM Range is a lot harder to learn anyways, so 
after that the Mozilla method should be as easy as cake.


From olav at olav.dk  Thu Feb 24 02:04:23 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 11:04:23 +0100
Subject: [whatwg] Value attribute (was: Re: [WA1] GUI Selections)
In-Reply-To: <421D53C0.6040209@earthlink.net>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>
	<421D20CB.3070009@olav.dk> <421D53C0.6040209@earthlink.net>
Message-ID: <421DA6A7.5000105@olav.dk>

 > Okay. I just skimmed the spec, so maybe it does. Doesn't really
 > matter, though, because the .value property is still not the same as
 > the |value| attribute or the contents of a <textarea> element,

Regarding the "value" property in the DOM, I think it's a bit confusing, 
but this is how I understand it:

The "value" property in the DOM reflects the current state of the input 
control in the UA. If the user edits the content of the input field, the 
DOM "value" property is updated.
However the contents of the "value" attribute in the original HTML 
source  is represented by the "defaultValue" DOM attribute. (This is 
also the initial value of the "value" attribute in the DOM). This is 
important for the reset button, but especially important if you are 
*editing* a HTML document rather than browsing it. When the document is 
serialized back to HTML by the editor, the "value" attribute in the HTML 
is generated from the "defaultValue" DOM attribute. OTOH the "value" DOM 
property is not serialized (and typically you won't change that in an 
editor anyway).

Think of it as currentValue and defaultValue. Both exists in the DOM, 
but only defaultValue is represented in the HTML source. The confusing 
part is that in HTML defaultValue is called "value", while in the DOM it 
is currentValue that is called "value".

Anyway, editing the value of an input field does change the DOM "value" 
attribute, but does not change the "value" content attribute in the 
underlying HTML.

regards
Olav Junker Kj?r


From olav at olav.dk  Thu Feb 24 03:47:01 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 12:47:01 +0100
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D53C0.6040209@earthlink.net>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>
	<421D20CB.3070009@olav.dk> <421D53C0.6040209@earthlink.net>
Message-ID: <421DBEB5.7080800@olav.dk>

Matthew Raymond wrote:
>    The Mozilla getSelection method doesn't actually return a DOM Range, 
> though, so I'm inclined to pass on it, even though we're introducing 
> window in WA1. It just strikes me as too complicated; it introduces a 
> completely new selection object, multiple ranges, et cetera...

This is like the IE model: a selection is is separate object, which may 
contain one ore more ranges. At least in IE this indirection is 
necessary since a the selection can be discontinuous e.g. several 
pictures different places in the same document (selected while holding 
the ctrl key down).

IE distinguishes between "text selection" and "control selection". 
Images, input controls, tables and absolutely positioned elements may be 
individually control-selected, which enables you to move end resize 
them. Continuous ranges of text (including objects) may be 
text-selected, but as far as I know, only one continuous text range can 
be selected at a time.
I don't know if Mozilla has a similar distinction?

Anyway, I agree this seem like overkill if you just want to manipulate 
the selection in a text-box. It might be useful to have some convenience 
methods to get the start and end points of a the current selection in a 
input field without having to walk through the selection and range objects.


>    Well, the question, though, is whether or not DOM Range provides 
> enough of an interface. In theory, you could do everything you need to, 
> but in reality the scripting could get so complex that you're rather 
> just use a built-in method like execCommand.

True. The execCommand encapsulates quite a bit of complexity. The 
problem with the IE version is that it is a black box. You cannot modify 
how a command works, you cannot create your own commands, and if you 
work outside of the box (and directly through the DOM), the undo history 
(which is the killer feature) is cleared. If WA1 should include 
execCommand, it should be a more general framework, which should allow 
you to create your own undoable commands. In the end this gets rather 
complicated.

It does make sense though, to standardize the execCommand interface, 
since lots of CMS frontends rely on contentEditable+execCommand, and 
this is an area where IE have a stronghold, since its still the only 
browser (as far as I know) that support contentEditable.

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Thu Feb 24 04:27:21 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 24 Feb 2005 07:27:21 -0500
Subject: [whatwg] Value attribute
In-Reply-To: <421DA6A7.5000105@olav.dk>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>	<421D20CB.3070009@olav.dk>
	<421D53C0.6040209@earthlink.net> <421DA6A7.5000105@olav.dk>
Message-ID: <421DC829.5090505@earthlink.net>

Olav Junker Kj?r wrote:
[Snip!]
> Think of it as currentValue and defaultValue. Both exists in the DOM, 
> but only defaultValue is represented in the HTML source. The confusing 
> part is that in HTML defaultValue is called "value", while in the DOM it 
> is currentValue that is called "value".
> 
> Anyway, editing the value of an input field does change the DOM "value" 
> attribute, but does not change the "value" content attribute in the 
> underlying HTML.

    In general, if you set a DOM property, it won't set the actual 
attribute in markup. In order to change the markup, I think you have to 
use the setAttribute method. However, I believe that the setAttribute 
method does change the DOM property.

    Internet Explorer, as I understand, completely ignores this and 
always makes a property and the corresponding attribute the same. In 
other words, IE is aspec.


From ian at hixie.ch  Thu Feb 24 04:51:58 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 24 Feb 2005 12:51:58 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <421CB517.1030307@earthlink.net>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
	<Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
	<421CB517.1030307@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502241226420.25653@dhalsim.dreamhost.com>


Boy did this get out of hand.

Matthew. I encourage you to send your proposals to this mailing list. The 
e-mail you sent with your proposal is still in my queue, along with all 
the other WA1 and WF2 proposals that have been sent and have not yet 
received technical replies. It will be given the same consideration as all 
the other proposals, including Tantek's and anything else I (or whoever 
the spec editor is at that time) come across.

There is no conspiracy here. Please relax. The only reason I suggested 
contacting Tantek is because I know he's been working on this topic, that 
he has some very good ideas, and that he is welcoming feedback. I would 
have thought that working with him on a proposal would have been more 
productive than working on independent proposals. However, that was merely 
a suggestion and was not meant to imply that other proposals would be 
ignored or given a different level of consideration.

In particular, please don't think that I will be swayed by flashy 
graphics, fancy markup, diagrams, or wiki-based development. At the end of 
the day I'm just looking at technical ideas on their technical merit, 
regardless of who came up with them and how they were presented. Some of 
the things in WF2 were originally just doodles people left on my 
whiteboard, others were formal proposals that went through the W3C or IETF 
recommendation tracks.

Also, progress on WHATWG specs is going at its own rate, and is not 
controlled by progress on external drafts or proposals.


On Wed, 23 Feb 2005, Matthew Raymond wrote:
> 
> In fact, I've been asking for a WHATWG wiki for quite some time.

I don't have the resources to set that up, but if you want to set up a 
wiki.whatwg.org site I could get you an account. However, I'm not really 
sure what the point is. As far as I'm concerned this mailing list is the 
most convenient way for me to handle input. I wouldn't monitor a wiki (or 
probably even look at it) if one was created.


> Oh, one other thing. If you're going to like to a spec, the page should 
> be static, not a wiki. Otherwise, you could inadvertently allow anyone 
> and their mother to change part of a WHATWG spec at will.

I do not intend to normatively reference easily editable resources. The 
links are currently purely informative to give people an idea of what was 
being considered when that part of the spec was written.


> Actually, you gave a specific time you'd be working on it...
> 
> "I'm not planning on touching the relevant sections of WA1 until 
> Tantek's drafts are much more stable."

I spoke ambiguously, my apologies. What I meant was that by the time I 
next touched those sections, I expected Tantek's drafts to be much more 
stable. (In particular, I am currently prioritising folding HTML4, XHTML1, 
and DOM2 HTML into WA1, adding the section on the Window interface, and 
speccing the new interfaces for networking and messaging. There is a LOT 
of work there.)


> > If your proposals are technically superior to other proposals, then, 
> > once it comes to including a calendar mechanism in the WA1 spec, the 
> > WHATWG members (probably represented by me) will use your proposals.
> 
> When will that be? When you're ready, or when Tantek is? (No offense to 
> Tantek. This is an argument of procedure rather than character.)

When I, or whoever is editing the spec, is ready.


> > > Might I also point out that the wikis you posted URLs to have NO 
> > > COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
> > > COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
> > > TECHNORATI. Who's to say his company won't just turn around and 
> > > claim copyrights and patents to the whole mess?
> > 
> > All good points to raise with Tantek.
> 
> Not if you're linking to them through the WA1 spec.

Whatever becomes the calendar/card section of WA1, I expect it to be 
completely defined in the WA1 spec, not reference an external spec. 
(Except if the definition is in terms of an external data model, such as 
an alternate serialisation of vCard -- in that case, the serialisation and 
interpretation would be in WA1, but the data model and semantics would be 
in the external spec.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From olav at olav.dk  Thu Feb 24 06:18:16 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 15:18:16 +0100
Subject: [whatwg] Value attribute
In-Reply-To: <421DC829.5090505@earthlink.net>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>	<421D20CB.3070009@olav.dk>	<421D53C0.6040209@earthlink.net>
	<421DA6A7.5000105@olav.dk> <421DC829.5090505@earthlink.net>
Message-ID: <421DE228.60502@olav.dk>

Matthew Raymond wrote:
>    In general, if you set a DOM property, it won't set the actual 
> attribute in markup. In order to change the markup, I think you have to 
> use the setAttribute method. However, I believe that the setAttribute 
> method does change the DOM property.

Did a quick test: In Mozilla, IE and Opera setting an ordinary attribute 
through a DOM property seems to be equivalent to using setAttribute. The 
"value" property is handled differently though. In IE and Opera 
getAttribute("value") returns the same as the "value" DOM property, 
while in Mozilla it returns the same as the defaultValue property (which 
is the correct behavior, I think). However, using innerHTML in Opera 
seem to serialize the element correctly by using the defaultValue 
property as at content of the value HTML, as does Mozilla.

Anyway, your original statment that DOM Range couldn't work on the 
current value in an input field seems to be correct. The DOM Range may 
work on an Attr node but not any DOM attribute. The current value is in 
the DOM in the form of an property, but not in the form of a DOM Attr node.

regards
Olav


From olav at olav.dk  Thu Feb 24 07:36:43 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 16:36:43 +0100
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D0123.8050202@earthlink.net>
References: <421A629B.2040409@mail.ru>
	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>
	<421B55A0.6080401@olav.dk> <421D0123.8050202@earthlink.net>
Message-ID: <421DF48B.10103@olav.dk>

Matthew Raymond wrote:
> | var myRange = document.getSelection();
> 
>    The above gets the current selection within the document. If the 
> document doesn't have a selection, it returns document.createRange(). 
> Similarly, there will be a setSelection method:

You assume that the selection is a property of the document. This is 
like IE, while in Mozilla its a propery of the window (if I understand 
the API correctly).

I think it makes most sense to have the selection be a property of the 
viewport i.e. the window object. If we consider two frames containing 
two different views of the same document (this is theoretically possible 
according to the dom spec), it would seem natural to allow different 
focus and selections in each view. (If e.g. an HTML editor allowed two 
different wiews on the same page while editing, this would matter.)

Btw. the DocumentFocus interface in WA1 (section 11.3) also seem to 
assume that focus is a propery of the document rather than the viewport. 
Again I think its more correct to have it a property of the viewport.

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Thu Feb 24 08:10:27 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 24 Feb 2005 11:10:27 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421DF48B.10103@olav.dk>
References: <421A629B.2040409@mail.ru>
	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>
	<421B55A0.6080401@olav.dk> <421D0123.8050202@earthlink.net>
	<421DF48B.10103@olav.dk>
Message-ID: <421DFC73.2060800@earthlink.net>

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
>>| var myRange = document.getSelection();
>>
>>   The above gets the current selection within the document. If the 
>>document doesn't have a selection, it returns document.createRange(). 
>>Similarly, there will be a setSelection method:
> 
> You assume that the selection is a property of the document. This is 
> like IE, while in Mozilla its a propery of the window (if I understand 
> the API correctly).

    That's my understanding too, though I'm hardly an expert.

> I think it makes most sense to have the selection be a property of the 
> viewport i.e. the window object.

    Yeah, I was mainly trying to avoid breaking existing Mozilla scripts 
using window.getSelection. I suppose we could just rename the thing 
"getSelectionRange", though. The main question is whether we care about 
multiple selections and the like. Perhaps we could have 
getSelectionRange return the first selection in the part of the viewport 
that has focus...

> If we consider two frames containing 
> two different views of the same document (this is theoretically possible 
> according to the dom spec), it would seem natural to allow different 
> focus and selections in each view.

    Depends on whether the viewports are actually using the same 
document object. If each viewport has it's own document object that 
happens to be created from the same document, then the selections could 
just be obtained from the document object. I think that's the case when 
you open the same page in two different browser windows.

    I do see your point, though. For instance, two people could be 
viewing a web page together over some kind of conferencing software, in 
which case they could each be selecting something different in their own 
viewports but sharing the same document object.

> (If e.g. an HTML editor allowed two 
> different wiews on the same page while editing, this would matter.)

    Bad example. You wouldn't want to be running script on the DOM at 
the same time you're editing the markup. Point already made, though.

> Btw. the DocumentFocus interface in WA1 (section 11.3) also seem to 
> assume that focus is a propery of the document rather than the viewport. 
> Again I think its more correct to have it a property of the viewport.

   Yup, window.getSelectionRange it is, then...


From mattraymond at earthlink.net  Thu Feb 24 08:50:00 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 24 Feb 2005 11:50:00 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502241226420.25653@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
	<Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
	<421CB517.1030307@earthlink.net>
	<Pine.LNX.4.61.0502241226420.25653@dhalsim.dreamhost.com>
Message-ID: <421E05B8.1050906@earthlink.net>

Ian Hickson wrote:
> Boy did this get out of hand.
> 
> Matthew. I encourage you to send your proposals to this mailing list. The 
> e-mail you sent with your proposal is still in my queue, along with all 
> the other WA1 and WF2 proposals that have been sent and have not yet 
> received technical replies. It will be given the same consideration as all 
> the other proposals, including Tantek's and anything else I (or whoever 
> the spec editor is at that time) come across.
> 
> There is no conspiracy here.

    Give it up! I know it was you and Tantek flying over my house in a 
black helicopter last night trying to reprogram me with radio waves!

> Please relax.

    I find it's usually unwise to say this to someone who is truly upset. ;)

> The only reason I suggested 
> contacting Tantek is because I know he's been working on this topic, that 
> he has some very good ideas, and that he is welcoming feedback. I would 
> have thought that working with him on a proposal would have been more 
> productive than working on independent proposals. However, that was merely 
> a suggestion and was not meant to imply that other proposals would be 
> ignored or given a different level of consideration.

    Glad we cleared that up then.

> In particular, please don't think that I will be swayed by flashy 
> graphics, fancy markup, diagrams, or wiki-based development.

    I never meant to imply this. I was trying to avoid a situation where 
a section of the spec was being developed outside of WHATWG in a way 
that gave people unequal opportunity to express their views and opinions.

[Snip!]
> Also, progress on WHATWG specs is going at its own rate, and is not 
> controlled by progress on external drafts or proposals.

   That's what I wanted to hear.

> On Wed, 23 Feb 2005, Matthew Raymond wrote:
>>In fact, I've been asking for a WHATWG wiki for quite some time.
> 
> I don't have the resources to set that up, but if you want to set up a 
> wiki.whatwg.org site I could get you an account. However, I'm not really 
> sure what the point is. As far as I'm concerned this mailing list is the 
> most convenient way for me to handle input. I wouldn't monitor a wiki (or 
> probably even look at it) if one was created.

    I've had several situations where people didn't understand the ideas 
I was presenting because they were spread out over several emails. 
Often, someone would confuse a concept I was advocating with an 
older-but-similar concept I had abandoned. Take the following concepts, 
for instance:

  * <format>
  * <dateinput>
  * <date> (as an input control)
  * <idate>
  * <icomplex>
  * <dataentry>

    They're all closely related to each other. In fact, <dataentry> is 
pretty much the same as <icomplex>. If there was a simple wiki I could 
use to maintain my ideas about the general topic, I could simply post 
the URL at the beginning of a message rather than having to hunt down 
all my messages and giving a long explanation of what parts were relevant.

    If I can find a way to set up a wiki for WHATWG, though, you'll be 
the first to know.

>>Actually, you gave a specific time you'd be working on it...
>>
>>"I'm not planning on touching the relevant sections of WA1 until 
>>Tantek's drafts are much more stable."
> 
> I spoke ambiguously, my apologies. What I meant was that by the time I 
> next touched those sections, I expected Tantek's drafts to be much more 
> stable. (In particular, I am currently prioritising folding HTML4, XHTML1, 
> and DOM2 HTML into WA1, adding the section on the Window interface, and 
> speccing the new interfaces for networking and messaging. There is a LOT 
> of work there.)

    Oh, I know you're busy, and that it often takes you a long time to 
get to some portions of a spec. I objected to what I thought was you 
saying you wouldn't even look at anything until Tantek's draft ready, 
which appears to be a miscommunication at this point.


From ian at hixie.ch  Fri Feb 25 04:20:03 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 25 Feb 2005 12:20:03 +0000 (UTC)
Subject: [whatwg] Introducing new elements is expensive
Message-ID: <Pine.LNX.4.61.0502251200130.16532@dhalsim.dreamhost.com>


I was just browsing through some of the proposals for WF2 and WA1 I've yet 
to respond to, and I noticed that several of them suggest introducing new 
elements.

While there are cases where new elements are appropriate, I'd like to 
encourage anyone making proposals to consider new elements to be very 
expensive. Introducing a new element:

 * Requires a new DOM interface.

 * Requires a lot of code to implement in native implementations.

 * Requires changes to HTML parsers, which is *very* hard.

 * Is a pain to implement in IE6.

 * Makes it a lot harder for authors to style the document in legacy UA,
   since the element doesn't appear in all legacy UAs, and not in the 
   same way when it does.

 * Makes it a lot harder for authors to navigate the DOM in script, as the
   elements have different index positions in the various DOM arrays.

I would recommend that suggestions avoid new elements, especially when 
those elements have a lot of attributes, and especially when the element 
has semantics very similar to an existing element.

Note that I consider the above problems to be a _lot_ worse than less- 
than-ideal fallback in legacy UAs. Speaking of fallback, I also consider 
it more important that legacy UAs get working fallback in all cases, thant 
that authors can provide ideal fallback if they want. My experience with 
the <object> element (which defaults to no fallback but allows for ideal 
fallback) is that authors rarely bother providing alternatives.

If you do introduce a new element, please include a detailed definition of 
the DOM interface that goes with it, along with definitions of each method 
and attribute on that interface. You should also include a detailed 
description of where the element can be placed, what can be placed inside 
the element, what each attribute does, what happens when the element has 
the wrong content, is in the wrong place, has the wrong attributes, or has 
attributes with the wrong values, and finally what the processing model is 
for when the element is correctly used. For an example of the detail you 
need, look at the definitions of elements like <base> in the WA1 spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jim.ley at gmail.com  Fri Feb 25 04:56:50 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Fri, 25 Feb 2005 12:56:50 +0000
Subject: [whatwg] Introducing new elements is expensive
In-Reply-To: <Pine.LNX.4.61.0502251200130.16532@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502251200130.16532@dhalsim.dreamhost.com>
Message-ID: <851c8d3105022504563c37481a@mail.gmail.com>

On Fri, 25 Feb 2005 12:20:03 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:

> * Is a pain to implement in IE6.

This is not true, implementing new elements is not a pain, other parts
of the spec are considerably harder, unless you can back statements
like this up, please don't use them, it makes the other statements so
much less believable.

As to all the information that you're saying need to be provided -
could you point to where that is in the spec for the datalist element?

Jim.


From mattraymond at earthlink.net  Wed Feb  2 08:00:21 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 02 Feb 2005 11:00:21 -0500
Subject: [whatwg] [WA1] Idea for Calendar Markup
Message-ID: <4200F915.9060803@earthlink.net>

    I like the idea of a calendar in Web Applications 1.0, but I really 
hate the way they're currently implemented. For one thing, if the 
|class| attribute contains the name of a calendar attribute, how do you 
style the element? What happens if you use |class| to style something, 
and the class happens to be the name of a calendar attribute? Does it 
style that attribute.

    Nope, I prefer to stick with good old-fashioned elements. Here's an 
example of what I'd like to see, minus the fallback content:

| <calendar>
|   <cevent id="e036f260-39b4-11d9-ad3f-fc68600c1802">
|     <csummary value="That thing we did that was so fun."></csummary>
|     <cattr type="status" value="CONFIRMED"></cattr>
|     <cattr type="class" value="PRIVATE"></cattr>
|     <cattr type="categories" value="Work"></cattr>
|     <cattr type="x-mozilla-alarm-default-length" value="0"></cattr>
|     <cattr type="dtstamp" value="2005-02-02T21:00Z"></cattr>
|     <cdatetime start="2005-02-30T19:00Z" end="2005-02-30T21:00Z">
|     </cdatetime>
|   </cevent>
| </calendar>

    Basic stuff like the summary and the start and end dates are defined 
specifically. The rest of the calendar event attributes are defined with 
<cattr type="attribute-name">. A WA1-compliant UA would then assign the 
|value| attribute as the value of the calendar event attribute. If 
|value| is not specified, the child contents are used. The <cdatetime> 
element is a special case in that it requires <datetime> elements to be 
in the child contents if |value| is undefined.

    All contents inside <calendar> that are not calendar-related 
elements or the contents of calendar-related elements are ignored. As a 
result, the following would provide proper fallback content:

| <calendar>
|   <table>
|     <caption>Upcoming Events</caption>
|     <tr>
|       <th>Summary</th>
|       <th>Status</th>
|       <th>Class</th>
|       <th>Categories</th>
|       <th>Start Date</th>
|       <th>End Date</th>
|     </tr>
|     <cevent id="e036f260-39b4-11d9-ad3f-fc68600c1802">
|     <tr>
|       <td><csummary>
|         That thing we did that was so fun.
|       </calsummary></td>
|       <td><cattr type="status">CONFIRMED</cattr></td>
|       <td><cattr type="class">PRIVATE</cattr></td>
|       <td><cattr type="categories">Work</cattr></td>
|       <cattr type="x-mozilla-alarm-default-length" value="0"></cattr>
|       <cattr type="dtstamp">
|         <datetime value="2005-02-02T21:00Z"></datetime>
|       </cattr>
|       <cdatetime>
|         <td><datetime value="2005-02-30T21:00Z">
|           02/30/05 7:00 PM
|         </datetime></td>
|         <td><datetime value="2005-02-30T21:00Z">
|           02/30/05 9:00 PM
|         </datetime></td>
|       </cdatetime>
|     </tr>
|     </cevent>
|   </table>
| </calendar>

    The above should render in legacy user agents as a table, with 
values unimportant to presentation not rendered. Yet, for a WA1 UA, it 
yields the same calendar as the first example.

    Note that in both examples, if the |type| of a <cattr> element is 
unknown to the user agent, the value can simply be ignored. The <cattr> 
would have a set of standardized |type| values that all user agents 
would support, then individual user agent vendors could implement 
extensions, with the recommended nomenclature being something like this:

    x-[company or organization]-[attribute name]

    This should give us a reasonable amount of flexibility and 
extensibility without creating a complicated markup scheme. If 
necessary, <cdatetime> and <csummary> could be rolled into <cattr>, but 
I'd prefer to have these separate, since they're likely to always be used.

   That's all for now. Thoughts welcome.


From ian at hixie.ch  Thu Feb  3 05:36:54 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 13:36:54 +0000 (UTC)
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <41FE8360.6000607@yahoo.com>
References: <41FC2D55.6030608@yahoo.com>
	<Pine.LNX.4.61.0501311501020.9893@dhalsim.dreamhost.com>
	<41FE8360.6000607@yahoo.com>
Message-ID: <Pine.LNX.4.61.0502031333100.6666@dhalsim.dreamhost.com>

On Mon, 31 Jan 2005, Daniel Brooks wrote:
> 
> Ah, that makes sense. Perhaps a single sentance that states that they 
> are counted as two form controls just like is described elsewhere (with 
> a reference), but that they are otherwise skipped.

The spec says:

| For image controls, instead of using the name given by the name 
| attribute, the field's name is checked against two names, the first 
| being the value of the name attribute with the string .x appended to it, 
| and the second being the same but with .y appended instead. Thus image 
| controls are handled as if they were two controls.
|
| If the identified form control is a file upload control, a push button 
| control, or an image control, then the field element is now skipped.


> Ah, it's in the third paragraph, but now that I read it again I see that 
> it says 'from script', not 'form script', so I guess it's ok, but 'for a 
> script' or 'for scripts' would be easier to read. The whole sentance is 
> "There is no way from script to detect this situation because that would 
> open the way for some privacy or security leaks."

Done.


Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 05:59:44 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 13:59:44 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <41FF0B32.8050604@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>

On Mon, 31 Jan 2005, Matthew Raymond wrote:
>>
>> It has problems, as mentioned elsewhere in the thread:
>>
>>  * It is easy for authors to not include any fallback, which makes it
>>    worse than the <input> equivalent.
> 
> If the legacy fallback is simply an <input>, then inheritance handles it 
> nicely. If you start with this:
> 
> | <input name="date" value="2005-01-31"> Format: YYYY-MM-DD

But you don't. Many, if not most, WF2 documents will be new documents. 
There is no existing content. Authors would just do:

   <idate name="date"/>

...or some such, and be done with it.


> Therefore, I see no reason why a webmaster would choose to drop their 
> legacy content when upgrading their websites to use <idate> and its 
> siblings.

The problem is assuming the Web author is upgrading a Web site in the 
first place. It could be a new one.


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



> >  * The fallback and non-fallback controls have different names.
> 
> This is only true of the 3SC scenario, and in that situation the server 
> script can easily be rewritten to handle the situation.

I thought we had to assume the server couldn't be changed?


>>  * The datetime types don't really need comprehensive fallback, given
>>    that the three cases that they could replace are:
>>      1. Text inputs, which would be improved, not hurt, by the new
>>         types,
> 
> Except you never solved the formatting hints problem to anyone's 
> satisfaction

I still don't understand what is wrong with the short amount of black-box 
JavaScript I proposed. It handles more cases than your proposals with no 
work on the UA implementor's behalf.

Not to mention that many of the authors who fall into this "1" category 
simply don't provide formatting hints at all. The authors who are likely 
to care about fallback formatting hints simply wouldn't use text inputs in 
current pages anyway, and therefore aren't, IMHO, part of this category.



> nor did you explain how to handle legacy sites that use <input> + DHTML 
> solutions.

That would be category 3 below.


> Elements like <idate>, as seen above, solve this problem in a simple, 
> straight-forward and effective manner.

IMHO it is neither simple, nor straight-forward, nor effective, and has 
serious drawbacks, as I have described. It certainly isn't a bad solution, 
but it isn't, IMHO, any better than what we have already.


> >      2. <select> controls, which do not need to be replaced at all,
> >         and
> 
> Yes you do. In fact, if people prefer using <select> controls for legacy 
> input, then failing to support it will drive people away from WF2, at 
> least where the date/time markup is concerned.

Why would this be a problem? As I said before, we're not trying to get 
people to use WF2 for the sake of using WF2 here.


> It may even give some user agent vendors reason not to implement parts 
> of the WF2 spec.

I highly doubt that use or lack of use of type="date" on sites will affect 
whether UAs implement it or not. There are plenty of counter-examples. 
(Nobody uses XForms, yet IBM implements it in Mozilla; lots of people use 
XSLT, yet Opera isn't implementing that, etc.)


> >      3. Complex JS widgets, for which declarative fallback is not
> >         needed.
> 
> Having a consistent, localized, canned date control is something 
> webmasters are going to want even if they have complex DHTML widgets. 
> However, they're not going to want to get rid of their DHTML widgets on 
> legacy clients that are still bound to be around for many years. As a 
> result, if you make it nigh impossible for them to use their widgets as 
> a fallback, they're just going to continue using them because they know 
> they'll still work on WF2 user agents.

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


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


> Could you provide a use case where implementation would be an issue?

I have no idea what you mean by this.



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


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


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


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lachlan.hunt at iinet.net.au  Thu Feb  3 06:08:15 2005
From: lachlan.hunt at iinet.net.au (Lachlan Hunt)
Date: Fri, 04 Feb 2005 01:08:15 +1100
Subject: [whatwg] [WF2] 6.2: maxlength Defintion - Grammatical Problems
Message-ID: <4202304F.5060705@iinet.net.au>

Hi,
   In section 6.2, under the defintion of the maxlength attribute, the 
current draft states [1]:

| Authors are encouraged to use maxlength on uri and email fields only
| if the server side processor actually has a limit on the size of data
| fields it can usefully process. Valid URIs and e-mail addresses in
| particular can often be surprisingly long.

I misread that several times as I was skimming through, thinking it 
meant that using maxlength on uri and email fields was generally a good 
thing.  I suggest you reverse it so that it makes a little more sense. 
I think this would be better:

   Authors are _discouraged from using_ maxlength on uri and email fields
   _unless_ the server side processor actually has a limit on the size of
   data fields it can usefully process. Valid URIs and e-mail addresses
   in particular can often be surprisingly long.

Also, another grammatical error I came across several times throught the 
draft is whenever it says "comply to", "complies to" or any other 
variation.  The correct preposition to use is actually "with", not "to". 
  Thus, they should read "comply with", "complies with", etc.

[1] 
http://www.whatwg.org/specs/web-forms/2005-01-28-call-for-comments/#extensions0
-- 
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/    Rediscover the Web
http://SpreadFirefox.com/   Igniting the Web



From ian at hixie.ch  Thu Feb  3 06:09:07 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 14:09:07 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <41FE6E94.6070604@cam.ac.uk>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
Message-ID: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>

On Mon, 31 Jan 2005, James Graham wrote:
> > 
> > It has problems, as mentioned elsewhere in the thread:
> > 
> > * It is easy for authors to not include any fallback, which makes it 
> > worse than the <input> equivalent.
>
> In general, it is easy to make WF2 pages incompatible with older 
> browsers.

Granted, but at least it's not the default.


> > * The fallback and non-fallback controls have different names.
>
> Why is that a problem? Would it not be a simple if construct on the 
> server side to deal with the two cases?

Having two different forms (as opposed to one form with just better 
behaviour in newer UAs) is something that the current WF2 design has, by 
and large, been striving for.


> >     2. <select> controls, which do not need to be replaced at all,
> 
> If that's really true, then all the date types seem a little pointless. 
> I thought that one of the advantages of the WF2 controls was allowing 
> sites to present a consistent, OS-specific interface to form controls. 
> If multiple select controls are as good a solution, there seems little 
> point in implementing or using WF2.

Indeed. Three <select>s are reasonably good UI, although not as good as 
type="date" on a supporting UA. While WF2 UAs are not in the majority, 
there's not really a huge advantage to using the new types. (This applies 
to <idate> et all as well, by the way.)

Similarly, while XHTML is not supported in the majority of UAs, there's 
not really any reason to use XHTML. That doesn't mean that XHTML is bad, 
indeed, XHTML (and especially the ability to create compound documents by 
mixing namespaces _with_ XHTML) is great. But there's no reason to rush 
off and use XHTML in the meantime.

The difference is that if you _do_ want to use type="date", you can do so, 
and legacy UAs will still work (albeit not as user-friendlyly). With 
XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have to be 
all-or-nothing, but authors are likely to take the easy route and thus not 
provide any fallback content. (Just look at how many authors provide good 
fallback content for images.)


> >     3. Complex JS widgets, for which declarative fallback is not needed.
>
> Why not? If one is replacing a javascript control with a WF2 control, 
> one can improve the accessibility of one's page further by providing 
> simple controls for legacy clients (this would be equivalant to say, 
> producing a CSS based design and allowing old browsers to recieve 
> unstyled content v using a table based design and blocking old browsers 
> entirely).

I said _declarative_ fallback was not needed. If you're using JS, you can 
easily implement the fallback yourself using JS.


> > ...not to mention the extra complexity and the implementation 
> > difficulty compared to just using a new "type".
>
> Really? Obviously you're much more familiar with the browser engines 
> than I am but I'm not sure that this is obviously difficult to 
> implement. At least not obviously a lot more difficult than WF2 datetime 
> controls are anyway. Is there something specific that browsers will 
> struggle to cope with?

Nothing specific. Just every little added bit of complexity. I'm already 
getting requests from implementors to drop the entire repetition model, 
and to massively simplify the validity stuff, etc. And those aren't 
particularly hard to implement.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 06:53:44 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 14:53:44 +0000 (UTC)
Subject: [whatwg] [WF2] 6.2: maxlength Defintion - Grammatical Problems
In-Reply-To: <4202304F.5060705@iinet.net.au>
References: <4202304F.5060705@iinet.net.au>
Message-ID: <Pine.LNX.4.61.0502031432370.6666@dhalsim.dreamhost.com>

On Fri, 4 Feb 2005, Lachlan Hunt wrote:
>
> I misread that several times as I was skimming through, thinking it 
> meant that using maxlength on uri and email fields was generally a good 
> thing.  I suggest you reverse it so that it makes a little more sense. I 
> think this would be better:
> 
>   Authors are _discouraged from using_ maxlength on uri and email fields
>   _unless_ the server side processor actually has a limit on the size of
>   data fields it can usefully process. Valid URIs and e-mail addresses
>   in particular can often be surprisingly long.

Good idea. Done.


> Also, another grammatical error I came across several times throught the 
> draft is whenever it says "comply to", "complies to" or any other 
> variation.  The correct preposition to use is actually "with", not "to".  
> Thus, they should read "comply with", "complies with", etc.

I couldn't find any reference to back this up, but since I don't have a 
strong opinion either way, I changed them all to "with".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 07:58:34 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 15:58:34 +0000 (UTC)
Subject: [whatwg] Web Forms 2 stable draft draft
Message-ID: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>


I've added a blurb in the status section of the WF2 document listing the 
issues that I am aware of that people still are not happy with with regard 
to the current state of the WF2 draft.

What a horrible sentence.

Anyway, please let me know ASAP if I've missed an issue.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Thu Feb  3 08:17:11 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 17:17:11 +0100
Subject: [whatwg] Use IRI instead of URI
Message-ID: <42024E87.4030505@annevankesteren.nl>

Since IRI is now a RFC, shouldn't Web Forms use that term instead of URI?

(For example, in section 2.12. I guess once UAs start supporting IRIs
you want a list of IRIs there, not just URIs.)


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From fora at annevankesteren.nl  Thu Feb  3 08:21:23 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 17:21:23 +0100
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
Message-ID: <42024F83.4020904@annevankesteren.nl>

I think Web Forms 2 should refer to a dated version of HTML 4.01 (for 
example section 2.13), not to the latest version since there is a very 
small chance that the definition might change eventually.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From mattraymond at earthlink.net  Thu Feb  3 08:49:53 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 03 Feb 2005 11:49:53 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
Message-ID: <42025631.7060004@earthlink.net>

Ian Hickson wrote:
> On Mon, 31 Jan 2005, Matthew Raymond wrote:
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>> * It is easy for authors to not include any fallback, which makes it
>>>   worse than the <input> equivalent.
>>
>>If the legacy fallback is simply an <input>, then inheritance handles it 
>>nicely. If you start with this:
>>
>>| <input name="date" value="2005-01-31"> Format: YYYY-MM-DD
> 
> But you don't. Many, if not most, WF2 documents will be new documents.

    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.

> 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? Furthermore, WF2 user 
agents will have little initial marketshare, so why would someone target 
them and leave out legacy support? This is especially nonsensical when 
you notice that supporting legacy UAs in a manner similar to <input 
type="date"> really isn't that hard:

| <idate><input name="date"></idate>

    And they're going to have to know how to use <input> to create forms 
anyways. If anything, <input type="date"> is just as confusing because 
it requires you to set the |type| attribute when the webmaster may have 
only learned this:

| <input name="date">

    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.

>>Therefore, I see no reason why a webmaster would choose to drop their 
>>legacy content when upgrading their websites to use <idate> and its 
>>siblings.
> 
> The problem is assuming the Web author is upgrading a Web site in the 
> first place. It could be a new one.

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

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

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

>>> * The fallback and non-fallback controls have different names.
>>
>>This is only true of the 3SC scenario, and in that situation the server 
>>script can easily be rewritten to handle the situation.
> 
> I thought we had to assume the server couldn't be changed?

    I thought I'd already acknowledged in a previous message that most 
people on this mailing list felt client-side formatting was a bad idea. 
That's why I call it "<idate>" now instead of "<date>".

>>> * The datetime types don't really need comprehensive fallback, given
>>>   that the three cases that they could replace are:
>>>     1. Text inputs, which would be improved, not hurt, by the new
>>>        types,
>>
>>Except you never solved the formatting hints problem to anyone's 
>>satisfaction
> 
> 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?

2) It relied on a empty <span> element, which doesn't validate under 
HTML Strict.

3) With Javascript turned off, you have the problem of having to select 
and delete the format hint text in some situations.

4) New webmasters, who don't understand how the script works, will 
easily break it.

5) The script takes up nearly as much space as the HTML!

    By contrast, my modified version using <idate> probably cut the size 
of the demo web page in half and supports the same features.

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

    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.

    Furthermore, the above code doesn't require the web author to know 
anything about the attributes of <idate> unless they specifically want 
to use three <select> elements or some similar scenario. Even then, the 
attributes are the same as <input>.

    So the real question is: How does the marginal added complexity of 
<idate> offset the benefit?

> 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. All three examples of textboxes used for dates have had formatting 
hints of some kind. QJump has in recent times dropped them from their 
front page, but does include them when it asks you to verify your 
journey details. (And in other places they use <select> elements.)

 > The authors who are likely to care about fallback formatting hints
 > simply wouldn't use text inputs in current pages anyway, and therefore'
 > aren't, IMHO, part of this category.

    There are plenty of reasons for them to care, not the least of which 
is localization and client-side date validation. Plus, as I've pointed 
out in previous messages, Javascript is required for a three <select> 
solution because the number of days in a month changes month-to-month.

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

>>Elements like <idate>, as seen above, solve this problem in a simple, 
>>straight-forward and effective manner.
> 
> IMHO it is neither simple, nor straight-forward, nor effective, and has 
> serious drawbacks, as I have described. It certainly isn't a bad solution, 
> but it isn't, IMHO, any better than what we have already.

    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.

    The supposed drawbacks, in my opinion, aren't serious. People who 
can't understand the markup aren't likely to be smart enough to 
hand-code HTML anyways. For those who use editors that don't support 
WF2, it's just as easy to create a textbox control and slap two <idate> 
tags around it as it is to create a textbox control and change the 
|type| to "date". In fact, some editors can be easily configured so that 
you can simply select the <input> element and press a button.

    As for pages intentionally written without fallback, legacy browser 
users, who will remain in the majority for perhaps years to come, can 
simply elect to to visit such pages, thus decreasing their hit counts. 
So if the webmaster cares if people visit her/his site, he/she will 
support legacy clients.

>>>     2. <select> controls, which do not need to be replaced at all,
>>>        and
>>
>>Yes you do. In fact, if people prefer using <select> controls for legacy 
>>input, then failing to support it will drive people away from WF2, at 
>>least where the date/time markup is concerned.
> 
> Why would this be a problem? As I said before, we're not trying to get 
> people to use WF2 for the sake of using WF2 here.

    We want them to use it because it's a better solution. However, if 
it's a better solution only on a few new browsers, but a worse solution 
on legacy browsers, which are in the majority, that makes WF2 a worse 
solution over all.

>>It may even give some user agent vendors reason not to implement parts 
>>of the WF2 spec.
> 
> I highly doubt that use or lack of use of type="date" on sites will affect 
> whether UAs implement it or not. There are plenty of counter-examples. 
> (Nobody uses XForms, yet IBM implements it in Mozilla; lots of people use 
> XSLT, yet Opera isn't implementing that, etc.)

    XSLT is being used by Microsoft as one excuse for not supporting web 
standards. It also can just as easily be done on the server as the 
client, so there's no reason to put it in the browser. Therefore, Opera 
had a reason not to implement it.

    XForms has yet to come out of beta on the Mozilla platform, and as I 
recall, Opera isn't going to include support because it's so complex. 
That complexity has given vendors reason to delay or even decide against 
implementation.

    So I don't see how those example help your case. In both situations, 
problems with the technology limited UA support.

>>>     3. Complex JS widgets, for which declarative fallback is not
>>>        needed.
>>
>>Having a consistent, localized, canned date control is something 
>>webmasters are going to want even if they have complex DHTML widgets. 
>>However, they're not going to want to get rid of their DHTML widgets on 
>>legacy clients that are still bound to be around for many years. As a 
>>result, if you make it nigh impossible for them to use their widgets as 
>>a fallback, they're just going to continue using them because they know 
>>they'll still work on WF2 user agents.
> 
> 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.

    By contrast, <idate> can be used to prevent execution of a script:

| <idate name="date1">
|  <script type="text/javascript" src="datepicker.js">
| </idate>

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

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

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

>>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. If WF2 
was to become popular enough for Microsoft to consider implementation, 
the 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. 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.

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

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


From mattraymond at earthlink.net  Thu Feb  3 09:20:08 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 03 Feb 2005 12:20:08 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
Message-ID: <42025D48.4020709@earthlink.net>

Ian Hickson wrote:
> On Mon, 31 Jan 2005, James Graham wrote:
> 
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>>* It is easy for authors to not include any fallback, which makes it 
>>>worse than the <input> equivalent.
>>
>>In general, it is easy to make WF2 pages incompatible with older 
>>browsers.
> 
> Granted, but at least it's not the default.

    When using the inheritance feature of <idate>, incompatibility isn't 
the default either, and the only situation in which you can't use 
inheritance is when the first child control doesn't submit a complete 
date. You're arguing a "Rogue Webmaster" scenario.

>>>* The fallback and non-fallback controls have different names.
>>
>>Why is that a problem? Would it not be a simple if construct on the 
>>server side to deal with the two cases?
> 
> Having two different forms (as opposed to one form with just better 
> behaviour in newer UAs) is something that the current WF2 design has, by 
> and large, been striving for.

    I know has support for having multiple forms use the same controls, 
but what does that have to do with multiple controls being used for the 
same field?

>>>    2. <select> controls, which do not need to be replaced at all,
>>
>>If that's really true, then all the date types seem a little pointless. 
>>I thought that one of the advantages of the WF2 controls was allowing 
>>sites to present a consistent, OS-specific interface to form controls. 
>>If multiple select controls are as good a solution, there seems little 
>>point in implementing or using WF2.
> 
> Indeed. Three <select>s are reasonably good UI, although not as good as 
> type="date" on a supporting UA. While WF2 UAs are not in the majority, 
> there's not really a huge advantage to using the new types. (This applies 
> to <idate> et all as well, by the way.)

    Are you arguing against the use of <idate> or against the use of 
<input type="date">?  Most dates are entered via the three <select> 
scenario. Therefore, if there's a compelling reason to use <input> in 
those cases, then <idate> is even more compelling.

> Similarly, while XHTML is not supported in the majority of UAs, there's 
> not really any reason to use XHTML. That doesn't mean that XHTML is bad, 
> indeed, XHTML (and especially the ability to create compound documents by 
> mixing namespaces _with_ XHTML) is great. But there's no reason to rush 
> off and use XHTML in the meantime.

    I fail to see how this argument supports the use of <input 
type="date"> and doesn't support the use of <idate>.

> The difference is that if you _do_ want to use type="date", you can do so, 
> and legacy UAs will still work (albeit not as user-friendlyly).

   Same is true for <idate>, unless--EGADS!--Not the Rogue Webmaster!!!

 > With
> XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have to be 
> all-or-nothing, but authors are likely to take the easy route and thus not 
> provide any fallback content. (Just look at how many authors provide good 
> fallback content for images.)

    The difference here is that text-base browsers, so far as I know, 
where NEVER the most popular type of browser, so there was little 
incentive for fallback. Not to mention the fact that IE corrupted the 
meaning of the |alt| attribute by using it for tooltips...

>>>    3. Complex JS widgets, for which declarative fallback is not needed.
>>
>>Why not? If one is replacing a javascript control with a WF2 control, 
>>one can improve the accessibility of one's page further by providing 
>>simple controls for legacy clients (this would be equivalant to say, 
>>producing a CSS based design and allowing old browsers to recieve 
>>unstyled content v using a table based design and blocking old browsers 
>>entirely).
> 
> I said _declarative_ fallback was not needed. If you're using JS, you can 
> easily implement the fallback yourself using JS.

    The <idate> element doesn't need JS at all. You're requiring 
webmasters to either learn scripting for legacy content, or depend on 
his Javascript programmer buddy to do the work for him.

>>>...not to mention the extra complexity and the implementation 
>>>difficulty compared to just using a new "type".
>>
>>Really? Obviously you're much more familiar with the browser engines 
>>than I am but I'm not sure that this is obviously difficult to 
>>implement. At least not obviously a lot more difficult than WF2 datetime 
>>controls are anyway. Is there something specific that browsers will 
>>struggle to cope with?
> 
> Nothing specific. Just every little added bit of complexity. I'm already 
> getting requests from implementors to drop the entire repetition model, 
> and to massively simplify the validity stuff, etc. And those aren't 
> particularly hard to implement.

    The repetition model is MORE complex than <idate>. Besides, isn't 
this what the implementation phase is for? Isn't the who point of the 
implementation phase to find out what people will actually implement and 
adjust the draft accordingly? Stick <idate> in, give the draft one more 
call before the implementation phase, and if people hate it, take it out 
before the implementation phase, or if people like it, but it's too hard 
to implement, it'll get dropped in the implementation phase.


From ian at hixie.ch  Thu Feb  3 09:23:43 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 17:23:43 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42024E87.4030505@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
>
> Since IRI is now a RFC, shouldn't Web Forms use that term instead of 
> URI?
> 
> (For example, in section 2.12. I guess once UAs start supporting IRIs 
> you want a list of IRIs there, not just URIs.)

I've already updated all the cases that really matter. For the most part 
I'd like to just stick to calling things URIs since otherwise people will 
just get more and more confused (most people still think they're URLs...).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Feb  3 09:24:29 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 17:24:29 +0000 (UTC)
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <42024F83.4020904@annevankesteren.nl>
References: <42024F83.4020904@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
>
> I think Web Forms 2 should refer to a dated version of HTML 4.01 (for 
> example section 2.13), not to the latest version since there is a very 
> small chance that the definition might change eventually.

Why wouldn't we want WF2 to track changes in HTML4?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Thu Feb  3 09:34:32 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 18:34:32 +0100
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>
References: <42024F83.4020904@annevankesteren.nl>
	<Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>
Message-ID: <420260A8.2070008@annevankesteren.nl>

Ian Hickson wrote:
> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> 
>> I think Web Forms 2 should refer to a dated version of HTML 4.01 
>> (for example section 2.13), not to the latest version since there 
>> is a very small chance that the definition might change eventually.
>
> Why wouldn't we want WF2 to track changes in HTML4?

Because the draft someone implements might not be stable in such cases.

Once HTML4 updates, WF2 could get an update of its own and match the 
changes in other drafts.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From fora at annevankesteren.nl  Thu Feb  3 09:42:48 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 18:42:48 +0100
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
Message-ID: <42026298.7020106@annevankesteren.nl>

Ian Hickson wrote:
> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> 
>> Since IRI is now a RFC, shouldn't Web Forms use that term instead 
>> of URI?
>> 
>> (For example, in section 2.12. I guess once UAs start supporting 
>> IRIs you want a list of IRIs there, not just URIs.)
> 
> I've already updated all the cases that really matter. For the most 
> part I'd like to just stick to calling things URIs since otherwise 
> people will just get more and more confused (most people still think
> they're URLs...).

Does that matter for a specification?

If you do it, you might want to add a line somewhere that URI and IRI
are used interchangeable.

Also, I think WF2 should refer to RFC3986 instead of RFC1738 since the
former updates the latter. RFC3986 is an internet standard and obsoletes
various other documents as well.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From jg307 at cam.ac.uk  Thu Feb  3 09:44:19 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Thu, 03 Feb 2005 17:44:19 +0000
Subject: [whatwg] Re: several messages
In-Reply-To: <42025D48.4020709@earthlink.net>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net>
Message-ID: <420262F3.7000008@cam.ac.uk>

Matthew Raymond wrote:

> Ian Hickson wrote:
>
>> On Mon, 31 Jan 2005, James Graham wrote:
>>
>>>> It has problems, as mentioned elsewhere in the thread:
>>>>
>>>> * It is easy for authors to not include any fallback, which makes 
>>>> it worse than the <input> equivalent.
>>>
>>>
>>> In general, it is easy to make WF2 pages incompatible with older 
>>> browsers.
>>
>>
>> Granted, but at least it's not the default.
>
>
>    When using the inheritance feature of <idate>, incompatibility 
> isn't the default either, and the only situation in which you can't 
> use inheritance is when the first child control doesn't submit a 
> complete date. You're arguing a "Rogue Webmaster" scenario.

To be clear, my adaptation of this model did not include any such 
inheritance (for implementation simplicity). Having said that I don't 
think that requiring authors to explicitly provide fallback content is 
such a bad thing (at least, not worse than the limited fallback options 
offered by input). But more on that later.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs



From ian at hixie.ch  Thu Feb  3 10:02:56 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 18:02:56 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42025631.7060004@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>

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.   `._.-(,_..'--(,_..'`-.;.'


From mattraymond at earthlink.net  Thu Feb  3 10:03:28 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 03 Feb 2005 13:03:28 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <420262F3.7000008@cam.ac.uk>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net> <420262F3.7000008@cam.ac.uk>
Message-ID: <42026770.3070205@earthlink.net>

James Graham wrote:
> Matthew Raymond wrote:
>>   When using the inheritance feature of <idate>, incompatibility 
>>isn't the default either, and the only situation in which you can't 
>>use inheritance is when the first child control doesn't submit a 
>>complete date. You're arguing a "Rogue Webmaster" scenario.
> 
> To be clear, my adaptation of this model did not include any such 
> inheritance (for implementation simplicity). Having said that I don't 
> think that requiring authors to explicitly provide fallback content is 
> such a bad thing (at least, not worse than the limited fallback options 
> offered by input). But more on that later.

    I could be convinced to drop inheritance if it's shown that it 
creates significant implementation problems, but unless someone can 
clearly communicate the problems involved, I still believe any potential 
feature removal should occur during the implementation phase of the spec.

    On a slightly unrelated note, I just realized a short time ago that 
the Microsoft sabotage scenario could happen just as easily if <idate>, 
or any part of it, were left out of the spec as it would be if it were 
included as-is. All Microsoft would have to do is implement flawed 
non-inheritance support (to mess up my version of <idate>), or implement 
my version in its entirety for either Ian's position or yours. So I 
don't think manipulating the markup is going to keep Microsoft from 
screwing us if it so desires...


From ian at hixie.ch  Thu Feb  3 10:05:16 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 3 Feb 2005 18:05:16 +0000 (UTC)
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <420260A8.2070008@annevankesteren.nl>
References: <42024F83.4020904@annevankesteren.nl>
	<Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>
	<420260A8.2070008@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502031803500.26895@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> Ian Hickson wrote:
> > On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> > 
> > > I think Web Forms 2 should refer to a dated version of HTML 4.01 (for
> > > example section 2.13), not to the latest version since there is a very
> > > small chance that the definition might change eventually.
> > 
> > Why wouldn't we want WF2 to track changes in HTML4?
> 
> Because the draft someone implements might not be stable in such cases.

The link points to the stable URI, so it would only be the stable 
version, not work in progress drafts, that was referenced.


> Once HTML4 updates, WF2 could get an update of its own and match the 
> changes in other drafts.

Unfortunately as the CSS working group is discovering with CSS 2.1, the 
theory of "we'll update the spec when our dependencies change" does not 
really work. (Many specs reference CSS2, and few have been updated to 
point to CSS2.1.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From fora at annevankesteren.nl  Thu Feb  3 10:12:19 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Thu, 03 Feb 2005 19:12:19 +0100
Subject: [whatwg] Link to dated version of HTML 4.01, not latest
In-Reply-To: <Pine.LNX.4.61.0502031803500.26895@dhalsim.dreamhost.com>
References: <42024F83.4020904@annevankesteren.nl>	<Pine.LNX.4.61.0502031724020.26895@dhalsim.dreamhost.com>	<420260A8.2070008@annevankesteren.nl>
	<Pine.LNX.4.61.0502031803500.26895@dhalsim.dreamhost.com>
Message-ID: <42026983.8020507@annevankesteren.nl>

Ian Hickson wrote:
> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> 
>> Ian Hickson wrote:
>> 
>>> On Thu, 3 Feb 2005, Anne van Kesteren wrote:
>>> 
>>> 
>>>> I think Web Forms 2 should refer to a dated version of HTML
>>>> 4.01 (for example section 2.13), not to the latest version
>>>> since there is a very small chance that the definition might
>>>> change eventually.
>>> 
>>> Why wouldn't we want WF2 to track changes in HTML4?
>> 
>> Because the draft someone implements might not be stable in such
>> cases.
>
> The link points to the stable URI, so it would only be the stable 
> version, not work in progress drafts, that was referenced.

Sorry, I meant that some might implement a stable version of WF2 which 
gets updated indirect by a stable update of HTML4.


>> Once HTML4 updates, WF2 could get an update of its own and match
>> the changes in other drafts.
> 
> Unfortunately as the CSS working group is discovering with CSS 2.1,
> the theory of "we'll update the spec when our dependencies change"
> does not really work. (Many specs reference CSS2, and few have been
> updated to point to CSS2.1.)

There are both advantages and disadvantages in that I suppose.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From ian at hixie.ch  Fri Feb  4 06:53:09 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Feb 2005 14:53:09 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42025D48.4020709@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502041413260.25632@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Matthew Raymond wrote:
> > > >
> > > > * It is easy for authors to not include any fallback, which makes 
> > > > it worse than the <input> equivalent.
> > > 
> > > In general, it is easy to make WF2 pages incompatible with older 
> > > browsers.
> > 
> > Granted, but at least it's not the default.
> 
> When using the inheritance feature of <idate> [...]

Doing so is not the default. The default is for there to be no contents in 
the <idate>.


> > > > * The fallback and non-fallback controls have different names.
> > > 
> > > Why is that a problem? Would it not be a simple if construct on the 
> > > server side to deal with the two cases?
> > 
> > Having two different forms (as opposed to one form with just better 
> > behaviour in newer UAs) is something that the current WF2 design has, 
> > by and large, been striving for.
> 
> I know has support for having multiple forms use the same controls, but 
> what does that have to do with multiple controls being used for the same 
> field?

Sorry, my sentence got very confused. What I meant to say was:

Having two different forms (as opposed to one form with just better 
behaviour in newer UAs) is something that the current WF2 design has, by 
and large, been striving _to avoid_.

By "two different forms" I meant two different sets of controls for the 
same submission, based on whether you are submitting from a legacy UA or a 
WF2 UA (I am not referring to multiple <form> elements).

For example, this:

   <form>
    <input type="foo" name="s">
   </form>

...vs:

   <form>
    <foo name="s">
     <input name="s1">
     <input name="s2">
    </foo>
   </form>

In the first, the submission will always be the same, for new UAs like old 
UAs. For the second, the old UAs will submit two different values and new 
UAs will submit just one.


> > > >    2. <select> controls, which do not need to be replaced at all,
> > > 
> > > If that's really true, then all the date types seem a little 
> > > pointless. I thought that one of the advantages of the WF2 controls 
> > > was allowing sites to present a consistent, OS-specific interface to 
> > > form controls. If multiple select controls are as good a solution, 
> > > there seems little point in implementing or using WF2.
> > 
> > Indeed. Three <select>s are reasonably good UI, although not as good 
> > as type="date" on a supporting UA. While WF2 UAs are not in the 
> > majority, there's not really a huge advantage to using the new types. 
> > (This applies to <idate> et all as well, by the way.)
> 
> Are you arguing against the use of <idate> or against the use of <input 
> type="date">?  Most dates are entered via the three <select> scenario. 
> Therefore, if there's a compelling reason to use <input> in those cases, 
> then <idate> is even more compelling.

There isn't a compelling reason to move away from three <select>s 
(whatever the replacement). There are reasons (better UI, better 
validation, more semantic) but at the end of the day, three <select>s 
perform quite adequately and are quite accessible. Moving from three 
<select>s to something new would mean either:

   * more complexity on the author side (two sets of controls which must
     be maintained togother) _and_ on the server side (two codepaths to 
     receive dates), or

   * less usable interface for users of legacy UAs.

Given that the advantages are quite small in both cases, I do not see why 
most authors would want to make the switch. Given that, it is logical to 
use the simplest possible solution in WF2, namely just a new type and 
nothing more.


> > The difference is that if you _do_ want to use type="date", you can do 
> > so, and legacy UAs will still work (albeit not as user-friendlyly).
> 
> Same is true for <idate>, unless--EGADS!--Not the Rogue Webmaster!!!

You seem to be downplaying the likelihood of Web authors being, as you 
say, "rogue". However, my experience with existing Web content strongly 
supports the view that most authors would fall into that category.


> > With XHTML, it's an all-or-nothing deal. With <idate>, it doesn't have 
> > to be all-or-nothing, but authors are likely to take the easy route 
> > and thus not provide any fallback content. (Just look at how many 
> > authors provide good fallback content for images.)
> 
> The difference here is that text-base browsers, so far as I know, where 
> NEVER the most popular type of browser, so there was little incentive 
> for fallback.

Image fallback is needed for a lot more than just text browsers: blind 
users, mobile users and users on dial-up connections (who have images 
disabled), search engines, etc.

And yet it is still inadequately catered for by authors.


> Not to mention the fact that IE corrupted the meaning of the |alt| 
> attribute by using it for tooltips...

This is another very good example of why we have to be _very_ wary of UA 
implementors when designing fallback mechanisms, by the way.


> > > > 3. Complex JS widgets, for which declarative fallback is not 
> > > > needed.
> > > 
> > > Why not? If one is replacing a javascript control with a WF2 
> > > control, one can improve the accessibility of one's page further by 
> > > providing simple controls for legacy clients (this would be 
> > > equivalant to say, producing a CSS based design and allowing old 
> > > browsers to recieve unstyled content v using a table based design 
> > > and blocking old browsers entirely).
> > 
> > I said _declarative_ fallback was not needed. If you're using JS, you 
> > can easily implement the fallback yourself using JS.
> 
> The <idate> element doesn't need JS at all. You're requiring webmasters 
> to either learn scripting for legacy content, or depend on his 
> Javascript programmer buddy to do the work for him.

Here, we're talking about a case where the author _already uses 
JavaScript_. So requiring JS is not a problem.


> > > > ...not to mention the extra complexity and the implementation 
> > > > difficulty compared to just using a new "type".
> > > 
> > > Really? Obviously you're much more familiar with the browser engines 
> > > than I am but I'm not sure that this is obviously difficult to 
> > > implement. At least not obviously a lot more difficult than WF2 
> > > datetime controls are anyway. Is there something specific that 
> > > browsers will struggle to cope with?
> > 
> > Nothing specific. Just every little added bit of complexity. I'm 
> > already getting requests from implementors to drop the entire 
> > repetition model, and to massively simplify the validity stuff, etc. 
> > And those aren't particularly hard to implement.
> 
> The repetition model is MORE complex than <idate>.

I beg to differ. The repetition model, to implement, requires very little 
except a few click event handlers and a modest DOM API. As far as I can 
tell implementing it is little more than translating the spec's text into 
C++ or whatever the UA is written in.

On the other hand, <idate> has element interdependencies. Change an 
attribute here, and something else has to change, etc. Move an element, 
and the entire validity of the control might change. Based on how UAs have 
screwed up this kind of thing before, I would say it is *significantly* 
harder to implement.


> Besides, isn't this what the implementation phase is for? Isn't the who 
> point of the implementation phase to find out what people will actually 
> implement and adjust the draft accordingly?

No. The implementation phase is to have people implement the spec. 
Ideally, without the spec changing at all, so that all implementations can 
then ship to consumers. If the implementation phase was guarenteed to 
result in the spec changing, then there would be no incentive in investing 
the scarce resources involved, since it would be risking that the code 
would have to be thrown out.


> Stick <idate> in, give the draft one more call before the implementation 
> phase, and if people hate it, take it out before the implementation 
> phase, or if people like it, but it's too hard to implement, it'll get 
> dropped in the implementation phase.

<idate> has at least as many problems as <input type="date">, and in my 
opinion the problems are worse on several fronts. I do not see it being 
worth adding to the spec, sorry.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Fri Feb  4 07:16:19 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Feb 2005 15:16:19 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42026298.7020106@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Anne van Kesteren wrote:
> > >
> > > Since IRI is now a RFC, shouldn't Web Forms use that term instead of 
> > > URI?
> > > 
> > > (For example, in section 2.12. I guess once UAs start supporting 
> > > IRIs you want a list of IRIs there, not just URIs.)
> > 
> > I've already updated all the cases that really matter. For the most 
> > part I'd like to just stick to calling things URIs since otherwise 
> > people will just get more and more confused (most people still think 
> > they're URLs...).
> 
> Does that matter for a specification?

Yes. :-)


> If you do it, you might want to add a line somewhere that URI and IRI 
> are used interchangeable.

Hm, could do.

Actually, I just went through the entire spec and made sure that every 
reference to URI is correct and every reference to IRI is correct. Let me 
know if you spot any cases that say URI when they should said IRI. I think 
they are all now correct, though.

(Also, if someone could look through section "5.6. Submitting the encoded 
form data set" and tell me which of the table cells in there aren't clear 
from a conformance point of view, that would be great. I can't see the 
wood for the trees in that section anymore.)


> Also, I think WF2 should refer to RFC3986 instead of RFC1738 since the 
> former updates the latter. RFC3986 is an internet standard and obsoletes 
> various other documents as well.

I'd updated all the relevant reference, I think. Did you see some I 
missed?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Fri Feb  4 07:20:18 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 4 Feb 2005 15:20:18 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42026770.3070205@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42025D48.4020709@earthlink.net> <420262F3.7000008@cam.ac.uk>
	<42026770.3070205@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502041518120.25632@dhalsim.dreamhost.com>

On Thu, 3 Feb 2005, Matthew Raymond wrote:
> 
> On a slightly unrelated note, I just realized a short time ago that the 
> Microsoft sabotage scenario could happen just as easily if <idate>, or 
> any part of it, were left out of the spec as it would be if it were 
> included as-is. All Microsoft would have to do is implement flawed 
> non-inheritance support (to mess up my version of <idate>), or implement 
> my version in its entirety for either Ian's position or yours. So I 
> don't think manipulating the markup is going to keep Microsoft from 
> screwing us if it so desires...

The odds of anyone intentionally "sabotaging" a standard or proposal in 
this way is basically zero, and not really worth any thought, IMHO.

As far as I am aware, every occurance of a "sabotage" in the Web world in 
the past 15 years has been due to misunderstandings, an accident, 
oversight, or plain stupidity, and none were intentional or malicious.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From steele at laszlosystems.com  Fri Feb  4 07:48:32 2005
From: steele at laszlosystems.com (Oliver Steele)
Date: Fri, 4 Feb 2005 10:48:32 -0500
Subject: [whatwg] drawing API
Message-ID: <82e5f4ef63edc67859055d6ceee3685e@laszlosystems.com>

Hello.  I'm new to the list, but I've looked over the archives and it 
looked like this was the right place to raise discuss this.  Apologies 
in advance if this is off topic.

I am involved with a proposal to add a procedural drawing API to the 
Laszlo RIA platform, a corporate-sponsored open source project hosted 
at http://openlaszlo.org.  We are planning to use, to the extent 
possible, a subset of that WHAT-WG graphics API 
<http://www.whatwg.org/specs/web-apps/current-work/#graphics>, for a 
variety of reasons described on the Drawing API proposal page 
<http://openlaszlo.org/wiki/Drawing_API>.

In looking over the drawing API, I found these names confusing:
   void quadraticCurveTo(in float cpx, in float cpy, in float x, in 
float y);
   void bezierCurveTo(in float cp1x, in float cp1y, in float cp2x, in 
float cp2y, in float x, in float y);
The reason is that (I assume) they both add bezier curves to the open 
path; but only one incorporates "bezier" in its name, and only one 
encodes the order of the bezier curve in its name: the names differ 
differ in that the first is "quadratic" and the second is "bezier", but 
the functionality differs in that the first is quadratic and the second 
is cubic.

A cursory scan of other modern graphics systems (Java2D, Cairo) 
indicates that they have a single curveTo() method, which takes 6 
parameters and specifies a cubic "bezier".  You can specify a quadratic 
"bezier" by using the same value for both control points. This is 
pretty inconvenient in my experience: specification of a quadratic 
bezier is actually a pretty common case.  (It's easier for programmers 
to specify; it's the common case in interactive drawing; and it's the 
only supported bezier order for some systems such as TrueType, the 
Flash rendering engine, and historical systems that have a fond place 
in my heart such as Quickdraw GX and the Alphamask Graphics Library.)

How about using a single variadic curveTo() method?:
   void curveTo(in float cpx, in float cpy, in float x, in float y); // 
quadratic bezier
   void curveTo(in float cp1x, in float cp1y, in float cp2x, in float 
cp2y, in float x, in float y); // cubic bezier
A JavaScript implementation of curveTo could distinguish these based on 
the value of arguments.length.

This would be the most convenient to users of the API, but I don't know 
what your conventions are on variadic methods and whether this has 
implications for non-JavaScript language bindings.  If this is 
unacceptable, what do you about changing the names to be parallel, and 
leaving it implicit that they're bezier's?  (I think all curveTo 
commands in modern vector graphics libraries are beziers.)
   void quadraticCurveTo(in float cpx, in float cpy, in float x, in 
float y);
   void cubicCurveTo(in float cp1x, in float cp1y, in float cp2x, in 
float cp2y, in float x, in float y);

Best,
Oliver

--
Oliver Steele
Chief Software Architect
Laszlo Systems, Inc.



From christoph.paeper at tu-clausthal.de  Fri Feb  4 08:30:33 2005
From: christoph.paeper at tu-clausthal.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Fri, 04 Feb 2005 17:30:33 +0100
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
Message-ID: <opslolg7jwofh7fl@crissov>

*Ian Hickson* <ian at hixie.ch>:
> On Mon, 31 Jan 2005, James Graham wrote:
>
>>>     2. <select> controls, which do not need to be replaced at all,
>>
>> If that's really true, then all the date types seem a little pointless.
>> I thought that one of the advantages of the WF2 controls was allowing
>> sites to present a consistent, OS-specific interface to form controls.
>> If multiple select controls are as good a solution, there seems little
>> point in implementing or using WF2.
>
> Indeed. Three <select>s are reasonably good UI,

They are easy for the programmer, but ask any usability expert: he will  
(perhaps even strongly) advice against them, because (alpha-)numerical  
input into /one/ field in ones accustomed format is much faster and  
easier. A (very) good online ticketing PoS date/time input thus has to  
understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" =  
"034" = "first Thursday in February", "next Thursday afternoon", "2nite",  
"asap" etc.p.p. (in an English speaking environment; defaulting to the  
next possible year, month, week, day, hour).

> although not as good as type="date" on a supporting UA.

Those calendar-datepickers, which are probably the expected GUI component,  
are also slower and usually not as flexible as a simple text string.  
Better than three selects at the client-side and easier to handle on the  
server-side, though.

> While WF2 UAs are not in the majority,
> there's not really a huge advantage to using the new types.

ACK, server-side intelligence is still the best. A scaled-down client-side  
version can help to avoid unnecessary requests.



From ian at hixie.ch  Mon Feb  7 06:28:16 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 14:28:16 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <opslolg7jwofh7fl@crissov>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
Message-ID: <Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>

On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
> > 
> > Indeed. Three <select>s are reasonably good UI,
> 
> They are easy for the programmer, but ask any usability expert: he will 
> (perhaps even strongly) advice against them, because (alpha-)numerical 
> input into /one/ field in ones accustomed format is much faster and 
> easier. A (very) good online ticketing PoS date/time input thus has to 
> understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" = 
> "034" = "first Thursday in February", "next Thursday afternoon", 
> "2nite", "asap" etc.p.p. (in an English speaking environment; defaulting 
> to the next possible year, month, week, day, hour).

And a mind-reading UI that can tell the user's intent without the user 
having to explicitly put it into words would presumably be even better.

Authors cannot be expected to implement everything you just described, 
especially because it is in fact impossible to determine the intent 
sometimes (for example, what date is 05/02/07?).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From fora at annevankesteren.nl  Mon Feb  7 07:03:17 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Mon, 07 Feb 2005 16:03:17 +0100
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
Message-ID: <42078335.6030705@annevankesteren.nl>

Ian Hickson wrote:
> Hm, could do.
> 
> Actually, I just went through the entire spec and made sure that 
> every reference to URI is correct and every reference to IRI is 
> correct. Let me know if you spot any cases that say URI when they 
> should said IRI. I think they are all now correct, though.

2.5. Extensions to existing attributes

Under 'maxlength': "Valid URIs and e-mail addresses in particular can
often be surprisingly long."

I guess that should be IRI since it refers to the value |type="uri"| can
have.


2.12. The datalist element and the list attribute

It could be that the UA has listed some IRIs as well though I may be
nitpicking here.


2.16. Extensions to the form element

Not sure about this. If it is an empty string, should it really be
relative to the base URI? I can remember a discussion in Bugzilla about
same-document references where there still isn't a conclusion about
this. (Among other things with regard to this.)

Or does this update the RFC in question?


6.1. Filling select elements

Why URI or IRI? IRI covers both. Same for other sections where this is
used. (See for another example 6.2.)


A. XHTML module definition

A lot of attribute can only contain URIs where it would make sense to
allow IRIs.


>> Also, I think WF2 should refer to RFC3986 instead of RFC1738 since 
>> the former updates the latter. RFC3986 is an internet standard and 
>> obsoletes various other documents as well.
> 
> I'd updated all the relevant reference, I think. Did you see some I 
> missed?

I was wondering why you were pointing to RFC1738 as well as pointing to
RFC3986. However, as you explained on IRC RFC3986 only updates the
specification it does not obsolete it.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From mattraymond at earthlink.net  Mon Feb  7 08:09:02 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 11:09:02 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
Message-ID: <4207929E.7090402@earthlink.net>

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.


From mattraymond at earthlink.net  Mon Feb  7 08:15:54 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 11:15:54 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
Message-ID: <4207943A.7050107@earthlink.net>

Ian Hickson wrote:
> On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
> 
>>>Indeed. Three <select>s are reasonably good UI,
>>
>>They are easy for the programmer, but ask any usability expert: he will 
>>(perhaps even strongly) advice against them, because (alpha-)numerical 
>>input into /one/ field in ones accustomed format is much faster and 
>>easier. A (very) good online ticketing PoS date/time input thus has to 
>>understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" = 
>>"034" = "first Thursday in February", "next Thursday afternoon", 
>>"2nite", "asap" etc.p.p. (in an English speaking environment; defaulting 
>>to the next possible year, month, week, day, hour).
> 
> And a mind-reading UI that can tell the user's intent without the user 
> having to explicitly put it into words would presumably be even better.
 >
> Authors cannot be expected to implement everything you just described, 
> especially because it is in fact impossible to determine the intent 
> sometimes (for example, what date is 05/02/07?).

    First of all, you need to apologize to Christoph for your sarcastic 
tone. It is inappropriate and unprofessional for the spokesman of WHATWG 
to be addressing a potential contributer in this manner.

    Second, you missed what he's trying to say. He's saying that people 
use the three select solution not because it's more usable, but because 
it's a pain to deal with input from a textbox. Webmasters will want to 
move to a datepicker because it provides better usability than the three 
<select> elements while offering similar usability to a textbox. 
However, they won't want the fallback to be a textbox because of the 
programming difficulties in specific situations. So the very solution 
that solves their usability problems, <input type="date">,  burns them 
in the legacy scenario.


From jim.ley at gmail.com  Mon Feb  7 08:18:29 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Mon, 7 Feb 2005 16:18:29 +0000
Subject: [whatwg] Re: several messages
In-Reply-To: <4207929E.7090402@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
	<4207929E.7090402@earthlink.net>
Message-ID: <851c8d31050207081850746a37@mail.gmail.com>

On Mon, 07 Feb 2005 11:09:02 -0500, Matthew Raymond
<mattraymond at earthlink.net> wrote:

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

It's also not a successful means of detection, it _DOES NOT_ detect
suppot for input type=date, and in the previous discussion (before I
gave up listing the flaws in the script, of which there are still
many) I mentioned the fact along with the some cases where it fails.

Please Ian, stop saying that script is perfect when it is so clearly
not.  It's obvious you've decided the input type=date stays, and as
you're the only person who has change control on the specification
your decision is final, the fact that no-one else supports you is
completely irrelevant, but please don't use that script to create
pretend justification of the degradability of input type=date.

Jim.


From mattraymond at earthlink.net  Mon Feb  7 08:19:20 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 11:19:20 -0500
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42078335.6030705@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>	<42026298.7020106@annevankesteren.nl>	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl>
Message-ID: <42079508.4090306@earthlink.net>

Anne van Kesteren wrote:
> 2.5. Extensions to existing attributes
> 
> Under 'maxlength': "Valid URIs and e-mail addresses in particular can
> often be surprisingly long."
> 
> I guess that should be IRI since it refers to the value |type="uri"| can
> have.

    Should that be |type="iri"|??? Perhaps we should have both, with 
"uri" being an alias.



From hsivonen at iki.fi  Mon Feb  7 08:47:46 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 7 Feb 2005 18:47:46 +0200
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42079508.4090306@earthlink.net>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl>
	<42079508.4090306@earthlink.net>
Message-ID: <5581891207a1c6391619906e9bf9df84@iki.fi>

On Feb 7, 2005, at 18:19, Matthew Raymond wrote:

> Should that be |type="iri"|??? Perhaps we should have both, with "uri" 
> being an alias.

Aliases are annoying from the implementation point of view. I once 
tried supporting attributes in no namespace and attributes in the 
namespace of the element at the same time. Not fun.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/



From jg307 at cam.ac.uk  Mon Feb  7 08:55:52 2005
From: jg307 at cam.ac.uk (James Graham)
Date: Mon, 07 Feb 2005 16:55:52 +0000
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
Message-ID: <42079D98.1000304@cam.ac.uk>

Ian Hickson wrote:

>On Mon, 31 Jan 2005, James Graham wrote:
>  
>
>>>It has problems, as mentioned elsewhere in the thread:
>>>
>>>* It is easy for authors to not include any fallback, which makes it 
>>>worse than the <input> equivalent.
>>>      
>>>
>>In general, it is easy to make WF2 pages incompatible with older 
>>browsers.
>>    
>>
>
>Granted, but at least it's not the default.
>  
>
True and I'll grant that such a situation is less than ideal. But given 
the high penetration of non-WF2 browsers, it is unlikely that anyone 
will be producing WF2-only content for some considerable time to come. 
Comparisons with missing alt-text and with sites requiring javascript 
are rather misleading. Alt text suffers because graphical browsers have 
such high penetration that many designers believe that everyone will see 
their graphics (and at the 98 or 99% level, they are probably right). 
Good alt text is also *very* hard (and sometimes impossible) to write 
since one has to replace the often complex content of a picture with a 
few words. There is also the historic problem of alt-text-as-tooltips 
which produced significant confusion as to the point of alt text. With 
WF2 date types, none of these points apply.
Javascript is also a poor comparison since javascript allows 
fundamentally new features to be implemented by the website compared to 
those allowed with pure markup. This means it is often difficult for 
designers to envision how their carfully designed interaction model for 
a site should work without the extra scripting features. Then since the 
javascript-enabled population is currently a significant majority of web 
users.

>>>* The fallback and non-fallback controls have different names.
>>>      
>>>
>>Why is that a problem? Would it not be a simple if construct on the 
>>server side to deal with the two cases?
>>    
>>
>
>Having two different forms (as opposed to one form with just better 
>behaviour in newer UAs) is something that the current WF2 design has, by 
>and large, been striving for.
>  
>
Which is easy to achieve when the WF2 control is well represented as a 
single HTML4 control. There seems to be some agreement that this isn't 
the case for date controls (single textboxes are much harder than 
necessary to use). It seems a shame to sacrifice a useful feature for a 
design ideal that is of limited practical benefit.

>
>  
>
>>>    2. <select> controls, which do not need to be replaced at all,
>>>      
>>>
>>If that's really true, then all the date types seem a little pointless. 
>>I thought that one of the advantages of the WF2 controls was allowing 
>>sites to present a consistent, OS-specific interface to form controls. 
>>If multiple select controls are as good a solution, there seems little 
>>point in implementing or using WF2.
>>    
>>
>
>Indeed. Three <select>s are reasonably good UI, although not as good as 
>type="date" on a supporting UA. While WF2 UAs are not in the majority, 
>there's not really a huge advantage to using the new types. (This applies 
>to <idate> et all as well, by the way.)
>  
>
So are we planning to suggest that people not use the new date types 
until the uptake of WF2 reaches some magic value (what value?). I think 
taking the position that people should hold off using new features until 
they are supported everywhere rather diminishes the point of having 
backward compatibility, considering the extra trauma that specifying a 
backward compatible syntax for everything creates. It also ignores the 
feedback between users and UA authors. Opera are implementing 
XmlHttpRequest as a direct result of a site (GMail) using a feature that 
they didn't support. Mozilla dropped MNG because it wasn't being used 
anywhere (if MNG was used on even 1% of websites, the codesize issue 
would never have come up). One can't simply wait on all browser makers 
to implement something and then certify it as OK for general use. One 
needs actual adoption on the real web to force browser makers to 
implement something.

Given that the new date types will produce a significant improvement in 
UI, I want every site to be using them as soon as possible - long before 
WF2 browsers have 99% of the market. If they're designed in such a way 
that the fallback content is a much worse UI than whatever those sites 
are using at the moment, that won't happen and browser makers will be 
much slower to implement the types at-all.

-- 
"But if science you say still sounds too deep,
Just do what Beaker does, just shrug and 'Meep!'"

-- Dr. Bunsen Honeydew & Beaker of Muppet Labs



From ian at hixie.ch  Mon Feb  7 08:59:19 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 16:59:19 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42078335.6030705@annevankesteren.nl>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl>
Message-ID: <Pine.LNX.4.61.0502071655070.24987@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, Anne van Kesteren wrote:
> > 
> > Actually, I just went through the entire spec and made sure that every 
> > reference to URI is correct and every reference to IRI is correct. Let 
> > me know if you spot any cases that say URI when they should said IRI. 
> > I think they are all now correct, though.
> 
> 2.5. Extensions to existing attributes
> 
> Under 'maxlength': "Valid URIs and e-mail addresses in particular can 
> often be surprisingly long."
> 
> I guess that should be IRI since it refers to the value |type="uri"| can 
> have.

I left that one because the term "URI" is more likely to be understood 
than "IRI", and that sentence is aimed at explaining a conformance 
criteria to authors. (Note that that sentence is not itself a conformance 
criteria but a statement.)


> 2.12. The datalist element and the list attribute
> 
> It could be that the UA has listed some IRIs as well though I may be
> nitpicking here.

Again, the occurances here are either in explanatory text or in examples, 
which are themselves non-normative by definition.


> 2.16. Extensions to the form element
> 
> Not sure about this. If it is an empty string, should it really be
> relative to the base URI? I can remember a discussion in Bugzilla about
> same-document references where there still isn't a conclusion about
> this. (Among other things with regard to this.)
> 
> Or does this update the RFC in question?

The Bugzilla discussion to which you refer was regarding fragment 
identifiers; there are none in this case.


> 6.1. Filling select elements
> 
> Why "URI or IRI"? IRI covers both. Same for other sections where this is 
> used. (See for another example 6.2.)

Again, because the term "URI" is much more likely to be understood than 
"IRI". Mentioning both means that the conformance criteria is exact while 
still making the intent clear.


> A. XHTML module definition
> 
> A lot of attribute can only contain URIs where it would make sense to
> allow IRIs.

AIUI, we are restricted by XHTML M12N here.


> > > Also, I think WF2 should refer to RFC3986 instead of RFC1738 since 
> > > the former updates the latter. RFC3986 is an internet standard and 
> > > obsoletes various other documents as well.
> > 
> > I'd updated all the relevant reference, I think. Did you see some I 
> > missed?
> 
> I was wondering why you were pointing to RFC1738 as well as pointing to 
> RFC3986. However, as you explained on IRC RFC3986 only updates the 
> specification it does not obsolete it.

Indeed.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From olav at olav.dk  Mon Feb  7 09:50:07 2005
From: olav at olav.dk (=?ISO-8859-1?Q?Olav_Junker_Kj=E6r?=)
Date: Mon, 07 Feb 2005 18:50:07 +0100
Subject: [whatwg] Web Forms 2 stable draft draft
In-Reply-To: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>
Message-ID: <4207AA4F.5050704@olav.dk>

You write:
 > The model used by the validity  DOM attribute is not very clean, and
 > may deserve to be replaced with something that has been thought
 > through with more care

Perhaps the bit field interface could be left out. The only thing that 
can't be done through the properties, is easily checking if the field is 
valid or not, like:
   if (field1.validity) ...
This could be supported by having the validity attribute return null 
when the field is valid. The ValidityState object would then alway be 
the description of an error.
This may be a bad idea though, since code like:

   if (field1.validity.isPatternMismatch) ...

would generate an error when the field is valid.
A better solution would perhaps be to add an attribute, "isValid" to 
ValidationState. So you could write:

  if (field1.validity.isValid) ...

Only problem is that the naming seems a bit strange. "validityState" 
would be clearer than "validity", but also a bit more cumbersome.

Anyway, it seems a bit redundant to support both the bit field and 
property interfaces.

regards
Olav Junker Kj?r


From ian at hixie.ch  Mon Feb  7 14:35:46 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 22:35:46 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <4207929E.7090402@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FF0B32.8050604@earthlink.net>
	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>
	<42025631.7060004@earthlink.net>
	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>
	<4207929E.7090402@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>

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.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Mon Feb  7 14:44:55 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 22:44:55 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <4207943A.7050107@earthlink.net>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, Matthew Raymond wrote:
> Ian Hickson wrote:
> > On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
> > 
> > > > Indeed. Three <select>s are reasonably good UI,
> > > 
> > > They are easy for the programmer, but ask any usability expert: he 
> > > will (perhaps even strongly) advice against them, because 
> > > (alpha-)numerical input into /one/ field in ones accustomed format 
> > > is much faster and easier. A (very) good online ticketing PoS 
> > > date/time input thus has to understand "2/3" = "3.2." = "Feb 3rd" = 
> > > "3 Feb." = "02-03" = "w05-4" = "034" = "first Thursday in February", 
> > > "next Thursday afternoon", "2nite", "asap" etc.p.p. (in an English 
> > > speaking environment; defaulting to the next possible year, month, 
> > > week, day, hour).
> > 
> > And a mind-reading UI that can tell the user's intent without the user 
> > having to explicitly put it into words would presumably be even 
> > better.
> >
> > Authors cannot be expected to implement everything you just described, 
> > especially because it is in fact impossible to determine the intent 
> > sometimes (for example, what date is 05/02/07?).
> 
> First of all, you need to apologize to Christoph for your sarcastic tone.

Apologies.


> Second, you missed what he's trying to say. He's saying that people use 
> the three select solution not because it's more usable, but because it's 
> a pain to deal with input from a textbox.

That certainly isn't what I understood from his message.

I disagree that that is the reason <select>s are used for date input.

I disagree with the assertion that text input is more accessible and 
usable than three <select>s. Indeed, if it was, I wouldn't be worried 
about the fact that type="date" has poor fallback, since by that argument 
it would in fact have good fallback.

A simple text box is IMHO hard to use because, without a suggested format, 
the user has no guidance as to what to enter. Since users have been 
conditioned to only provide data in the Correct Format, the user is more 
likely to be confused by an empty text field than by three clear drop-down 
widgets containing what are obviously days, months and years.


> Webmasters will want to move to a datepicker because it provides better 
> usability than the three <select> elements while offering similar 
> usability to a textbox.
> However, they won't want the fallback to be a textbox because of the 
> programming difficulties in specific situations.

Handling free-form input for dates isn't that hard if you are willing to 
reject anything that doesn't match a given format. You can even suggest 
one format and accept a number of other popular formats, assuming that you 
only accept unambiguous formats.

It is extremely hard to do, however, if you are not willing to reject 
data, since then you have to be able to determine the meaning of dates 
like 05-02-07 (this is an actual date).


> So the very solution that solves their usability problems, <input 
> type="date">, burns them in the legacy scenario.

I agree that <input type="date"> has a poor fallback story. I just haven't 
seen any proposals that have fewer problems.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Mon Feb  7 14:47:48 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 22:47:48 +0000 (UTC)
Subject: [whatwg] Use IRI instead of URI
In-Reply-To: <42079508.4090306@earthlink.net>
References: <42024E87.4030505@annevankesteren.nl>
	<Pine.LNX.4.61.0502031722420.26895@dhalsim.dreamhost.com>
	<42026298.7020106@annevankesteren.nl>
	<Pine.LNX.4.61.0502041453150.25632@dhalsim.dreamhost.com>
	<42078335.6030705@annevankesteren.nl> <42079508.4090306@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502072245230.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, Matthew Raymond wrote:
> Anne van Kesteren wrote:
> > 2.5. Extensions to existing attributes
> > 
> > Under 'maxlength': "Valid URIs and e-mail addresses in particular can
> > often be surprisingly long."
> > 
> > I guess that should be IRI since it refers to the value |type="uri"| can
> > have.
> 
> Should that be |type="iri"|??? Perhaps we should have both, with "uri" 
> being an alias.

I believe type="uri" would be a lot easier for authors to understand. I 
generally would suggest we stay away from aliases unless we have very 
specific needs for them, because they are an implementation nightmare 
(you have to deal with obscure problems like "what does the DOM |type| 
attribute return?" and "how do you canonicalise the document?").

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From gkilwein at fbsdata.com  Mon Feb  7 15:03:40 2005
From: gkilwein at fbsdata.com (Greg Kilwein)
Date: Mon, 07 Feb 2005 17:03:40 -0600
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>
	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>
Message-ID: <4207F3CC.9070508@fbsdata.com>


>The problems with what I understand of your proposal are:
>
>[snip]
> * Fallback needs author involvement
>    - easiest to simply not support legacy
>    - server typically needs to handle different names for controls,
>      not just different format
>
I'll add one more problem - the author cannot easily test the fallback 
content in the UA of <idate/> if the author doesn't have a legacy UA 
available.  If the author can't easily test it, the odds of the fallback 
content being missing or broken are higher.

Greg



From ian at hixie.ch  Mon Feb  7 15:15:26 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 23:15:26 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <42079D98.1000304@cam.ac.uk>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<42079D98.1000304@cam.ac.uk>
Message-ID: <Pine.LNX.4.61.0502072248470.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, James Graham wrote:
>
> True and I'll grant that such a situation is less than ideal. But given 
> the high penetration of non-WF2 browsers, it is unlikely that anyone 
> will be producing WF2-only content for some considerable time to come. 

Sure. But when they do, we don't want them to be encouraged to drop 
support for the then-minority browsers.


> > > > * The fallback and non-fallback controls have different names.
> > >
> > > Why is that a problem? Would it not be a simple if construct on the 
> > > server side to deal with the two cases?
> > 
> > Having two different forms (as opposed to one form with just better 
> > behaviour in newer UAs) is something that the current WF2 design has, 
> > by and large, been striving for
>
> Which is easy to achieve when the WF2 control is well represented as a 
> single HTML4 control. There seems to be some agreement that this isn't 
> the case for date controls (single textboxes are much harder than 
> necessary to use). It seems a shame to sacrifice a useful feature for a 
> design ideal that is of limited practical benefit.

I don't think it's that limited. In fact I think that given the knock-on 
effects (different names on the server, different code paths in scripts, 
multiple variants to test, etc) it is quite important, at least as 
important as having a good legacy fallback story.


> > Indeed. Three <select>s are reasonably good UI, although not as good 
> > as type="date" on a supporting UA. While WF2 UAs are not in the 
> > majority, there's not really a huge advantage to using the new types. 
> > (This applies to <idate> et all as well, by the way.)
> 
> So are we planning to suggest that people not use the new date types 
> until the uptake of WF2 reaches some magic value (what value?). I think 
> taking the position that people should hold off using new features until 
> they are supported everywhere rather diminishes the point of having 
> backward compatibility, considering the extra trauma that specifying a 
> backward compatible syntax for everything creates.

It depends what people would be using instead. If they would just be using 
a single text field (as many are) then using type="date" gives an 
immediate benefit. Similarly, if they are currently using complex 
JavaScript, then it makes sense to use type="date" and then have some 
script that detects whether or not that is supported (by comparing the 
input element's |type| DOM attribute to the value "date") and if it isn't, 
replacing it with what is being used today.

And other types -- type="time", "number", "uri", etc -- make sense today 
as well, with or without UA support. It's only really "date", "datetime", 
"datetime-local", and "range" that have poor fallback.


> It also ignores the feedback between users and UA authors. Opera are 
> implementing XmlHttpRequest as a direct result of a site (GMail) using a 
> feature that they didn't support.

But DOM3 Load and Save was implemented first, despite that not being used 
anywhere.


> Mozilla dropped MNG because it wasn't being used anywhere (if MNG was 
> used on even 1% of websites, the codesize issue would never have come 
> up).

The reasons for dropping MNG are far more complex than that.


> One can't simply wait on all browser makers to implement something and 
> then certify it as OK for general use. One needs actual adoption on the 
> real web to force browser makers to implement something.

Not always. Opera, Mozilla and Safari all support XHTML, but there's 
basically no real use of XHTML on the Web. Mozilla supports MathML, and 
there's even less MathML than XHTML. There's now an XForms plugin for 
Mozilla, and there's no XForms content.

Yet the same browsers don't support ActiveX, despite that being heavily 
used. Opera doesn't support XSLT, yet there is author demand for that 
(misguided as it may be).

In fact, I would say that in general, it is much more often the case that 
the UAs have to implement something before the authors use it. It's only 
when one UA is lagging behind on one particular feature that the authoring 
community can push for that UA to implement something (XmlHttpRequest 
being a good recent example here -- Opera was only forced to implement it 
because everyone else already had implemented it.)


> Given that the new date types will produce a significant improvement in 
> UI, I want every site to be using them as soon as possible - long before 
> WF2 browsers have 99% of the market. If they're designed in such a way 
> that the fallback content is a much worse UI than whatever those sites 
> are using at the moment, that won't happen and browser makers will be 
> much slower to implement the types at-all.

Since most of the new types do not have this problem, I do not think that 
you need worry.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From stuartp at gmail.com  Mon Feb  7 15:16:14 2005
From: stuartp at gmail.com (Stuart Parmenter)
Date: Mon, 7 Feb 2005 15:16:14 -0800
Subject: [whatwg] drawing API
In-Reply-To: <82e5f4ef63edc67859055d6ceee3685e@laszlosystems.com>
References: <82e5f4ef63edc67859055d6ceee3685e@laszlosystems.com>
Message-ID: <a8d4ef520502071516284b02c4@mail.gmail.com>

On Fri, 4 Feb 2005 10:48:32 -0500, Oliver Steele
<steele at laszlosystems.com> wrote:
> How about using a single variadic curveTo() method?:
>    void curveTo(in float cpx, in float cpy, in float x, in float y); //
> quadratic bezier
>    void curveTo(in float cp1x, in float cp1y, in float cp2x, in float
> cp2y, in float x, in float y); // cubic bezier
> A JavaScript implementation of curveTo could distinguish these based on
> the value of arguments.length.

Using varargs should be avoided in IDL if possible as it is a language
specific feature.  There are also people shipping with the above API
so I'd prefer to not see it change.  Cubic may have been a better name
than bezier for it, but I think it is minor.

stuart


From ian at hixie.ch  Mon Feb  7 15:20:49 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 7 Feb 2005 23:20:49 +0000 (UTC)
Subject: [whatwg] Web Forms 2 stable draft draft
In-Reply-To: <4207AA4F.5050704@olav.dk>
References: <Pine.LNX.4.61.0502031556220.30807@dhalsim.dreamhost.com>
	<4207AA4F.5050704@olav.dk>
Message-ID: <Pine.LNX.4.61.0502072315510.27753@dhalsim.dreamhost.com>

On Mon, 7 Feb 2005, [ISO-8859-1] Olav Junker Kj?r wrote:
> You write:
> > The model used by the validity  DOM attribute is not very clean, and
> > may deserve to be replaced with something that has been thought
> > through with more care
> 
> Perhaps the bit field interface could be left out.

Yeah, I'm considering it. My main reason not to just do it is that it 
would require _massive_ changes to the draft (everything is currently 
defined in terms of the bit masks, and the object is then defined in 
terms of that).


> A better solution would perhaps be to add an attribute, "isValid" to 
> ValidationState. So you could write:
> 
>  if (field1.validity.isValid) ...
> 
> Only problem is that the naming seems a bit strange. "validityState" 
> would be clearer than "validity", but also a bit more cumbersome.

That's pretty much the line of thought I had on the matter.


> Anyway, it seems a bit redundant to support both the bit field and 
> property interfaces.

I agree. Hence the comment in the status section. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From rimantas at gmail.com  Mon Feb  7 16:03:55 2005
From: rimantas at gmail.com (Rimantas Liubertas)
Date: Tue, 8 Feb 2005 02:03:55 +0200
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net> <41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
	<Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
Message-ID: <5ccfb3340502071603daa4931@mail.gmail.com>

<...>
Looks like Cristoph really does know this stuff (I mean usability),
and I am with him
on this one.

> I disagree that that is the reason <select>s are used for date input.
> 
> I disagree with the assertion that text input is more accessible and
> usable than three <select>s. Indeed, if it was, I wouldn't be worried
> about the fact that type="date" has poor fallback, since by that argument
> it would in fact have good fallback.

I have seen enough recommendations "use drop-down list to prevent
invalid date entries",
to believe, that this is main reason for using <select>.
As user I hate those triplets, they require too much manipulation and
I am afraid even to think how does it feel for someone with motoric
disabilities.

To enter some date you must: Click on the year drop-down. Scroll to
the right item. Click on it (and be sure not to miss). Repeat for the
month. Repeat for the day.
I am unfortunate to be born at the end of the year so I almost always
forced to scroll those lists. Text field does not require any
jumping/tabbing/scrolling/clicking.

> A simple text box is IMHO hard to use because, without a suggested format,
> the user has no guidance as to what to enter. Since users have been
> conditioned to only provide data in the Correct Format, the user is more
> likely to be confused by an empty text field than by three clear drop-down
> widgets containing what are obviously days, months and years.

User obviously does know what date he want to enter, so why to be
afraid of text box?
What IS confusing is to guess which is the Correct Format. There is no
de facto standard
on this, so forcing some format on the user will break the main
usability principle: "don't make me think" (or do not make me feel
stupid). Hints like DD-MM-/YYYY (and especially MM/DD/YY ones) are not
of much help, because you still have to decipher and parse them in
your head (that is - think).
 
> > Webmasters will want to move to a datepicker because it provides better
> > usability than the three <select> elements while offering similar
> > usability to a textbox.
> > However, they won't want the fallback to be a textbox because of the
> > programming difficulties in specific situations.
> 
> Handling free-form input for dates isn't that hard if you are willing to
> reject anything that doesn't match a given format. You can even suggest
> one format and accept a number of other popular formats, assuming that you
> only accept unambiguous formats.

To quote Donald Norman (http://www.jnd.org/GoodDesign.html):
---
Hurrah for Microsoft! Too many companies force you to enter dates in
their preferred format (and often they only tell you after you do it
wrong. In Outlook calendar, you can type almost anything, and it is
interpreted properly. For example, "tomorrow," "day after tomorrow,"
"next day," Wednesday," Wed." Oct. 24, 24 Oct, 14/10, 10/14, etc.
Kudos to Microsoft
---
 
> It is extremely hard to do, however, if you are not willing to reject
> data, since then you have to be able to determine the meaning of dates
> like 05-02-07 (this is an actual date).

Cristoph has suggested how to deal with this: next possible date,
context depended, of course.

If you buy a ticket to the cinema online, if would be 2005-02-07,
cause you cannot buy tickets to the cinema in year 2002, or 2007,
2005-07-02 does not make much sense either.
Sure, there will be tough cases, but "probability vs. possibility"
principle still does apply.

>From the usability point of view my vote would be text box with
capabilities which Norman describes (so you can just type 'tonight')
and date-picker component beside.(like
http://www.dynarch.com/demos/jscalendar/).

Regards,
Rimantas
--
http://rimantas.com/


From ian at hixie.ch  Mon Feb  7 16:40:48 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 8 Feb 2005 00:40:48 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <5ccfb3340502071603daa4931@mail.gmail.com>
References: <41F659E0.1040709@earthlink.net> <41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
	<Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
	<5ccfb3340502071603daa4931@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0502080018000.27753@dhalsim.dreamhost.com>

On Tue, 8 Feb 2005, Rimantas Liubertas wrote:
> 
> To enter some date you must: Click on the year drop-down. Scroll to the 
> right item. Click on it (and be sure not to miss). Repeat for the month. 
> Repeat for the day.

(Just FYI, you can actually use the keyboard as well: click the first 
control, then start typing, then press tab, type, tab, type. Most UAs jump 
to the right item in the drop down when you start typing in one.)


> User obviously does know what date he want to enter, so why to be afraid 
> of text box? What IS confusing is to guess which is the Correct Format. 
> There is no de facto standard on this, so forcing some format on the 
> user will break the main usability principle: "don't make me think" (or 
> do not make me feel stupid). Hints like DD-MM-/YYYY (and especially 
> MM/DD/YY ones) are not of much help, because you still have to decipher 
> and parse them in your head (that is - think).

Well, if text fields represent good UI for date inputs, then the current 
fallback for <input type="date"> seems fine. People were arguing that it 
wasn't good UI, and that therefore it wasn't fine.


> > > Webmasters will want to move to a datepicker because it provides 
> > > better usability than the three <select> elements while offering 
> > > similar usability to a textbox. However, they won't want the 
> > > fallback to be a textbox because of the programming difficulties in 
> > > specific situations.
> > 
> > Handling free-form input for dates isn't that hard if you are willing 
> > to reject anything that doesn't match a given format. You can even 
> > suggest one format and accept a number of other popular formats, 
> > assuming that you only accept unambiguous formats.
> 
> To quote Donald Norman (http://www.jnd.org/GoodDesign.html):
> ---
> Hurrah for Microsoft! Too many companies force you to enter dates in
> their preferred format (and often they only tell you after you do it
> wrong. In Outlook calendar, you can type almost anything, and it is
> interpreted properly. For example, "tomorrow," "day after tomorrow,"
> "next day," Wednesday," Wed." Oct. 24, 24 Oct, 14/10, 10/14, etc.
> Kudos to Microsoft
> ---

Yeah, that's the best. It's also the hardest to implement! :-) But authors 
are certainly free to implement that, as are Web Browser implementors.


> From the usability point of view my vote would be text box with 
> capabilities which Norman describes (so you can just type 'tonight') and 
> date-picker component beside.(like 
> http://www.dynarch.com/demos/jscalendar/).

Yup, that's definitely an allowed way of implementing type="date".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From christoph.paeper at tu-clausthal.de  Mon Feb  7 18:40:19 2005
From: christoph.paeper at tu-clausthal.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Tue, 08 Feb 2005 03:40:19 +0100
Subject: [whatwg] Re: several messages
In-Reply-To: <4207943A.7050107@earthlink.net>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net>
Message-ID: <opsluxphesofh7fl@crissov>

*Matthew Raymond* <mattraymond at earthlink.net>:
> Ian Hickson wrote:
>> On Fri, 4 Feb 2005, [iso-8859-1] Christoph P?per wrote:
>>
>>>> Indeed. Three <select>s are reasonably good UI,
>>>
>>> They are easy for the programmer, but ask any usability expert: he  
>>> will (perhaps even strongly) advice against them, because  
>>> (alpha-)numerical input into /one/ field in ones accustomed format is  
>>> much faster and easier.

Three 'input' are yet another case, btw.

>>> A (very) good online ticketing PoS date/time input thus has to  
>>> understand "2/3" = "3.2." = "Feb 3rd" = "3 Feb." = "02-03" = "w05-4" =  
>>> "034" = "first Thursday in February", "next Thursday afternoon",  
>>> "2nite", "asap" etc.p.p. (in an English speaking environment; 
>>> defaulting to the next possible year, month, week, day, hour).
>>
>>  And a mind-reading UI that can tell the user's intent without the user  
>> having to explicitly put it into words would presumably be even better.

Sure, the perfect human machine input device. (I'm not sure I would want  
to use the output device using a reverse technology.) I actually expect to  
see such a thing in my lifetime, although towards the statistical end of  
it and not in every home.

>> Authors cannot be expected to implement everything you just described,

At least not everyone by himself, each time.

>> especially because it is in fact impossible to determine the intent  
>> sometimes (for example, what date is 05/02/07?).

If it's a form on an English site for an international audience requesting  
dates in the future, it's very likely May 2nd, 2007, because I would then  
consider USAn style the default when the separator is '/'. In other  
_contexts_ it might be just yesterday (in my timezone). Of course you  
don't accept ambiguous input data without the user having check and  
acknowledge it. '<input type="date">' can help to avoid that step, because  
the UA either offers a GUI that produces valid dates only or does the  
checking of textual input without the need for author action. The  
remaining problem would be HTML UAs.

> First of all, you need to apologize to Christoph for your sarcastic tone.

Actually, I don't mind.

>     Second, you missed what he's trying to say. He's saying that people  
> use the three select solution not because it's more usable, but because  
> it's a pain to deal with input from a textbox.

That is what I was saying.

> However, [webmasters] won't want the fallback to be a textbox because of  
> the programming difficulties in specific situations.

A simple 'text' 'input' has the advantage that it generates only one  
parameter to be handled by the server (and an optional client-side  
validation script), just like the 'date' 'input' does. The most basic  
handling would be to reject anything that is not an ISO?8601 conformant  
string (in the valid time frame), requiring the user to resubmit. From  
there on you can get as complex guessing as you want. Unambiguous, valid  
inputs are (silently) accepted, others rejected. Rejection on ambiguity  
should include showing the user the guessed likeliest value in an  
unambiguous format, so he hopefully just has to accept without further  
changing. The lesser advanced the guess script, the more important it is  
to inform the user of the expected input style.

 From the point of usability I wouldn't want '<input type="date">' to fall  
back to anything but '<input type="text">'. Neither from the point of  
marking-up and styling. In this case the programmer has to swallow the  
bitter pill, IMVHO. After all it's a recurring problem for which he has to  
find or write a solution only once (at least in theory).


From mattraymond at earthlink.net  Mon Feb  7 18:44:33 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 07 Feb 2005 21:44:33 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <4207F3CC.9070508@fbsdata.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>
	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>
	<4207F3CC.9070508@fbsdata.com>
Message-ID: <42082791.6070104@earthlink.net>

Greg Kilwein wrote:
> I'll add one more problem - the author cannot easily test the fallback 
> content in the UA of <idate/> if the author doesn't have a legacy UA 
> available.  If the author can't easily test it, the odds of the fallback 
> content being missing or broken are higher.

    Who are you kidding? To test <idate>, you just comment out the 
"<idate>" tags:

| <!-- <idate> -->
|  <input name="date1">
| <!-- </idate> -->

    Or you write the fallback and test it before adding the date-related 
WF2 markup.


From mattraymond at earthlink.net  Tue Feb  8 05:30:55 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 08 Feb 2005 08:30:55 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<opslolg7jwofh7fl@crissov>	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>	<4207943A.7050107@earthlink.net>
	<Pine.LNX.4.61.0502072235560.27753@dhalsim.dreamhost.com>
Message-ID: <4208BF0F.6080404@earthlink.net>

Ian Hickson wrote:
> On Mon, 7 Feb 2005, Matthew Raymond wrote:
>>First of all, you need to apologize to Christoph for your sarcastic tone.
> 
> Apologies.

   Thank you.

>>Second, you missed what he's trying to say. He's saying that people use 
>>the three select solution not because it's more usable, but because it's 
>>a pain to deal with input from a textbox.
> 
[Snip!]
> I disagree with the assertion that text input is more accessible and 
> usable than three <select>s. Indeed, if it was, I wouldn't be worried 
> about the fact that type="date" has poor fallback, since by that argument 
> it would in fact have good fallback.

    Not really. Three selects eliminates date formatting and parsing 
from the equation. That's why webmasters like it. It means that they 
don't have to think about how to handle the date input and the user 
doesn't have to know how to type the date in properly. It's a system 
with fewer points of failure.

> A simple text box is IMHO hard to use because, without a suggested format, 
> the user has no guidance as to what to enter.

    The vast majority of people using text boxes for date input provide 
formatting hints.

 > Since users have been
> conditioned to only provide data in the Correct Format, the user is more 
> likely to be confused by an empty text field than by three clear drop-down 
> widgets containing what are obviously days, months and years.

    This can be true under specific circumstances. It is not true for a 
date picker, which can use built-in browser format parsing (or enforce a 
native date format) and provide optional calendar selection. So you a 
date control give you both improved reliability and improved usability. 
It can even provide you with a combination of drop-down lists and text 
entry, if the user agent vendor so chooses.

> Handling free-form input for dates isn't that hard if you are willing to 
> reject anything that doesn't match a given format. You can even suggest 
> one format and accept a number of other popular formats, assuming that you 
> only accept unambiguous formats.

    Which, in the case of <input type="date">, requires more scripting 
than a legacy text box because you have to not only code for the 
different formats but you have to have scripting that implants 
formatting hints into the DOM.

> It is extremely hard to do, however, if you are not willing to reject 
> data, since then you have to be able to determine the meaning of dates 
> like 05-02-07 (this is an actual date).

    Which is exactly why you need formatting hints.


From mattraymond at earthlink.net  Tue Feb  8 06:22:42 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 08 Feb 2005 09:22:42 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <Pine.LNX.4.61.0502072248470.27753@dhalsim.dreamhost.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>
	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FE6E94.6070604@cam.ac.uk>	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>	<42079D98.1000304@cam.ac.uk>
	<Pine.LNX.4.61.0502072248470.27753@dhalsim.dreamhost.com>
Message-ID: <4208CB32.6020305@earthlink.net>

Ian Hickson wrote:
> On Mon, 7 Feb 2005, James Graham wrote:
>>True and I'll grant that such a situation is less than ideal. But given 
>>the high penetration of non-WF2 browsers, it is unlikely that anyone 
>>will be producing WF2-only content for some considerable time to come. 
> 
> Sure. But when they do, we don't want them to be encouraged to drop 
> support for the then-minority browsers.

    Why would we care??? ;)

>>>>>* The fallback and non-fallback controls have different names.
>>>>
>>>>Why is that a problem? Would it not be a simple if construct on the 
>>>>server side to deal with the two cases?
>>>
>>>Having two different forms (as opposed to one form with just better 
>>>behaviour in newer UAs) is something that the current WF2 design has, 
>>>by and large, been striving for
>>
>>Which is easy to achieve when the WF2 control is well represented as a 
>>single HTML4 control. There seems to be some agreement that this isn't 
>>the case for date controls (single textboxes are much harder than 
>>necessary to use). It seems a shame to sacrifice a useful feature for a 
>>design ideal that is of limited practical benefit.
> 
> I don't think it's that limited. In fact I think that given the knock-on 
> effects (different names on the server, different code paths in scripts, 
> multiple variants to test, etc) it is quite important, at least as 
> important as having a good legacy fallback story.

    It's far easier to get reliable scripting on the server than on a 
client, since the clients are varied and unlimited in number, whereas 
the server is not. Therefore, while there may be some small additional 
overhead in dealing with dates, it's far easier to handle that 
server-side than try to get the client to behave as you would like.

>>>Indeed. Three <select>s are reasonably good UI, although not as good 
>>>as type="date" on a supporting UA. While WF2 UAs are not in the 
>>>majority, there's not really a huge advantage to using the new types. 
>>>(This applies to <idate> et all as well, by the way.)
>>
>>So are we planning to suggest that people not use the new date types 
>>until the uptake of WF2 reaches some magic value (what value?). I think 
>>taking the position that people should hold off using new features until 
>>they are supported everywhere rather diminishes the point of having 
>>backward compatibility, considering the extra trauma that specifying a 
>>backward compatible syntax for everything creates.
> 
> It depends what people would be using instead. If they would just be using 
> a single text field (as many are) then using type="date" gives an 
> immediate benefit.

    Only if they solve the formatting problem, and only if their server 
is set up to handle ISO 8601 formatted date strings.

> Similarly, if they are currently using complex 
> JavaScript, then it makes sense to use type="date" and then have some 
> script that detects whether or not that is supported (by comparing the 
> input element's |type| DOM attribute to the value "date") and if it isn't, 
> replacing it with what is being used today.

    Or, assuming what they have fulfills their needs, they could stick 
with what they have and avoid adding the extra "code paths in scripts" 
on the client, which may have varying levels of Javascript compliance 
depending on the user agent.

> And other types -- type="time", "number", "uri", etc -- make sense today 
> as well, with or without UA support.  It's only really "date", "datetime",
> "datetime-local", and "range" that have poor fallback.

    Actually, "time" has several different formats, as does "week" and 
"month".

>>It also ignores the feedback between users and UA authors. Opera are 
>>implementing XmlHttpRequest as a direct result of a site (GMail) using a 
>>feature that they didn't support.
> 
> But DOM3 Load and Save was implemented first, despite that not being used 
> anywhere.

    I presume you mean on Opera, because I'm pretty sure Mozilla hasn't 
implemented it yet, although they implemented something with similar 
functionality.

>>Mozilla dropped MNG because it wasn't being used anywhere (if MNG was 
>>used on even 1% of websites, the codesize issue would never have come 
>>up).
> 
> The reasons for dropping MNG are far more complex than that.

    Not really. There were many suggestions on how to reduce the size of 
MING support in Mozilla, and they managed to reduce file size 
significantly and even produce a number of potential compromises that 
would have brought the file size down farther. Unfortunately, there 
seems to be a great deal of apathy with regards to all suggestions put 
forward, and I can only attribute that to the fact that there wasn't 
strong demand for MNG on the part of webmasters.

    Pity. Animations with JPEG compressed RGBA images are pretty cool.

>>One can't simply wait on all browser makers to implement something and 
>>then certify it as OK for general use. One needs actual adoption on the 
>>real web to force browser makers to implement something.
> 
> Not always. Opera, Mozilla and Safari all support XHTML, but there's 
> basically no real use of XHTML on the Web. Mozilla supports MathML, and 
> there's even less MathML than XHTML. There's now an XForms plugin for 
> Mozilla, and there's no XForms content.

    Minority browsers will always be inclined to add standards that 
aren't necessarily used on the majority of websites. It allows them 
greater access to niche markets, where minority software tend to do the 
best.

> Yet the same browsers don't support ActiveX, despite that being heavily 
> used.

    That's because Microsoft could simply make ActiveX a moving target 
like they did with a number of other products. Why add a technology that 
has a fundamentally flawed security model when you can't even ensure 
that Microsoft won't introduce a new incompatible version tomorrow?

 > Opera doesn't support XSLT, yet there is author demand for that
> (misguided as it may be).

    Due to the fact that Opera is designed to run on small devices, 
where supporting XSLT may not be desirable, Opera's somewhat of a 
special case.

> In fact, I would say that in general, it is much more often the case that 
> the UAs have to implement something before the authors use it.

    That's more the case with plug-ins, I would think.

 > It's only
> when one UA is lagging behind on one particular feature that the authoring 
> community can push for that UA to implement something (XmlHttpRequest 
> being a good recent example here -- Opera was only forced to implement it 
> because everyone else already had implemented it.)

    XmlHttpRequest, as I recall, was put into IE first. Because of IE's 
marketshare, all the other browser makers had to follow suit. It's not 
like people suddenly started using it when there was no browser out 
there supporting it.

>>Given that the new date types will produce a significant improvement in 
>>UI, I want every site to be using them as soon as possible - long before 
>>WF2 browsers have 99% of the market. If they're designed in such a way 
>>that the fallback content is a much worse UI than whatever those sites 
>>are using at the moment, that won't happen and browser makers will be 
>>much slower to implement the types at-all.
> 
> Since most of the new types do not have this problem, I do not think that 
> you need worry.

    I do. I can easily see a scenario where some of the WF2 stuff is 
added, but the date/time stuff is left out. For instance, why does one 
need <input type="date"> when one can do this:

| <label for="date1">Date: </label>
| <input type="text" id="date1" name="date1" pattern="[date format]">
| Format: [date format]

    The date gets formatted in WF2 clients in the same way is it's 
specified in the formatting hint, and it gets submitted to the server 
that way, so the webmaster doesn't have to change anything on the 
server. So I'd take a good, hard look at how you support legacy fallback...


From gkilwein at fbsdata.com  Tue Feb  8 06:36:29 2005
From: gkilwein at fbsdata.com (Greg Kilwein)
Date: Tue, 08 Feb 2005 08:36:29 -0600
Subject: [whatwg] Re: several messages
In-Reply-To: <42082791.6070104@earthlink.net>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>	<4207F3CC.9070508@fbsdata.com>
	<42082791.6070104@earthlink.net>
Message-ID: <4208CE6D.6020804@fbsdata.com>

Matthew Raymond wrote:

> Greg Kilwein wrote:
>
>> I'll add one more problem - the author cannot easily test the 
>> fallback content in the UA of <idate/> if the author doesn't have a 
>> legacy UA available.  If the author can't easily test it, the odds of 
>> the fallback content being missing or broken are higher.
>
>    Who are you kidding? To test <idate>, you just comment out the 
> "<idate>" tags:
>
> | <!-- <idate> -->
> |  <input name="date1">
> | <!-- </idate> -->
>
>    Or you write the fallback and test it before adding the 
> date-related WF2 markup.

The key is _easily_ test the fallback content.  For those authors who 
just don't care, there's no default fallback content, which I think is 
worse than none at all.  Besides, if the upper-end authors really want 
to replace <input type="date"> with three select boxes in legacy UAs, it 
can be done with some script without imposing some sort of 
comment/uncomment testing method on lower-end authors who just don't 
know or care.

Greg



From mattraymond at earthlink.net  Tue Feb  8 07:12:17 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 08 Feb 2005 10:12:17 -0500
Subject: [whatwg] Re: several messages
In-Reply-To: <4208CE6D.6020804@fbsdata.com>
References: <41F659E0.1040709@earthlink.net>	<851c8d3105012705432ecbf2d0@mail.gmail.com>	<41F91945.7060906@earthlink.net>	<851c8d31050127084967914a93@mail.gmail.com>	<41F925ED.8040400@earthlink.net>	<851c8d310501280256759eb54b@mail.gmail.com>	<41FA3EEF.1000206@earthlink.net>	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>	<41FA8B25.4020001@earthlink.net>	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>	<851c8d3105012902545fce5f43@mail.gmail.com>	<41FBCBB8.5030306@earthlink.net>	<41FE681F.60200@cam.ac.uk>	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>	<41FF0B32.8050604@earthlink.net>	<Pine.LNX.4.61.0502031337110.6666@dhalsim.dreamhost.com>	<42025631.7060004@earthlink.net>	<Pine.LNX.4.61.0502031724420.26895@dhalsim.dreamhost.com>	<4207929E.7090402@earthlink.net>	<Pine.LNX.4.61.0502071659250.24987@dhalsim.dreamhost.com>	<4207F3CC.9070508@fbsdata.com>
	<42082791.6070104@earthlink.net> <4208CE6D.6020804@fbsdata.com>
Message-ID: <4208D6D1.4070009@earthlink.net>

Greg Kilwein wrote:
> The key is _easily_ test the fallback content.  For those authors who 
> just don't care, there's no default fallback content, which I think is 
> worse than none at all.  Besides, if the upper-end authors really want 
> to replace <input type="date"> with three select boxes in legacy UAs, it 
> can be done with some script without imposing some sort of 
> comment/uncomment testing method on lower-end authors who just don't 
> know or care.

    The easy way to test pages for legacy fallback is to use a legacy 
UA, but you were specifically asking how someone would test markup in a 
_WF2_ user agent. In the end, the only way to know for sure that 
something degrades gracefully on a legacy browser is to check it with a 
legacy browser. For instance, you would not be able to test if your 
client or server-side validation of the date works on a legacy browser 
by testing it in a WF2 browser unless the WF2 browser had a feature for 
turning WF2 off, in which case <idate> would benefit in a similar manner.


From ian at hixie.ch  Wed Feb  9 07:21:41 2005
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 9 Feb 2005 15:21:41 +0000 (UTC)
Subject: [whatwg] Re: several messages
In-Reply-To: <opsluxphesofh7fl@crissov>
References: <41F659E0.1040709@earthlink.net>
	<851c8d3105012705432ecbf2d0@mail.gmail.com>
	<41F91945.7060906@earthlink.net>
	<851c8d31050127084967914a93@mail.gmail.com>
	<41F925ED.8040400@earthlink.net>
	<851c8d310501280256759eb54b@mail.gmail.com>
	<41FA3EEF.1000206@earthlink.net>
	<Pine.LNX.4.61.0501281359320.15536@dhalsim.dreamhost.com>
	<41FA8B25.4020001@earthlink.net>
	<0D62341D-7180-11D9-85E7-003065B8CF0E@iki.fi>
	<851c8d3105012902545fce5f43@mail.gmail.com>
	<41FBCBB8.5030306@earthlink.net> <41FE681F.60200@cam.ac.uk>
	<Pine.LNX.4.61.0501311720100.11029@dhalsim.dreamhost.com>
	<41FE6E94.6070604@cam.ac.uk>
	<Pine.LNX.4.61.0502031359580.6666@dhalsim.dreamhost.com>
	<opslolg7jwofh7fl@crissov>
	<Pine.LNX.4.61.0502071424470.11020@dhalsim.dreamhost.com>
	<4207943A.7050107@earthlink.net> <opsluxphesofh7fl@crissov>
Message-ID: <Pine.LNX.4.61.0502091520140.1757@dhalsim.dreamhost.com>

On Tue, 8 Feb 2005, [iso-8859-1] Christoph P?per wrote:
>
> A simple 'text' 'input' has the advantage that it generates only one 
> parameter to be handled by the server (and an optional client-side 
> validation script), just like the 'date' 'input' does. The most basic 
> handling would be to reject anything that is not an ISO?8601 conformant 
> string (in the valid time frame), requiring the user to resubmit. From 
> there on you can get as complex guessing as you want. Unambiguous, valid 
> inputs are (silently) accepted, others rejected. Rejection on ambiguity 
> should include showing the user the guessed likeliest value in an 
> unambiguous format, so he hopefully just has to accept without further 
> changing. The lesser advanced the guess script, the more important it is 
> to inform the user of the expected input style.
> 
> From the point of usability I wouldn't want '<input type="date">' to 
> fall back to anything but '<input type="text">'. Neither from the point 
> of marking-up and styling. In this case the programmer has to swallow 
> the bitter pill, IMVHO. After all it's a recurring problem for which he 
> has to find or write a solution only once (at least in theory).

I agree.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From mattraymond at earthlink.net  Wed Feb  9 08:06:21 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 09 Feb 2005 11:06:21 -0500
Subject: [whatwg] [WF2] The <icomplex> element
Message-ID: <420A34FD.5040705@earthlink.net>

INTRO:

    Ian had some interesting points about element counts, dynamic issues 
involving inheritance and the potential for empty legacy content in 
previous messages regarding <idate>. While I don't entirely agree with 
him, I feel it's better to change the concept to address some of his 
concerns than trying to convert him to my own opinions. Thus, I'm making 
the following changes to the <idate> concept:

1) I'm introducing a |type| attribute and combining all the various 
chronological elements (<idate>, <idatetime>, <itime>, <iweek>, et 
cetera) into a single element <icomplex>.

2) The new <icomplex> element will have all non-depreciated <input> 
attributes.

3) The <icomplex> element will now only be used in cases involving 
complex fallback (that is, situations where <input> can't effectively 
provide the desired fallback).

4) Inheritance is dropped.

5) Opening and closing tags should be required in both HTML and XHTML.

6) Suppression of Javascript within <icomplex> is not required. Controls 
within <icomplex>, however, will not be successful for submission.

    These changes reduce complexity for use as well as implementation, 
help prevent inappropriate use and provide a more general method of 
providing fallback that can be extended to non-chronological inputs and 
input types that don't even exist yet.

OUTDATED CONCEPTS:

    Note that all of the following concepts are outdated:

  * <format>
  * <date> (and it's siblings, AS A CONTROL)
  * <idate> (and it's siblings)

EXAMPLES:

    Here's a simple example for the three <select> scenario:

| <icomplex type="date" id="d1" name="d1" value="2005-02-09">
|  <select name="d1_day"><!-- Options --></select> /
|  <select name="d1_month"><!-- Options --></select> /
|  <select name="d1_year"><!-- Options --></select>
| </icomplex>

    Here's an example for users of jscalendar:

| <icomplex type="date" id="sel1_WF2" name="date1">
|  <input type="text" id="sel1" name="date1" size="30">
|  <input type="reset" value=" ... "
|   onclick="return showCalendar('sel1', '%Y-%m-%d');" >
|  YYYY-MM-DD
| </icomplex>

ISSUES RESOLVED:

    Ian brought up some issues in a previous message regarding <idate>. 
Let's take a look.

 >  * More complicated to implement:
 >     - more elements involved
 >     - interactions of elements and attributes that require
 >       dynamic updates (very bug prone)

    The number of elements has been reduced to one, and that element has 
a nearly identical list of attributes to <input>. The lack of 
inheritance prevents problems with dynamic updates. So unless you're 
really against adding a single additional element to HTML, this section 
is no longer an issue.

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

    As previously stated, there is now only one additional element, and 
it's only used when complex legacy support is needed.

    If scripting using the form .elements collection is a problem for 
webmasters, they have the option of falling back to <input>, but since 
webmasters can either use getElementById or cycle through the elements 
until an |id| is found (for DOM1 browsers), this largely looks like a 
non-issue. Suggestions for improvement are welcome, of course.

 >  * Fallback needs author involvement
 >     - easiest to simply not support legacy
 >     - server typically needs to handle different names for controls,
 >       not just different format

    Since <icomplex> is a compliment to <input>, and has the same 
attributes but requires a closing tag, <input> will still be preferred 
by webmasters that don't want to include fallback. The server handling 
is a red herring, because <input> doesn't address the problem of 
fallback to multiple controls.

    So it looks like nearly all of his concerns have been addressed. Let 
me know if there are any other concerns to address.


From hallvors at online.no  Thu Feb 10 03:35:32 2005
From: hallvors at online.no (Hallvord Reiar Michaelsen Steen)
Date: Thu, 10 Feb 2005 12:35:32 +0100
Subject: [whatwg] [WF2] The <icomplex> element
In-Reply-To: <420A34FD.5040705@earthlink.net>
Message-ID: <420B5514.9827.7CF51ED@localhost>

On 9 Feb 2005 at 11:06, Matthew Raymond wrote:
> it's only used when complex legacy support is needed.
<X>
> <input> will still be preferred by webmasters that don't want to 
> include fallback. 

You can neither dictate nor predict such things. 
Authors are going to use it however they like (not to mention that 
their WYSIWYG editor will do things that they are not even aware of) 
;)

>  Let me know if there are any other concerns to address. 

Not the prettiest tag name :)

The .elements problem is not solved, since the indexes will still be 
different depending on what type of UA you deal with. It is more 
common to access elements by name but in this scenario we are dealing 
with legacy content possibly including older scripts that do not use 
getElementById et al.

A DOM scripting issue if you want to add a new HTML element: what do 
browsers do if you do document.createElement('icomplex') ? Will any 
browsers choke and throw errors? If an element is created, can the 
script reliably detect if the created element is the element type 
they expect?
-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/

Note: mail to hallvors at online.no will still be read but you may want to start using 
hallvord at hallvord.com instead

-- 
Hallvord Reiar Michaelsen Steen
http://www.hallvord.com/

Note: mail to hallvors at online.no will still be read but you may want to start using 
hallvord at hallvord.com instead



From mattraymond at earthlink.net  Thu Feb 10 06:47:33 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 10 Feb 2005 09:47:33 -0500
Subject: [whatwg] [WF2] The <icomplex> element
In-Reply-To: <420B5514.9827.7CF51ED@localhost>
References: <420B5514.9827.7CF51ED@localhost>
Message-ID: <420B7405.6080301@earthlink.net>

Hallvord Reiar Michaelsen Steen wrote:
> On 9 Feb 2005 at 11:06, Matthew Raymond wrote:
>>it's only used when complex legacy support is needed.
> 
> <X>

"<X>"???

    I was referring to how it would be presented in the spec. I don't 
expect we can enforce a specific use in any way. However, I don't think 
such enforcement is needed. See below.

>><input> will still be preferred by webmasters that don't want to 
>>include fallback. 
> 
> You can neither dictate nor predict such things. 
> Authors are going to use it however they like (not to mention that 
> their WYSIWYG editor will do things that they are not even aware of) 
> ;)

    True, but if you were used to using <input>, would you use a tag 
with  then same attributes but a longer name and a required closing tag 
to do the exact same thing? Especially if the specs say to use <input> 
in simple cases? Take a look:

| <input type="date" name="date1" value="2005-02-10">

| <icomplex type="date" name="date1" value="2005-02-10"></icomplex>

    So it's not a certainty, but it's pretty close. As for the editor, 
they can simply use <input> by default and give a warning before saving 
if <icomplex> has no contents. (Can we require contents??? My first 
guess would be no, but maybe someone knows more than I.)

>> Let me know if there are any other concerns to address. 
> 
> Not the prettiest tag name :)

    Other suggestions are welcome. Some possibilities:

  * <inputcomplex>
  * <inputc>
  * <cinput>
  * <ci>
  * <input1>
  * <ic>
  * <ilegacy>

> The .elements problem is not solved, since the indexes will still be 
> different depending on what type of UA you deal with. It is more 
> common to access elements by name but in this scenario we are dealing 
> with legacy content possibly including older scripts that do not use 
> getElementById et al.

    Well, one solution would be to provide an optional attribute that 
can exclude <icomplex> from the .elements collection:

| <icomplex domcloak="true" name="hideMe"><!-- Contents. --></icomplex>

    I'm not sure I like that solution though, and I'm almost certain Ian 
won't like it. Another solution would be that <icomplex> would never be 
included in the .elements collection at all. That seems like a better 
solution, and since the WF2 DOM extensions depend on DOM2 and 
getElementById is well supported. So there's no issues of being able to 
get a specific <icomplex> element on WF2 UAs.

> A DOM scripting issue if you want to add a new HTML element: what do 
> browsers do if you do document.createElement('icomplex')?  Will any
 > browsers choke and throw errors?

    This isn't actually a problem specific to <icomplex>. Elements such 
as <datalist>, <output> and any other new elements we introduce could 
have this problem. If this can't be addressed, it may be a serious 
problem for any WHATWG specification.

> If an element is created, can the script reliably detect if the
 > created element is the element type they expect?

    /me shrugs and offers this:

| if (myIcomplexElement.type) // Does the object has a .type property?

    Yeah, assuming an unrecognized element doesn't automatically have 
properties that aren't on most elements, I'd say that's pretty safe. 
Remember, though that IANAJSG. (Guess the acronym!) ;)

    Is it just me, or are there holes in the Javascript and DOM specs 
that you can drive a truck through?


From michael at quuxo.com  Thu Feb 10 19:34:26 2005
From: michael at quuxo.com (Michael Gratton)
Date: Fri, 11 Feb 2005 14:04:26 +1030
Subject: [whatwg] default action/button for forms
Message-ID: <1108092866.4753.40.camel@wintermute>

Hi guys,

After looking through the archives, surprised to find that there has
been no mention of some way to specify the default button/action for a
form.

Most browsers behave as the Web Forms 2.0 spec specifies in section 2.3,
"Changes to existing controls". That is, the first button is used as the
default. But this is pretty annoying behaviour. In a large form, it is
common to have several submit buttons and is is just as likely as it is
not that the first button should be the default.

As a result, web application developers generally resort to one of two
kluges: adding a hidden submit button to the form or using JavaScript to
trap key events or the form submission event.

For me is is also a problem because <troll>like today's common usable
desktop environments (Mac OS, GNOME, etc),</troll> I design forms so
that the default button is to the right of any additional action
buttons.

It would be great to see some way of specifying the default button for
the form in Web Forms 2.0, or some later revision. One way of
implementing this (and the way I would do it if I was fixing the problem
using JavaScript) would be to add a "default-action" attribute or
similar to the form element. This would be an IDREF that specifies the
id of the default submit button. Eg:

  <form action="bofh" method="post" default-action="lart">
    <input type="text" name="who">
    <input type="submit" id="ignore" name="action" value="Ignore">
    <input type="submit" id="lart" name="action" value="LART">
  </form>

What do you think?

/Mike

-- 
Michael Gratton, Software Architect.
Quuxo Software <http://web.quuxo.com/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20050211/295fe386/attachment-0001.pgp>

From mattraymond at earthlink.net  Fri Feb 11 08:52:55 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Fri, 11 Feb 2005 11:52:55 -0500
Subject: [whatwg] default action/button for forms
In-Reply-To: <1108092866.4753.40.camel@wintermute>
References: <1108092866.4753.40.camel@wintermute>
Message-ID: <420CE2E7.6010405@earthlink.net>

Michael Gratton wrote:
> After looking through the archives, surprised to find that there has
> been no mention of some way to specify the default button/action for a
> form.
> 
> Most browsers behave as the Web Forms 2.0 spec specifies in section 2.3,
> "Changes to existing controls". That is, the first button is used as the
> default. But this is pretty annoying behaviour. In a large form, it is
> common to have several submit buttons and is is just as likely as it is
> not that the first button should be the default.

    Good point.

> As a result, web application developers generally resort to one of two
> kluges: adding a hidden submit button to the form or using JavaScript to
> trap key events or the form submission event.

    Neither ideal, since it's best to have solutions that don't CSS or 
JS support.

[Snip!]

> It would be great to see some way of specifying the default button for
> the form in Web Forms 2.0, or some later revision. One way of
> implementing this (and the way I would do it if I was fixing the problem
> using JavaScript) would be to add a "default-action" attribute or
> similar to the form element. This would be an IDREF that specifies the
> id of the default submit button. Eg:
> 
>   <form action="bofh" method="post" default-action="lart">
>     <input type="text" name="who">
>     <input type="submit" id="ignore" name="action" value="Ignore">
>     <input type="submit" id="lart" name="action" value="LART">
>   </form>
> 
> What do you think?

    I'd prefer something like this:

| <form action="http://somesite.com/prog/adduser" method="post">
|   <input type="text" name="who">
|   <input type="submit" name="action" value="Remove">
|   <input default type="submit" name="action" value="Add">
| </form>


From fora at annevankesteren.nl  Sat Feb 12 16:37:38 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 13 Feb 2005 01:37:38 +0100
Subject: [whatwg] [wf2] type="url"
Message-ID: <420EA152.7090100@annevankesteren.nl>

After thinking about it. Having |type="url"| instead of |type="uri"| or 
|type="iri"| might not be so bad.

It would also be compatible with CSS, which is the main advantage.

Furthermore, URL does not really mean anything anymore on todays web 
though it is widely understood.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From michael at quuxo.com  Sat Feb 12 17:55:15 2005
From: michael at quuxo.com (Michael Gratton)
Date: Sun, 13 Feb 2005 12:25:15 +1030
Subject: [whatwg] default action/button for forms
In-Reply-To: <420CE2E7.6010405@earthlink.net>
References: <1108092866.4753.40.camel@wintermute>
	<420CE2E7.6010405@earthlink.net>
Message-ID: <1108259715.20772.61.camel@wintermute>

On Fri, 2005-02-11 at 11:52 -0500, Matthew Raymond wrote:
> 
>     I'd prefer something like this:
> 
> | <form action="http://somesite.com/prog/adduser" method="post">
> |   <input type="text" name="who">
> |   <input type="submit" name="action" value="Remove">
> |   <input default type="submit" name="action" value="Add">
> | </form>

Sounds reasonable, it does allow some ambiguity however (what happens if
there a multiple defaults in one form?) and the default button to my
mind seems more like a property of the form then a control.

But hey, I'd be happy with either.

/Mike

-- 
Michael Gratton, Software Architect.
Quuxo Software <http://web.quuxo.com/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20050213/2764b123/attachment-0001.pgp>

From hsivonen at iki.fi  Sun Feb 13 01:29:47 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 13 Feb 2005 11:29:47 +0200
Subject: [whatwg] [wf2] type="url"
In-Reply-To: <420EA152.7090100@annevankesteren.nl>
References: <420EA152.7090100@annevankesteren.nl>
Message-ID: <91ba2235e5546f4383f2b14e550e3c10@iki.fi>

On Feb 13, 2005, at 02:37, Anne van Kesteren wrote:

> Furthermore, URL does not really mean anything anymore on todays web

IMO, that stance is both impractical and revisionist.

Quoting RFC 3986, section 1.1.3.:
"A URI can be further classified as a locator, a name, or both.  The 
term 'Uniform Resource Locator' (URL) refers to the subset of URIs 
that, in addition to identifying a resource, provide a means of 
locating the resource by describing its primary access mechanism (e.g., 
its network 'location')."

The practical matter is that the URL subset of URIs is the subset that 
actually works. I think it is rather silly to talk about URIs in 
contexts where everyone knows that the URI needs to be dereferencable 
and only URLs (or only HTTP URLs) actually work.

As for identifiers, character to character comparison works much better 
for identifier equality comparison that full-blown scheme-aware URI 
comparison.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/



From hsivonen at iki.fi  Sun Feb 13 02:18:38 2005
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 13 Feb 2005 12:18:38 +0200
Subject: [whatwg] default action/button for forms
In-Reply-To: <420CE2E7.6010405@earthlink.net>
References: <1108092866.4753.40.camel@wintermute>
	<420CE2E7.6010405@earthlink.net>
Message-ID: <5710727973deb3ed87041d93285ae979@iki.fi>

On Feb 11, 2005, at 18:52, Matthew Raymond wrote:

> <input default type="submit" name="action" value="Add">

As a practical matter, it would be better to avoid new minimized 
attributes in order to avoid changes to tag soup processors that handle 
a closed list of attributes as special minimized cases.

-- 
Henri Sivonen
hsivonen at iki.fi
http://iki.fi/hsivonen/



From fora at annevankesteren.nl  Sun Feb 13 02:26:08 2005
From: fora at annevankesteren.nl (Anne van Kesteren)
Date: Sun, 13 Feb 2005 11:26:08 +0100
Subject: [whatwg] [wf2] type="url"
In-Reply-To: <91ba2235e5546f4383f2b14e550e3c10@iki.fi>
References: <420EA152.7090100@annevankesteren.nl>
	<91ba2235e5546f4383f2b14e550e3c10@iki.fi>
Message-ID: <420F2B40.9030406@annevankesteren.nl>

Henri Sivonen wrote:
> On Feb 13, 2005, at 02:37, Anne van Kesteren wrote:
> 
>> Furthermore, URL does not really mean anything anymore on todays web
>
> IMO, that stance is both impractical and revisionist.
> 
> Quoting RFC 3986, section 1.1.3.:
> "A URI can be further classified as a locator, a name, or both.  The 
> term 'Uniform Resource Locator' (URL) refers to the subset of URIs that, 
> in addition to identifying a resource, provide a means of locating the 
> resource by describing its primary access mechanism (e.g., its network 
> 'location')."
> 
> The practical matter is that the URL subset of URIs is the subset that 
> actually works. I think it is rather silly to talk about URIs in 
> contexts where everyone knows that the URI needs to be dereferencable 
> and only URLs (or only HTTP URLs) actually work.

IIRC URLs do not include #foo, which is quite a practical thing and 
heavily used on todays web.

Agreed that I should have dropped that last sentence.


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>



From mattraymond at earthlink.net  Sun Feb 13 04:14:18 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Sun, 13 Feb 2005 07:14:18 -0500
Subject: [whatwg] default action/button for forms
In-Reply-To: <1108259715.20772.61.camel@wintermute>
References: <1108092866.4753.40.camel@wintermute>	<420CE2E7.6010405@earthlink.net>
	<1108259715.20772.61.camel@wintermute>
Message-ID: <420F449A.1080903@earthlink.net>

Michael Gratton wrote:
> On Fri, 2005-02-11 at 11:52 -0500, Matthew Raymond wrote:
>>    I'd prefer something like this:
>>
>>| <form action="http://somesite.com/prog/adduser" method="post">
>>|   <input type="text" name="who">
>>|   <input type="submit" name="action" value="Remove">
>>|   <input default type="submit" name="action" value="Add">
>>| </form>
> 
> Sounds reasonable, it does allow some ambiguity however (what happens if
> there a multiple defaults in one form?)

    I just assumed we'd handle it the same way as |autofocus|:

| Authors should avoid setting the autofocus attribute on multiple
| enabled elements in a document. If multiple elements with the
| autofocus attribute set are  inserted into a document, each one will
| be processed as described above, as they are inserted. This means that
| during document load, for example, the last focusable form control in
| document order with the attribute set will end up with the focus.

    So the last button of the form set as the default would be default.

 > and the default button to my
> mind seems more like a property of the form then a control.

    I disagree. In Visual Basic, for instance, the value is set on the 
button, not the form. (Although, in VB, the environment automatically 
sets the value of the |default| property on all other buttons to false. 
I suppose HTML editors could follow suit.) Furthermore, HTML has a 
history of putting mutually exclusive values on items rather than the 
container of the items (see <option selected> and <input type="radio" 
checked>).

    Also, in WA1, the <command> element has an attribute of the same 
name that does roughly the same thing.

> But hey, I'd be happy with either.

    Good to know. :)

Henri Sivonen wrote:
 > On Feb 11, 2005, at 18:52, Matthew Raymond wrote:
 >>| <input default type="submit" name="action" value="Add">
 >
 > As a practical matter, it would be better to avoid new minimized
 > attributes in order to avoid changes to tag soup processors that
 > handle a closed list of attributes as special minimized cases.

    Yeah, WA1 does the same thing with <command>, so we can just fall in 
line:

| <input default="default" type="submit" name="action" value="Add">

    Hmm. On a side note: What was our motivation for making people put 
the name of the property as the value in these cases? Why not just 
"true"? Not that important, though...


From mattraymond at earthlink.net  Sun Feb 13 11:26:54 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Sun, 13 Feb 2005 14:26:54 -0500
Subject: [whatwg] [WF2] <icomplex> Recap
Message-ID: <420FA9FE.6030709@earthlink.net>

    Here's a quick recap of <icomplex>...


QUICK DESCRIPTION:

    It's just like <input>, with three exceptions:

  * It doesn't have the depreciated attributes.
  * It should contain alternative contents for legacy support.
  * It requires a closing tag ("</icomplex>").


EXAMPLES:

     Here's a simple example for the three <select> scenario:

| <icomplex type="date" id="d1" name="d1" value="2005-02-09">
|  <select name="d1_day"><!-- Options --></select> /
|  <select name="d1_month"><!-- Options --></select> /
|  <select name="d1_year"><!-- Options --></select>
| </icomplex>

     Here's an example for users of jscalendar:

| <icomplex type="date" id="sel1_WF2" name="date1">
|  <input type="text" id="sel1" name="date1" size="30">
|  <input type="reset" value=" ... "
|   onclick="return showCalendar('sel1', '%Y-%m-%d');" >
|  YYYY-MM-DD
| </icomplex>


PROS:

1) The <icomplex> element can allow for a far greater range of legacy 
fallback than <input>.

2) Because the |type| is defined in an attribute, <icomplex> can be used 
for input types in later specifications, or for vendor-specific input types.

3) The element is designed in both semantics and structure to encourages 
the use of <input> in simple cases where legacy fallback needs are minimal.

4) The element is designed only to prevent the presentation of its child 
elements. It does not require user agents to delete contents from the 
DOM or suppress Javascript execution.

5) Because it has the same attributes as <input>, there's nothing new to 
learn except the inclusion of fallback content.

CONS:

1) The size of a form's elements collection in Javascript may differ 
between user agents.

2) There may be legacy Javascript issues that cause script failure when 
generating unrecognized elements.

3) When creating an <icomplex> element, you should be able to test for 
the correct element type by checking to see if it has a .type property, 
but I can't be 100% certain.

4) Some unneeded Javascript overhead on WF2 clients.

5) CSS styling for <icomplex> can't be done directly because user agents 
that support unrecognized elements may use the styling instead of 
ignoring the <icomplex> as intended.

6) The name sucks?


SOLUTIONS FOR CONS:

1) We could just define <icomplex> as never showing up in the .elements 
collection, or provide an attribute to that effect. Neither are ideal, 
but if most of the WF2 content will be written from scratch, then 
.elements is only an issue for those trying to support browsers without 
support for getElementById.

2) This is a general issue affecting all new elements we introduce.

3) May not be an issue, but I'd like to hear from an expert.

4) Ian seems to feel this is a non-issue, so I won't argue with him.

5) Simply style <icomplex type="something"> as if it were <input 
type="something"> in WF2 user agents. Therefore, on a system that uses 
the following CSS...

| input[type=date] { /* Some styling here. */ }

...The above styling would apply to both <input type="date"> and 
<icomplex type="date">.

6) Someone should suggest a new name if they don't like the current one.


From mpt at myrealbox.com  Mon Feb 14 06:02:11 2005
From: mpt at myrealbox.com (Matthew Thomas)
Date: Mon, 14 Feb 2005 16:02:11 +0200
Subject: [whatwg] [WF2] <icomplex> Recap
In-Reply-To: <420FA9FE.6030709@earthlink.net>
References: <420FA9FE.6030709@earthlink.net>
Message-ID: <ef32a544f7c9df731555bd6b1f11bed0@myrealbox.com>

On 13 Feb, 2005, at 9:26 PM, Matthew Raymond wrote:
> ...
> CONS:
> ...
> 6) The name sucks?
> ...
> 6) Someone should suggest a new name if they don't like the current 
> one.

<entry>.

-- 
Matthew Thomas
http://mpt.net.nz/



From mattraymond at earthlink.net  Mon Feb 14 07:21:23 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 14 Feb 2005 10:21:23 -0500
Subject: [whatwg] [WF2] <icomplex> Recap
In-Reply-To: <ef32a544f7c9df731555bd6b1f11bed0@myrealbox.com>
References: <420FA9FE.6030709@earthlink.net>
	<ef32a544f7c9df731555bd6b1f11bed0@myrealbox.com>
Message-ID: <4210C1F3.3010501@earthlink.net>

Matthew Thomas wrote:
> On 13 Feb, 2005, at 9:26 PM, Matthew Raymond wrote:
>>6) Someone should suggest a new name if they don't like the current 
>>one.
> 
> <entry>.

    There are a few problems with this name:

1) An <entry> element could easily be confused for being an entry in a 
weblog or similar document. It could also be confused for being some 
kind of entry point for something, like insertion of content. It just 
doesn't have a very clear meaning. In fact, if you go here...

    http://thesaurus.reference.com/search?q=input

...you'll notice that entry isn't even listed as a synonym of input.

2) There's nothing about the name "entry" that allows people to 
associate it with the <input> element (which it's modeled on).

3) There's nothing about the name "entry" that people can associate with 
legacy content.

    I could live with _<dataentry>_, though. That's very clearly an 
input element, and it has a mild phonetic association with <datalist>, 
which itself supports legacy content. (My only issue is that it's a 
little on the long side, but then to a lesser extent so is <icomplex>.)


From mattraymond at earthlink.net  Fri Feb 18 05:07:40 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Fri, 18 Feb 2005 08:07:40 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
Message-ID: <4215E89C.70303@earthlink.net>

    I've been pondering my earlier post regarding calendars in WA1:

http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003046.html

    While I like the idea, it seems to introduce too many tags, so I've 
simplified things a bit. The element <cattr> will now be called <vattr> 
and will be used in place of <cdatetime> and <csummary>. This may seem 
to general, but if you look at a vCalendar example, it's pretty straight 
forward. Here's a vCalendar from the hCalendar spec 
(http://developers.technorati.com/wiki/hCalendar):

| BEGIN:VCALENDAR
| PRODID:-//XYZproduct//EN
| VERSION:2.0
| BEGIN:VEVENT
| URL:http://www.web2con.com/
| DTSTART:20041005
| DTEND:20041007
| SUMMARY:Web 2.0 Conference
| END:VEVENT
| END:VCALENDAR

    Now here's how I propose we handle the same information in WA1 markup:

| <vcalendar>
|   <vattr name="prodid" value="-//XYZproduct//EN"
|   <vattr name="version" value="2.0"></vattr>
|   <vevent>
|     <vattr name="url" value="http://www.web2con.com/"></vattr>
|     <vattr name="dtstart" value="2004-10-05"></vattr>
|     <vattr name="dtend" value="2004-10-07"></vattr>
|     <vattr name="summary" value="Web 2.0 Conference"></vattr>
|   </vevent>
| </vcalendar>

    It's fairly simple, and it can be transformed directly into a 
vCalendar and back. The idea is quite similar for vCards. Let's look at 
and example from the hCard spec 
(http://developers.technorati.com/wiki/hCard):

| BEGIN:VCARD
| VERSION:3.0
| N:?elik;Tantek
| FN:Tantek ?elik
| URL:http://tantek.com
| END:VCARD

    This translates into the following markup:

| <vcard>
|   <vattr name="version" value="3.0"></vattr>
|   <vattr name="n" value="?elik;Tantek"></vattr>
|   <vattr name="fn" value="Tantek ?elik"></vattr>
|   <vattr name="url" value="http://tantek.com"></vattr>
| </vcard>

    As you can see, the markup structure mirrors the vCard structure and 
contains the same attribute names and information. It would be trivial 
to parse this information and convert it to vCard format.

    Here's the same two examples with fallback content:

| <vcalendar>
|   <table>
|     <caption>Upcoming Events</caption>
|     <tr>
|       <th>URL</th>
|       <th>Start Date</th>
|       <th>End Date</th>
|       <th>Summary</th>
|     </tr>
|     <vevent>
|     <tr>
|       <td><vattr name="url">http://www.web2con.com/</vattr></td>
|       <td><vattr name="dtstart">2004-10-05</vattr></td>
|       <td><vattr name="dtend">2004-10-07</vattr></td>
|       <td><vattr name="summary">Web 2.0 Conference</vattr></td>
|     </tr>
|     </vevent>
|   </table>
| </vcalendar>

| <vcard>
|   <vattr name="version" value="3.0"></vattr>
|   <vattr name="n" value="?elik;Tantek"></vattr>
|   <div id="tc" class="vcard">
|     <p><vattr name="fn">Tantek ?elik</vattr></p>
|     <a href="http://tantek.com">
|      <vattr name="url">http://tantek.com</vattr>
|     </a>
|     <button type="button" onclick="return addContact('tc')">
|       Add to contact list...
|     </button>
|   </div>
| </vcard>

    Comments welcome.


From ian at hixie.ch  Fri Feb 18 05:43:44 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 18 Feb 2005 13:43:44 +0000 (UTC)
Subject: [whatwg] Status Update
Message-ID: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>


If you've sent feedback on the Web Apps spec in the past few months, 
please do not think it has been ignored. I will be getting to it 
eventually. At the moment I am writing large chunks of spec in sections 1 
and 2 (recently added were the conformance requirements and the sections 
defining the <html>, <head>, <body>, <base>, etc, elements). Those 
sections are still under heavy development so while comments are welcome, 
don't be too quick to complain. ;-) However, since I'm writing these 
sections I've not had time to reply to comments.

I will be returning to Web Forms comments in due course as well, don't 
think that I'm ignoring those either!

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jim.ley at gmail.com  Fri Feb 18 07:35:05 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Fri, 18 Feb 2005 15:35:05 +0000
Subject: [whatwg] Status Update
In-Reply-To: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>
Message-ID: <851c8d31050218073550ce7f7b@mail.gmail.com>

On Fri, 18 Feb 2005 13:43:44 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 
> If you've sent feedback on the Web Apps spec in the past few months,
> please do not think it has been ignored. I will be getting to it
> eventually. 

As you're months behind by your own admission, maybe it would be a
good idea if some of the other members of the working group started
actually responding to issues too.  Why do they not, why does the
WHAT-WG have a single point of failure, are the other members not
really interested in contributing to this work?

One of the big themes coming from the Web Applications workshop in San
Jose was that the W3 was a bad place to do this work due to the
incredible slowness and a small outside organisation could do it so
much faster, indeed the original discussion on this list was for
implementations to be in the wild for Christmas, we're still a long
way from even having a spec, let alone a call for implementations.

Maybe a little more speed from the WHAT WG members (not criticising
you individually Ian, you obviously spend an awful lot of time on
this) would mean we'd actually have something worth using.

Jim.


From jim.ley at gmail.com  Fri Feb 18 08:45:41 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Fri, 18 Feb 2005 16:45:41 +0000
Subject: [whatwg] Re: [off-list] Status Update
In-Reply-To: <Pine.LNX.4.61.0502181552510.8897@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502181333240.8897@dhalsim.dreamhost.com>
	<851c8d31050218073550ce7f7b@mail.gmail.com>
	<Pine.LNX.4.61.0502181552510.8897@dhalsim.dreamhost.com>
Message-ID: <851c8d3105021808456681a813@mail.gmail.com>

On Fri, 18 Feb 2005 16:00:04 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 18 Feb 2005, Jim Ley wrote:
> > As you're months behind by your own admission, maybe it would be a good
> > idea if some of the other members of the working group started actually
> > responding to issues too.
> 
> More people responding would not make things go faster. 

Of course it does, one of the continual problems on this is your
(comparitively) limited experience of script, therefore it takes
people a long time to explain to you why your "it's all solved with
script" is simply not true.  If the issue is addressed and resolved by
someone with lots of  script experience those delays simply would not
happen.

>The problem with
> many W3C committees that I'm directly familiar with is in fact that there
> are too many people responding to issues, not too few.

So you would say that 1 and just 1 person is the appropriate number
(no other member of the WHAT-WG has responded to an issue that you've
not also responded too)  I'm afraid I cannot agree with that, and
whilst I would agree that lots of people is bad the sweet spot is not
1.  What's the point of all the other members if they don't do
anything - I find it difficult to believe they're even reading the
list.

> > are the other members not really interested in contributing to this
> > work?
> 
> While it may not be in the form of heavy volume posting to the WHATWG
> list, I can assure you that the other members are doing their part.

Rather than "assure me" could you point to some concrete things that
they're doing?  They're not responding to issues, they're providing
text, they're not providing input, what exactly is their part?  Simply
trying to give this body some credibility by lending their names to
it?  If that is the case then yes, I guess they are "doing their part"
 but I'd like to see that made clear.

> I don't recall speed ever being an issue that was raised related to doing
> the WF2 and WA1 work in the WHATWG instead of the W3C. The W3C is not
> necessarily slow.

I certainly recall speed being one of the main motivators, and urls like
http://www.mozillazine.org/talkback.html?article=4816  "many feel that
formal standards bodies move too slowly " reflect that.

> The WF2 spec is basically done. Implementation work has started.

What?  before a "call for implementation", that's scary, I understood
you'd previously argued that this was a bad thing?  The spec is
clearly not finished, there are big unresolved issues (particularly
the date fallback and icomplex type proposals)

Jim.


From bkn3 at columbia.edu  Fri Feb 18 11:29:23 2005
From: bkn3 at columbia.edu (Brad Neuberg)
Date: Fri, 18 Feb 2005 11:29:23 -0800
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <4215E89C.70303@earthlink.net>
References: <4215E89C.70303@earthlink.net>
Message-ID: <6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>

Have you seen Tantek's work with hCalendar, which is basicly the iCal 
standard translated into XHTML? It's very clean and seems like a nice 
ancillary standard that could be included with WA:

http://developers.technorati.com/wiki/hCalendar

At 05:07 AM 2/18/2005, Matthew Raymond wrote:
>    I've been pondering my earlier post regarding calendars in WA1:
>
>http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003046.html
>
>    While I like the idea, it seems to introduce too many tags, so I've 
> simplified things a bit. The element <cattr> will now be called <vattr> 
> and will be used in place of <cdatetime> and <csummary>. This may seem to 
> general, but if you look at a vCalendar example, it's pretty straight 
> forward. Here's a vCalendar from the hCalendar spec 
> (http://developers.technorati.com/wiki/hCalendar):
>
>| BEGIN:VCALENDAR
>| PRODID:-//XYZproduct//EN
>| VERSION:2.0
>| BEGIN:VEVENT
>| URL:http://www.web2con.com/
>| DTSTART:20041005
>| DTEND:20041007
>| SUMMARY:Web 2.0 Conference
>| END:VEVENT
>| END:VCALENDAR
>
>    Now here's how I propose we handle the same information in WA1 markup:
>
>| <vcalendar>
>|   <vattr name="prodid" value="-//XYZproduct//EN"
>|   <vattr name="version" value="2.0"></vattr>
>|   <vevent>
>|     <vattr name="url" value="http://www.web2con.com/"></vattr>
>|     <vattr name="dtstart" value="2004-10-05"></vattr>
>|     <vattr name="dtend" value="2004-10-07"></vattr>
>|     <vattr name="summary" value="Web 2.0 Conference"></vattr>
>|   </vevent>
>| </vcalendar>
>
>    It's fairly simple, and it can be transformed directly into a 
> vCalendar and back. The idea is quite similar for vCards. Let's look at 
> and example from the hCard spec (http://developers.technorati.com/wiki/hCard):
>
>| BEGIN:VCARD
>| VERSION:3.0
>| N:?elik;Tantek
>| FN:Tantek ?elik
>| URL:http://tantek.com
>| END:VCARD
>
>    This translates into the following markup:
>
>| <vcard>
>|   <vattr name="version" value="3.0"></vattr>
>|   <vattr name="n" value="?elik;Tantek"></vattr>
>|   <vattr name="fn" value="Tantek ?elik"></vattr>
>|   <vattr name="url" value="http://tantek.com"></vattr>
>| </vcard>
>
>    As you can see, the markup structure mirrors the vCard structure and 
> contains the same attribute names and information. It would be trivial to 
> parse this information and convert it to vCard format.
>
>    Here's the same two examples with fallback content:
>
>| <vcalendar>
>|   <table>
>|     <caption>Upcoming Events</caption>
>|     <tr>
>|       <th>URL</th>
>|       <th>Start Date</th>
>|       <th>End Date</th>
>|       <th>Summary</th>
>|     </tr>
>|     <vevent>
>|     <tr>
>|       <td><vattr name="url">http://www.web2con.com/</vattr></td>
>|       <td><vattr name="dtstart">2004-10-05</vattr></td>
>|       <td><vattr name="dtend">2004-10-07</vattr></td>
>|       <td><vattr name="summary">Web 2.0 Conference</vattr></td>
>|     </tr>
>|     </vevent>
>|   </table>
>| </vcalendar>
>
>| <vcard>
>|   <vattr name="version" value="3.0"></vattr>
>|   <vattr name="n" value="?elik;Tantek"></vattr>
>|   <div id="tc" class="vcard">
>|     <p><vattr name="fn">Tantek ?elik</vattr></p>
>|     <a href="http://tantek.com">
>|      <vattr name="url">http://tantek.com</vattr>
>|     </a>
>|     <button type="button" onclick="return addContact('tc')">
>|       Add to contact list...
>|     </button>
>|   </div>
>| </vcard>
>
>    Comments welcome.

Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html. 



From mattraymond at earthlink.net  Mon Feb 21 04:58:11 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Mon, 21 Feb 2005 07:58:11 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
Message-ID: <4219DAE3.8080604@earthlink.net>

Brad Neuberg wrote:
> Have you seen Tantek's work with hCalendar, which is basicly the iCal 
> standard translated into XHTML? It's very clean and seems like a nice 
> ancillary standard that could be included with WA:
> 
> http://developers.technorati.com/wiki/hCalendar
[Snip!]
> At 05:07 AM 2/18/2005, Matthew Raymond wrote:
[Snip!]
>>(http://developers.technorati.com/wiki/hCalendar):

    So, as you can see above, the answer to that question would be yes.

    There are several problems with hCalendar (and in turn, vCard):

1) There is no way for some reading the markup to tell if a class name
is the name of an attribute or simply the name of a class used for styling.

2) As a result of the above, user agents would not be able to reliably
allow users to access extension properties such as
"x-mozilla-alarm-default-length" (which is an actual extension used in
Sunbird).

3) Other than Ian's <calendar> addition, there's no actual semantic
markup for calendars or business cards.

4) What happens if I use a class inside <calendar> when I don't want the
element I use it on to be a property of the calendar? What happens if
the class is used both inside and outside <calendar>?

5) What do I do if I want to add styling to a group of calendar events,
especially if the calendar contains dynamic content? Styling a long list
of IDs through the use of dynamically generated CSS doesn't sound all
that appealing.

6) What do you do if you don't want the calendar or card to show up on
legacy user agents, or what if you don't want specific properties to
show up? hCalendar and hCard require you to use CSS to hide markup in
legacy user agents.

7) The use of <abbr> for dates is incorrect. "August 5th, 2004" is not
the abbreviation of 2004-09-05. In fact, the opposite is closer to the
truth. So, what would be a semantically correct method for storing
separate values for legacy UAs and WA1 UAs?

8) If we're going to use title for separation of content for differing
user agents, what happens when we want tooltips on certain items for
legacy user agents? For that matter, how do we use those tooltips on WA1
user agents?

9) What element is most appropriate in specific circumstances? Would the
use of <acronym> for DTSTART be just as good as <abbr>??? What happens
if a browser doesn't support either <acronym> or <abbr> with respect to
calendars?

    So, effectively, for hCard and hCalendar, you have to create a
complex set of rules for all possible uses of legacy markup within
<calendar> which can easily be implemented incorrectly, and even then
you still have styling and tooltip issues that are unresolved. By
contrast, my system had a clear separation between legacy markup and WA1
markup. My system also works on a simple set of rules that don't change
or overload any existing elements, and it does so without adding
complicated markup. Compare the following:

| <calendar>
|  <span class="vevent">
|   <a class="url" href="http://www.web2con.com/">
|    <abbr class="dtstart" title="20041005">October 5</abbr>-
|    <abbr class="dtend" title="20041007">7</abbr>
|    <span class="summary">Web 2.0 Conference</span>
|   </a>
|  </span>
| </calendar>

| <vcalendar>
|  <vevent>
|   <a href="http://www.web2con.com/">
|    <vattr name="url" value="http://www.web2con.com/"></vattr>
|    <vattr name="dtstart" value="20041005">October 5</vattr>-
|    <vattr name="dtend" value="20041007">7</vattr>
|    <vattr name="summary">Web 2.0 Conference</vattr>
|   </a>
|  </vevent>
| </vcalendar>

    They're very similar, but only the first overloads |class| and
|title|. Only the hCalendar example uses multiple elements to define
calendar properties. Granted, you save an element, but at the cost of
diluting the meaning of <a>.

    Not that I don't see the advantage and flexibility of the
hCard/hCalendar system. You can use multiple class names to declare
redundant attributes in a single element. You can also nest
calendar/card attributes. (Then again, you could theoretically do the
same with <vattr>.)

    The problem is that, for all the creative ways you can use
hCalendar/hCard, it's more complicated for webmasters to read and
understand and more complicated for developers to implement. 
Furthermore, I dislike the entire system of using class names as markup. 
Class names should be reserved for user-defined semantics.


From ian at hixie.ch  Mon Feb 21 11:53:12 2005
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 21 Feb 2005 19:53:12 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <4219DAE3.8080604@earthlink.net>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>

On Mon, 21 Feb 2005, Matthew Raymond wrote:
> 
> There are several problems with hCalendar (and in turn, vCard): [...]

Tantek has asked me to point people to:

  http://developers.technorati.com/wiki/hCalendarFAQ
  http://developers.technorati.com/wiki/hCalendarIssues

Please discuss hCalendar and hCard issues with Tantek; I'm not planning on 
touching the relevant sections of WA1 until Tantek's drafts are much more 
stable. Unless there are good reasons not to do so, I plan to just take 
his specs wholesale (either by reference or by inclusion), when they are 
ready. There's not really any point in several different versions of these 
things being done at the same time!

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From mw at mattwright.com  Mon Feb 21 13:47:24 2005
From: mw at mattwright.com (Matt Wright)
Date: Mon, 21 Feb 2005 14:47:24 -0700
Subject: [whatwg] required attribute for checkbox/select
Message-ID: <000001c5185e$ee430810$6a00a8c0@msa>

Sorry if these items have already been discussed on the mailing list, but I
searched the archives and didn't see anything. I had a couple suggestions
for the required attribute (section 2.7) in Web Forms 2.0.

1) For checkboxes, wouldn't it would make more sense from a web applications
standpoint if this applied to a checkbox group like radio buttons currently
does?

	OLD: "For checkboxes, the required attribute shall only be satisfied
when the checkbox is checked."

	NEW: "For checkboxes, the required attribute shall only be satisfied
when one or more of the checkboxes in that checkbox group is checked."

If authors want the behavior currently specified in the draft, they simply
name that checkbox something different from all other fields in the form.

2) Why can't the required attribute apply to a select field?  It is common
for application designers to want to force the user to manually select an
option.  They will do something like <option value="">Please select a valid
option</option>. You could easily word the document to say that:

	NEW: "For select, the required attribute shall only be satisfied
when a non-empty option value is selected."

Or, you may not even need to re-word the document, but just remove select
from the list of unsupported controls, since the final catch-all of this
section explains "Any non-empty value satisfies the required condition,
including a simple whitespace character."

Thanks,

Matt Wright



From thingol at mail.ru  Mon Feb 21 14:37:15 2005
From: thingol at mail.ru (Roman Ivanov)
Date: Tue, 22 Feb 2005 01:37:15 +0300
Subject: [whatwg] Web Forms 2.0
Message-ID: <421A629B.2040409@mail.ru>

Hello.

I think that web developers really need a standard on working with 
selection in textarea and input type=text fields.

Now there's no standard that describes how to get starting point of 
selection, ending point of selection, and cursor position.
Also there's no standard that describes how to set selection and cursor 
position.

Now it can be done in Mozilla and MSIE but neither in Opera nor in Safari.

We'll make a great step into compatibility if Web Forms will contain 
such standard.

Thank you very much.

-- 
Roman Ivanov


From olav at olav.dk  Tue Feb 22 02:45:24 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 22 Feb 2005 11:45:24 +0100
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421A629B.2040409@mail.ru>
References: <421A629B.2040409@mail.ru>
Message-ID: <421B0D44.9040904@olav.dk>

Roman Ivanov wrote:
> I think that web developers really need a standard on working with 
> selection in textarea and input type=text fields.

Yes, that would be nice.
It has been discussed before:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001996.html

I think the best way would be if the value attribute of an input field 
could be treated as if it were text content of the element. Then the DOM 
Range spec (perhaps with some extensions) would cover how selections are 
treated.

Also, this would make editing input and textarea elements consistent 
with contentEditable, where the contents of an element is made directly 
editable.

Olav Junker Kj?r


From mattraymond at earthlink.net  Tue Feb 22 05:59:28 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 22 Feb 2005 08:59:28 -0500
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421B0D44.9040904@olav.dk>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
Message-ID: <421B3AC0.2020805@earthlink.net>

Olav Junker Kj?r wrote:
> Roman Ivanov wrote:
>>I think that web developers really need a standard on working with 
>>selection in textarea and input type=text fields.
> 
> Yes, that would be nice.
> It has been discussed before:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-August/001996.html

    Let's take a look:

| function getcaretpos(inp)
| {
|     // for mozilla
|     if(inp.selectionEnd)
|       return inp.selectionEnd;
|
|     // for IE
|     if(inp.createTextRange)
|     {
|       var docrange = document.selection.createRange();
|       var inprange = inp.createTextRange();
|       inprange.setEndPoint('EndToStart', docrange);
|       return inprange.text.length;
|     }
|
|     return inp.value.length; // other browsers don't provide a method 
|                              // that I know of
| }

    Man, what were the IE developers smoking when they came up with 
that?  The Mozilla method is waaaaaaaaaaaay easier.

> I think the best way would be if the value attribute of an input field 
> could be treated as if it were text content of the element. Then the DOM 
> Range spec (perhaps with some extensions) would cover how selections are 
> treated.

    Then you wouldn't be able to determine the original value of the 
|value| attribute, not to mention the fact that the value couldn't be 
restored to the default when you hit a reset button...

 From http://www.w3.org/TR/html4/interact/forms.html#reset-button:
| # reset buttons: When activated, a reset button resets all controls to
|   their initial values.

 From http://www.w3.org/TR/html4/interact/forms.html#initial-value:
| ...a control's "initial value" may be specified with the control
| element's value attribute.

    So, messing with the DOM wouldn't be smart.

    Another problem, though, is the fact that user agents would have to 
support Document Object Model Range. That may be assumed as a result of 
the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
that requires DOM Range.

    Another thing is that I don't like the idea of changing the behavior 
of a specific attribute based on the value of another attribute (type), 
especially when the behavior is already defined by previous specifications.

> Also, this would make editing input and textarea elements consistent 
> with contentEditable, where the contents of an element is made directly 
> editable.

    I think I know where you're going with this one. In theory, we could 
change the behavior based on the value of a new attribute like 
|contentEditable|. I'm not sure I like this solution for simple text 
selection, though. Mozilla's method is just so darn easy. Just 
.selectionStart and .selectionEnd. Easy as cake.


From olav at olav.dk  Tue Feb 22 07:26:39 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 22 Feb 2005 16:26:39 +0100
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421B3AC0.2020805@earthlink.net>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net>
Message-ID: <421B4F2F.2000100@olav.dk>

 >    So, messing with the DOM wouldn't be smart.

Yeah, it was probably a bad idea anyway. I just thought it would be 
consistent if editing always happened on element contents rather than on 
an attribute value. Especially in the case of textarea it seems a little 
unintuitive that it's the contents of the value attribute that is 
edited, rather than the element contents. But it would probably be a 
mess to try to change now.

Olav Junker Kj?r


From olav at olav.dk  Tue Feb 22 07:54:08 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Tue, 22 Feb 2005 16:54:08 +0100
Subject: [whatwg] Web Forms 2.0
In-Reply-To: <421B3AC0.2020805@earthlink.net>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net>
Message-ID: <421B55A0.6080401@olav.dk>

Matthew Raymond wrote:
>    Another problem, though, is the fact that user agents would have to 
> support Document Object Model Range. That may be assumed as a result of 
> the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
> that requires DOM Range.

I thought that selectionStart, selectionEnd and setSelectionRange() were 
part of the DOM Range, but they seem to be Mozilla-specific?

That means we have three different models for working with selections in 
input fields: the IE way, the Mozilla way, and DOM Range.

Since DOM Range is already a standard there seems to be no point in 
defining yet another standard in WHAT (except perhaps if the point was 
to standardize on the IE way for backwards compatibility?)

Anyway, I dont think selections should be part of WF2, but rather WA1 
where editing is defined, and I certainly think that the same interface 
should be used for handling editing in form controls and in elements 
with contentEditable.

Olav Junker Kj?r


From mattraymond at earthlink.net  Tue Feb 22 07:54:33 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Tue, 22 Feb 2005 10:54:33 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
Message-ID: <421B55B9.4050007@earthlink.net>

Ian Hickson wrote:
> On Mon, 21 Feb 2005, Matthew Raymond wrote:
>>There are several problems with hCalendar (and in turn, vCard): [...]
> 
> Tantek has asked me to point people to:
>   http://developers.technorati.com/wiki/hCalendarFAQ
>   http://developers.technorati.com/wiki/hCalendarIssues

    I appreciate his quick response to my email.

> Please discuss hCalendar and hCard issues with Tantek;

    Why? I have no intention of developing a Calendar/Card system for 
HTML5 outside of a public forum, and the Wikis are outside of my 
control. (Not that I question Tantek's integrity and dedication to 
standards. I just think it's a poor precedent to redirect conversations 
about WHATWG specifications to area's outside the control of WHATWG.) 
Furthermore, if you haven't noticed with some of Jim Ley's messages, 
there would be questions about fairness and tampering with the Wiki even 
if everything was on the up-and-up.

> I'm not planning on 
> touching the relevant sections of WA1 until Tantek's drafts are much more 
> stable.

    Why are we holding up the Calendar/Card portion of WA1 based 
entirely on the work of a single individual who is not a member of 
WHATWG? Granted, he's vastly more qualified than I am, but with regards 
to the WHATWG charter, he has no more authority than I do. Are we going 
to start carving up WHATWG specs and handing out pieces to specific 
individuals outside of the WHATWG for them to control?!? If someone who 
worked on Browser-X comes up with a menu system for WA1, do we just put 
everything on hold until he finishes that draft?!? Can't wait 'til Jim 
replies to this one!

> Unless there are good reasons not to do so, I plan to just take 
> his specs wholesale (either by reference or by inclusion), when they are 
> ready. There's not really any point in several different versions of these 
> things being done at the same time!

    Excuse me? There will always be several versions. It's called a 
difference of opinion. The whole point is to debate who's opinion is 
more valid until a clear, well-thought-out decision can be made. If you 
don't have that, then you have a specification developed by one, and 
WHATWG will quickly loose legitimacy.

    Might I also point out that the wikis you posted URLs to have NO 
COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
TECHNORATI. Who's to say his company won't just turn around and claim 
copyrights and patents to the whole mess?

    If you and Tantek want hCalendar and hCard as part of a WHATWG 
specification, you should post material here and allow people to comment 
on it publicly. A specific solution should not get special treatment 
regardless of who came up with it. I wouldn't mind seeing Tantek as a 
member of WHATWG personally, but freezing a portion of the spec so that 
a single individual can work on it completely outside of this working 
group is just wrong.

P.S.: I will be directing all my comments and ideas with regards to 
Calendar/Card markup to this mailing list only. I invite Tantek to do 
the same.


From ian at hixie.ch  Tue Feb 22 08:42:01 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 22 Feb 2005 16:42:01 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <421B55B9.4050007@earthlink.net>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>

On Tue, 22 Feb 2005, Matthew Raymond wrote:
>> 
>> Please discuss hCalendar and hCard issues with Tantek;
> 
> Why?

Because Tantek is the editor of those specs.


> I have no intention of developing a Calendar/Card system for HTML5 
> outside of a public forum, and the Wikis are outside of my control.

Neither do I. I don't intend to develop a Calendar/Card system for HTML5 
at all, in fact, since someone else is already working on a system for 
this. When it comes to editing that part of the WA1 spec, if there exist 
proposals that can just be imported wholesale, I would much rather do that 
than come up with yet another way of doing things.


> > I'm not planning on touching the relevant sections of WA1 until 
> > Tantek's drafts are much more stable.
> 
> Why are we holding up the Calendar/Card portion of WA1 based entirely on 
> the work of a single individual who is not a member of WHATWG?

We're not. WA1 is likely to become a huge spec. I expect to be quite busy 
doing lots of WA1 work for months. I hope that hCalendar and hCard will be 
stable once most of the rest of the WA1 spec is ready; if it is, then we 
will be able to re-use that work and save ourselves a lot of time and 
effort.


> Granted, he's vastly more qualified than I am, but with regards to the 
> WHATWG charter, he has no more authority than I do. Are we going to 
> start carving up WHATWG specs and handing out pieces to specific 
> individuals outside of the WHATWG for them to control?!? If someone who 
> worked on Browser-X comes up with a menu system for WA1, do we just put 
> everything on hold until he finishes that draft?!?

There's no "carving up" here; it's just a matter of not reinventing the 
wheel. You'll notice that the <canvas> part of WA1 is almost identical to 
the Apple implementation in early Tiger betas. This is not coincidental. 
Similarly, we're reusing much of the work that the HTML and DOM working 
groups have done over the past few years in terms of HTML and DOM errata. 
And we're using suggestions from www-html, Slashdot, and bug systems; not 
just in this mailing list.

I'm not saying that your suggestions on <calendar> aren't welcome; quite 
the opposite. However, at the moment, your suggestions would be best given 
to Tantek, since Tantek is actively working on this kind of work, and has 
studied the requirements in detail. I myself will not be working on the 
calendar and business card parts of the spec for a long time.

You are of course more than welcome to make independent proposals for 
including calendar data and "business card" data in HTML(5). If your 
proposals are technically superior to other proposals, then, once it comes 
to including a calendar mechanism in the WA1 spec, the WHATWG members 
(probably represented by me) will use your proposals.


> Might I also point out that the wikis you posted URLs to have NO 
> COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
> COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
> TECHNORATI. Who's to say his company won't just turn around and claim 
> copyrights and patents to the whole mess?

All good points to raise with Tantek.


> If you and Tantek want hCalendar and hCard as part of a WHATWG 
> specification, you should post material here and allow people to comment 
> on it publicly. A specific solution should not get special treatment 
> regardless of who came up with it. I wouldn't mind seeing Tantek as a 
> member of WHATWG personally, but freezing a portion of the spec so that 
> a single individual can work on it completely outside of this working 
> group is just wrong.

I hope this e-mail has clarified any misunderstandings; specifically, that 
comments are indeed welcome here, that Tantek's proposals aren't getting 
special treatment, and that the relevant parts of the spec aren't frozen.


> P.S.: I will be directing all my comments and ideas with regards to 
> Calendar/Card markup to this mailing list only. I invite Tantek to do 
> the same.

Tantek's proposals are also, as I understand it, aimed at areas that are 
out of scope for WHATWG, such as adding calendar metadata to existing 
HTML4 documents that can be processed by Web crawlers such as 
Technorati's. Thus I wouldn't be surprised if he did not feel it 
appropriate to do the work in this forum.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From bkn3 at columbia.edu  Tue Feb 22 14:39:47 2005
From: bkn3 at columbia.edu (Brad Neuberg)
Date: Tue, 22 Feb 2005 14:39:47 -0800
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
Message-ID: <6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>

At 11:53 AM 2/21/2005, Ian Hickson wrote:
>On Mon, 21 Feb 2005, Matthew Raymond wrote:
> >
> > There are several problems with hCalendar (and in turn, vCard): [...]
>
>Tantek has asked me to point people to:
>
>   http://developers.technorati.com/wiki/hCalendarFAQ
>   http://developers.technorati.com/wiki/hCalendarIssues
>
>Please discuss hCalendar and hCard issues with Tantek; I'm not planning on
>touching the relevant sections of WA1 until Tantek's drafts are much more
>stable. Unless there are good reasons not to do so, I plan to just take
>his specs wholesale (either by reference or by inclusion), when they are
>ready. There's not really any point in several different versions of these
>things being done at the same time!

Does this mean that you are thinking about possibily including hCalendar 
and hCard with the WA1 standard as a linked standard?

Best,
   Brad



>Cheers,
>--
>Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Brad Neuberg, bkn3 at columbia.edu
Senior Software Engineer, Rojo Networks
Weblog: http://www.codinginparadise.org

=====================================================================

Check out Rojo, an RSS and Atom news aggregator that I work on.  Visit 
http://rojo.com for more info. Feel free to ask me for an invite!

Rojo is Hiring!  If you're interested in RSS, Weblogs, Social Networking, 
Java, Open Source, etc... then come work with us at Rojo.  If you recommend 
someone and we hire them you'll get a free iPod!  See 
http://www.rojonetworks.com/JobsAtRojo.html. 



From ian at hixie.ch  Tue Feb 22 15:26:05 2005
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 22 Feb 2005 23:26:05 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>
Message-ID: <Pine.LNX.4.61.0502222322560.19631@dhalsim.dreamhost.com>

On Tue, 22 Feb 2005, Brad Neuberg wrote:
> 
> Does this mean that you are thinking about possibily including hCalendar 
> and hCard with the WA1 standard as a linked standard?

Yeah; as the spec mentions, in fact:

   http://whatwg.org/specs/web-apps/current-work/#calendars
   http://whatwg.org/specs/web-apps/current-work/#business

But of course if other proposals come along, those will be considered as 
well.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From mattraymond at earthlink.net  Wed Feb 23 08:53:43 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 23 Feb 2005 11:53:43 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
	<Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
Message-ID: <421CB517.1030307@earthlink.net>

Ian Hickson wrote:
> On Tue, 22 Feb 2005, Matthew Raymond wrote:
>>>Please discuss hCalendar and hCard issues with Tantek;
>>
>>Why?
> 
> Because Tantek is the editor of those specs.

     I fail to see how I could have a reasonable debate over whether
hCalendar/hCard should be included in a WHATWG spec without actually
holding such a discussion on the mailing list. Remember, I'm proposing a 
complete alternative to hCalendar and hCard, not a modification of it. A 
debate over competing proposals is outside the scope of any one proposal.

>>I have no intention of developing a Calendar/Card system for HTML5 
>>outside of a public forum, and the Wikis are outside of my control.
> 
> Neither do I. I don't intend to develop a Calendar/Card system for HTML5 
> at all, in fact, since someone else is already working on a system for 
> this. When it comes to editing that part of the WA1 spec, if there exist 
> proposals that can just be imported wholesale, I would much rather do that 
> than come up with yet another way of doing things.

     Why use it at all? If you want others to do the development of
calender/card markup for you, why not just drop it from WA1 entirely? 
The only thing WA1 introduces on top of hCalendar/hCard are the 
<calendar> and <card> container elements. Otherwise, it's pretty much 
straight from Tantek's spec, and there are no obvious dependencies in 
other parts of the WA1 spec. (Not that I don't think including 
calendar/card markup in WA1 is a good idea...)

    Alternatively, why not just break WA1 into sections or modules (i.e. 
"Web Applications 1.0 - iCalendar Mappings"), sorta like CSS3, and 
develop each module individually? (I'll leave it up to you as to how to 
submit WA1 to standards organizations. You may want to submit all 
sections together to avoid breaking dependencies between them, or 
perhaps one at a time so that any one has a better chance of getting 
through.)

>>>I'm not planning on touching the relevant sections of WA1 until 
>>>Tantek's drafts are much more stable.
>>
>>Why are we holding up the Calendar/Card portion of WA1 based entirely on 
>>the work of a single individual who is not a member of WHATWG?
> 
> We're not. WA1 is likely to become a huge spec. I expect to be quite busy 
> doing lots of WA1 work for months. I hope that hCalendar and hCard will be 
> stable once most of the rest of the WA1 spec is ready; if it is, then we 
> will be able to re-use that work and save ourselves a lot of time and 
> effort.

    Reuse is fine so long as everyone agrees that a particular solution 
is the best or most practical. What concerns me is that I don't have a 
nice little wiki to post my ideas to or organize my thoughts with, 
whereas Tantek has his company's developer site, so I'm at a 
disadvantage. Since I and other WHATWG contributors don't have our own 
wiki, even if myself and other contributers find a better solution, you 
aren't going to put it into the WA1 spec until Tantek says he's done 
with his project.

    A good example are those two links you posted:

    http://developers.technorati.com/wiki/hCalendarFAQ
    http://developers.technorati.com/wiki/hCalendarIssues

    In both, Tantek is directly replying to a message I posted in this 
list, and he can add and change material over time to better support his 
position. Not that I think he shouldn't be able to do this. In fact, 
I've been asking for a WHATWG wiki for quite some time. Right now, 
sadly, the "XUL Alliance" does a better job of providing such resources.

    Anyone know a good free Wiki site, by the way?

    Oh, one other thing. If you're going to like to a spec, the page 
should be static, not a wiki. Otherwise, you could inadvertently allow 
anyone and their mother to change part of a WHATWG spec at will.

>>Granted, he's vastly more qualified than I am, but with regards to the 
>>WHATWG charter, he has no more authority than I do. Are we going to 
>>start carving up WHATWG specs and handing out pieces to specific 
>>individuals outside of the WHATWG for them to control?!? If someone who 
>>worked on Browser-X comes up with a menu system for WA1, do we just put 
>>everything on hold until he finishes that draft?!?
> 
> There's no "carving up" here; it's just a matter of not reinventing the 
> wheel. You'll notice that the <canvas> part of WA1 is almost identical to 
> the Apple implementation in early Tiger betas. This is not coincidental. 
> Similarly, we're reusing much of the work that the HTML and DOM working 
> groups have done over the past few years in terms of HTML and DOM errata. 
> And we're using suggestions from www-html, Slashdot, and bug systems; not 
> just in this mailing list.

    Much of the stuff you just mentioned was already implemented in a 
browser of some sort or approved by a standards organization. Tantek is 
not a standards organization, and as far as I know, hCalendar and hCard 
have not been implemented in a browser. In fact, after reading the spec 
more closely, it looks more like it's designed for automated extraction 
of information by webcrawlers rather than for actual calender controls 
and the like.

> I'm not saying that your suggestions on <calendar> aren't welcome; quite 
> the opposite. However, at the moment, your suggestions would be best given 
> to Tantek, since Tantek is actively working on this kind of work, and has 
> studied the requirements in detail. I myself will not be working on the 
> calendar and business card parts of the spec for a long time.

    Actually, you gave a specific time you'd be working on it...

    "I'm not planning on touching the relevant sections of WA1 until 
Tantek's drafts are much more stable."

    So if the above is the case, I wouldn't be able to get anything 
regarding calendars or cards considered for inclusion in the 
specification until Tantek decides to complete his hCalendar and hCard 
specs, both of which date back to mid October of last year.

> You are of course more than welcome to make independent proposals for 
> including calendar data and "business card" data in HTML(5).

    Why would anyone do that if the guy editing the target spec is going 
to ignore them for a period of time determined by a third party? It's 
one thing to be too busy to work on it at a given moment, but it's 
another thing to say that you definitely WON'T work on it until someone 
else is ready.

 > If your
> proposals are technically superior to other proposals, then, once it comes 
> to including a calendar mechanism in the WA1 spec, the WHATWG members 
> (probably represented by me) will use your proposals.

    When will that be? When you're ready, or when Tantek is? (No offense 
to Tantek. This is an argument of procedure rather than character.)

>>Might I also point out that the wikis you posted URLs to have NO 
>>COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
>>COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
>>TECHNORATI. Who's to say his company won't just turn around and claim 
>>copyrights and patents to the whole mess?
> 
> All good points to raise with Tantek.

    Not if you're linking to them through the WA1 spec. Once something 
becomes part of a WHATWG spec, these concerns become _your_ problem. 
(Although, if anything Tantek posts on the wiki becomes part of the 
WHATWG spec, there's the same issue, since he's already posted it... Has 
nothing to do with my method, though, since I use a different approach.)

>>If you and Tantek want hCalendar and hCard as part of a WHATWG 
>>specification, you should post material here and allow people to comment 
>>on it publicly. A specific solution should not get special treatment 
>>regardless of who came up with it. I wouldn't mind seeing Tantek as a 
>>member of WHATWG personally, but freezing a portion of the spec so that 
>>a single individual can work on it completely outside of this working 
>>group is just wrong.
> 
> I hope this e-mail has clarified any misunderstandings; specifically, that 
> comments are indeed welcome here, that Tantek's proposals aren't getting 
> special treatment, and that the relevant parts of the spec aren't frozen.

    If you're waiting on Tantek to finish his spec BEFORE working on the 
Calendar/Card section of WA1, that's special treatment. I doubt I could 
hold up portions of a WHATWG specification in a similar way.

>>P.S.: I will be directing all my comments and ideas with regards to 
>>Calendar/Card markup to this mailing list only. I invite Tantek to do 
>>the same.
> 
> Tantek's proposals are also, as I understand it, aimed at areas that are 
> out of scope for WHATWG, such as adding calendar metadata to existing 
> HTML4 documents that can be processed by Web crawlers such as 
> Technorati's. Thus I wouldn't be surprised if he did not feel it 
> appropriate to do the work in this forum.

    Actually, I was wondering if that was the case earlier, and looking 
at the spec now, I'm even more inclined to believe that...

    Hmm. I'm wondering if a calendar control might not be in order. 
Something like this:

| <input type="calendar" name="calendar1" data="myCalendar.ics">

    ..And for a version with fallback (just to annoy you ;) )...

| <dataentry type="calendar" name="calendar1" data="myCalendar.ics">
|  <div class="vcalendar">
|   <div class="vevent" id="events" repeat="template">
|    <p>
|     <label>URL:
|      <input type="text" class="url"
|             name="calendar1.event[events].url"
|             value="http://www.web2con.com/">
|     </label><br>
|     <label>Start Date:
|      <input type="text" class="dtstart"
|             name="calendar1.event[events].dtstart" value="2005-10-05">
|     </label><br>
|      <label>End Date:
|      <input type="text" class="dtend"
|             name="calendar1.event[events].dtend" value="2005-10-07">
|     </label><br>
|     <label>Summary:
|      <input type="text" class="summary"
|             name="calendar1.event[events].summary"
|             value="Web 2.0 Conference">
|     </label>
|    </p>
|    <p><button type="remove">Remove Event</button></p>
|   </div>
|   <p><button type="add" template="event">Add Event</button></p>
|   <p><button type="submit">Submit</button></p>
|  </div>
| </dataentry>

    The above degrades into WF2, and then into HTML 4.01, while using 
hCalendar.

    Not sure we need something as specific as a calendar control, 
though. There may not be a use case for it. Then again, if webmail 
programs become more like Outlook and combine scheduling with email, 
there may be a significant use case for this.


From olav at olav.dk  Wed Feb 23 12:24:09 2005
From: olav at olav.dk (=?ISO-8859-1?Q?Olav_Junker_Kj=E6r?=)
Date: Wed, 23 Feb 2005 21:24:09 +0100
Subject: [whatwg] WF2 section A
In-Reply-To: <Pine.LNX.4.61.0502222322560.19631@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>	<4219DAE3.8080604@earthlink.net>	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>	<6.2.1.2.2.20050222143923.0259c6e0@pop.mail.yahoo.com>
	<Pine.LNX.4.61.0502222322560.19631@dhalsim.dreamhost.com>
Message-ID: <421CE669.6030209@olav.dk>

A few more editorial nits concerning WF2 section A:

- it does not say that "onformchange" and "onforminput" attributes are 
added to the "form" element, but I assume that this is the case?

- it says that the "oninvalid" attribute is added to all form controls 
except "output" elements. This implies that it is added to "button" 
elements, which I assume is a bug (since "button" elements can't be 
invalid)?

In section 7.12 it says
 > the changed event fired by the dispatchFormChanged() method...
I assume this should be "the *change* event..."


The HTMLFormElement has the dispatchFormChange() method while the 
corresponding method on form controls is called dispatchFormChanged() 
(with a "d"). However in section 7.12 the method on HTMLFormElement is 
called dispatchFormChanged() (with a "d").

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Wed Feb 23 14:18:11 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 23 Feb 2005 17:18:11 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421B55A0.6080401@olav.dk>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net> <421B55A0.6080401@olav.dk>
Message-ID: <421D0123.8050202@earthlink.net>

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
> 
>>   Another problem, though, is the fact that user agents would have to 
>>support Document Object Model Range. That may be assumed as a result of 
>>the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
>>that requires DOM Range.
> 
> I thought that selectionStart, selectionEnd and setSelectionRange() were 
> part of the DOM Range, but they seem to be Mozilla-specific?

     Looks like it. I'd prefer the Mozilla method for form controls, though.

> That means we have three different models for working with selections in 
> input fields: the IE way, the Mozilla way, and DOM Range.

     Yeah, but from the little bit I've read of the IE method, I hear it
sucks.

> Since DOM Range is already a standard there seems to be no point in 
> defining yet another standard in WHAT (except perhaps if the point was 
> to standardize on the IE way for backwards compatibility?)

    DOM Range doesn't appear to have anything to do with actual GUI 
selection. It merely states that you can use a Range DOM object to 
represent the selection. From 
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html:

    "The term 'selecting' does not mean that every Range corresponds to 
a selection made by a GUI user; however, such a selection can be 
returned to a DOM user as a Range."

    So you see, if we want to establish a GUI selection interface for 
DOM/Javascript, we can use DOM Range as PART of the interface, but we 
still have to define some way of getting the current selection and 
setting the user selection. I'm thinking something like this:

| var myRange = document.getSelection();

    The above gets the current selection within the document. If the 
document doesn't have a selection, it returns document.createRange(). 
Similarly, there will be a setSelection method:

| document.setSelection(myRange);

    If you wish to deselect everything in the document, you could do the 
following:

| document.removeSelection();

    If you want to select a specific element, you'd do something like this:

| var myRange = document.createRange();
| var myElement = document.getElementById('myID');
|
| myRange.selectNode(myElement);
| document.setSelection(myRange);

    Do we need a way of maintaining multiple user selections? I don't 
think IE supports this. Also, do we need execCommand if we're using DOM 
Range? It would seem to me that you could just use surroundContents, 
etc. for something for some of this stuff, but that might get 
complicated. If anyone wants to chime in on these issues, feel free.

     Near as I can determine, though, DOM Range can't change attributes,
so it would be useless for use with <input>, even if the |value| 
attribute was always equal to the .value property. It doesn't really 
matter, though. With the Mozilla method, you need only find the <input> 
node and set two values to set the selection. In DOM Range, you have to 
create a Range object, feed the element node to .selectNodeContents, 
then change the start and end offsets, so you have two extra steps. 
Therefore, the Mozilla method would win even if the text was in the DOM.

> Anyway, I dont think selections should be part of WF2, but rather WA1 
> where editing is defined,

     Agreed.

 > and I certainly think that the same interface
> should be used for handling editing in form controls and in elements 
> with contentEditable.

    No. The whole idea behind |contentEditable| is that you're changing 
the DOM. The values of <input> and <textarea> may be copies of values 
set in markup, but the actual value in a control is never truly in the 
DOM. For controls like <input> and <textarea>, I prefer the Mozilla 
method anyways. It's much simpler and people don't have to understand 
DOM Range to use it, which is good in situations like this since dealing 
with selections within controls is more common.

    Question: Should any element with |contentEditable| be submitted if 
it's within a <form> and has a |name| attribute?


From mpt at myrealbox.com  Wed Feb 23 16:10:51 2005
From: mpt at myrealbox.com (Matthew Thomas)
Date: Wed, 23 Feb 2005 19:10:51 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D0123.8050202@earthlink.net>
References: <421A629B.2040409@mail.ru> <421B0D44.9040904@olav.dk>
	<421B3AC0.2020805@earthlink.net> <421B55A0.6080401@olav.dk>
	<421D0123.8050202@earthlink.net>
Message-ID: <f9dcd5f7b0d1d6986b7dbdded3698d80@myrealbox.com>

On 23 Feb, 2005, at 5:18 PM, Matthew Raymond wrote:
> ...
>    So you see, if we want to establish a GUI selection interface for 
> DOM/Javascript, we can use DOM Range as PART of the interface, but we 
> still have to define some way of getting the current selection and 
> setting the user selection. I'm thinking something like this:
>
> | var myRange = document.getSelection();

That seems harmless ...

>    The above gets the current selection within the document. If the 
> document doesn't have a selection, it returns document.createRange(). 
> Similarly, there will be a setSelection method:
>
> | document.setSelection(myRange);
>
>    If you wish to deselect everything in the document, you could do 
> the following:
>
> | document.removeSelection();
> ...

.... But those two, unfortunately, seem more likely to be abused than 
usefully used. Annoying authors would repeatedly clear any selection in 
a misguided attempt to prevent people from copying text, more often 
than application authors would use those functions for legitimate 
purposes. (Yes, you could work around this by turning off JavaScript, 
but that would work only for the small proportion of users who 
understand what's causing the problem.)

I know that authors can be annoying no matter what you give them (for 
example, displaying text as graphics), but I think this would make 
being annoying far too easy.

-- 
Matthew Thomas
http://mpt.net.nz/



From olav at olav.dk  Wed Feb 23 16:33:15 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 01:33:15 +0100
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D0123.8050202@earthlink.net>
References: <421A629B.2040409@mail.ru>
	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>
	<421B55A0.6080401@olav.dk> <421D0123.8050202@earthlink.net>
Message-ID: <421D20CB.3070009@olav.dk>

Matthew Raymond wrote:
 > So you see, if we want to establish a GUI selection interface for
 > DOM/Javascript, we can use DOM Range as PART of the interface, but we
 > still have to define some way of getting the current selection and
 > setting the user selection.

Okay. I get it. Mozilla seem to support something similar (also 
non-standard) to get from a selection to a DOM range:
http://www.mozilla.org/docs/dom/domref/dom_window_ref24.html#1000044
While I like your proposal, I think we should choose one of the 
currently implemented methods (IE's or Mozillas) unless they have 
serious shortcomings.

 > Yeah, but from the little bit I've read of the IE method, I hear it
 > sucks.

Well, it doesn't provide a way to get the start or end points of a 
selection, which is what the original poster wanted.
It works like this: the document has a "selection" property which 
represents the current selection. On the selection object you can call 
createRange() to create a TextRange object which is more or less similar 
to a DOM Range object (although more limited). Also, you can turn a 
TextRange into the current selected by calling the select() method on it.
It works the same way for input values, textarea values, and ordinary 
content.

 > Near as I can determine, though, DOM Range can't change attributes,
 > so it would be useless for use with <input>, even if the |value|
 > attribute was always equal to the .value property.

The DOM Range spec claims that it works on Attr-nodes also.

 > Do we need a way of maintaining multiple user selections? I don't
 > think IE supports this.

The API suggest that it does (there is a createRangeCollection() 
method), but I'm not sure this actually works.

 > Also, do we need execCommand if we're using DOM Range?

The important thing is to have contentEditable and an interface to 
manipulate the current selection. Then execCommand can be built on top 
of that in script. (The execCommand interface in IE is cool though, 
because it supports undo. Except that the undo history is cleared when 
any DOM manipulation is done using any other method than execCommand, 
which limits its usefulness).

 > I prefer the Mozilla
 > method anyways. It's much simpler and people don't have to understand
 > DOM Range to use it, which is good in situations like this since
 > dealing with selections within controls is more common.

But one interface is simpler that two interfaces, and we need DOM Range 
(or something similar) anyway to do rich editing, which is arguably just 
as common an use case.

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Wed Feb 23 20:10:40 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Wed, 23 Feb 2005 23:10:40 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D20CB.3070009@olav.dk>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>
	<421D0123.8050202@earthlink.net> <421D20CB.3070009@olav.dk>
Message-ID: <421D53C0.6040209@earthlink.net>

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
>  > So you see, if we want to establish a GUI selection interface for
>  > DOM/Javascript, we can use DOM Range as PART of the interface, but we
>  > still have to define some way of getting the current selection and
>  > setting the user selection.
> 
> Okay. I get it. Mozilla seem to support something similar (also 
> non-standard) to get from a selection to a DOM range:
> http://www.mozilla.org/docs/dom/domref/dom_window_ref24.html#1000044
> While I like your proposal, I think we should choose one of the 
> currently implemented methods (IE's or Mozillas) unless they have 
> serious shortcomings.

    The Mozilla getSelection method doesn't actually return a DOM Range, 
though, so I'm inclined to pass on it, even though we're introducing 
window in WA1. It just strikes me as too complicated; it introduces a 
completely new selection object, multiple ranges, et cetera...

    Then again, if you have a really good argument for it, I'm willing 
to  hear it.

>  > Yeah, but from the little bit I've read of the IE method, I hear it
>  > sucks.
> 
> Well, it doesn't provide a way to get the start or end points of a 
> selection, which is what the original poster wanted.
> It works like this: the document has a "selection" property which 
> represents the current selection. On the selection object you can call 
> createRange() to create a TextRange object which is more or less similar 
> to a DOM Range object (although more limited). Also, you can turn a 
> TextRange into the current selected by calling the select() method on it.
> It works the same way for input values, textarea values, and ordinary 
> content.

    Matthew Thomas was worried that allowing webmasters to alter 
selections with setSelection or removeSelection would create situations 
where webmasters would intentionally prevent users from selecting stuff. 
As a result, I think he'd oppose a model that supports setting the 
selection outside a control, which makes the IE selection model not 
terribly useful.

>  > Near as I can determine, though, DOM Range can't change attributes,
>  > so it would be useless for use with <input>, even if the |value|
>  > attribute was always equal to the .value property.
> 
> The DOM Range spec claims that it works on Attr-nodes also.

    /me shrugs.

    Okay. I just skimmed the spec, so maybe it does. Doesn't really 
matter, though, because the .value property is still not the same as the 
|value| attribute or the contents of a <textarea> element, and changing 
that would break the specification of the reset button. (In theory, you 
may actually want to change the initial value of a control in the DOM so 
that when someone hits a reset button, the new initial value is put into 
the control instead of the old one, so saving the initial value outside 
the DOM may not be an option.)

    Then again, there's a .defaultValue property. Form reset could be 
defined in such a way as to use that property as the initial value 
instead of the contents of the DOM. However, the DOM content is defined 
as the initial value in the HTML 4.01 spec, so does changing the DOM in 
some browsers change the corresponding value of .defaultValue???

    What's certain is that linking the .value property with the markup 
for the initial value would directly contradict portions of the DOM2 spec.

 From http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485:

    "Changing this attribute changes the contents of the form control, 
but does not change the value of the HTML value attribute of the element."

 From http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-70715579:

    "Changing this attribute changes the contents of the form control, 
but does not change the contents of the element."

    So would this be considered breaking backwards compatibility, since 
the opposite of the proposed behavior is defined in the spec?

>  > Do we need a way of maintaining multiple user selections? I don't
>  > think IE supports this.
> 
> The API suggest that it does (there is a createRangeCollection() 
> method), but I'm not sure this actually works.

    Perhaps we should change getSelection to getSelections and have it 
return a collection of ranges... Hmm...

>  > Also, do we need execCommand if we're using DOM Range?
> 
> The important thing is to have contentEditable and an interface to 
> manipulate the current selection. Then execCommand can be built on top 
> of that in script. (The execCommand interface in IE is cool though, 
> because it supports undo. Except that the undo history is cleared when 
> any DOM manipulation is done using any other method than execCommand, 
> which limits its usefulness).

    Well, the question, though, is whether or not DOM Range provides 
enough of an interface. In theory, you could do everything you need to, 
but in reality the scripting could get so complex that you're rather 
just use a built-in method like execCommand.

>  > I prefer the Mozilla
>  > method anyways. It's much simpler and people don't have to understand
>  > DOM Range to use it, which is good in situations like this since
>  > dealing with selections within controls is more common.
> 
> But one interface is simpler that two interfaces, and we need DOM Range 
> (or something similar) anyway to do rich editing, which is arguably just 
> as common an use case.

    The real problem is that DOM Range is largely useless for selections 
that consist entirely of a string of text obtained through the .value 
property. All I need to know is the start and end points within the 
string and I can make any changes I want using simple string 
manipulation. So there's really never a situation where you NEED 
something as complicated as DOM Range for a simple text control. Never 
mind the fact that the value you're talking about doesn't exist in the 
DOM in the first place. There's also the problem of DOM Ranges requiring 
Nodes to define their start and end points. If .value isn't in the DOM, 
what would the parent node be?

    No, better to have two systems, since we're essentially dealing with 
two kinds of content. DOM Range is a lot harder to learn anyways, so 
after that the Mozilla method should be as easy as cake.


From olav at olav.dk  Thu Feb 24 02:04:23 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 11:04:23 +0100
Subject: [whatwg] Value attribute (was: Re: [WA1] GUI Selections)
In-Reply-To: <421D53C0.6040209@earthlink.net>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>
	<421D20CB.3070009@olav.dk> <421D53C0.6040209@earthlink.net>
Message-ID: <421DA6A7.5000105@olav.dk>

 > Okay. I just skimmed the spec, so maybe it does. Doesn't really
 > matter, though, because the .value property is still not the same as
 > the |value| attribute or the contents of a <textarea> element,

Regarding the "value" property in the DOM, I think it's a bit confusing, 
but this is how I understand it:

The "value" property in the DOM reflects the current state of the input 
control in the UA. If the user edits the content of the input field, the 
DOM "value" property is updated.
However the contents of the "value" attribute in the original HTML 
source  is represented by the "defaultValue" DOM attribute. (This is 
also the initial value of the "value" attribute in the DOM). This is 
important for the reset button, but especially important if you are 
*editing* a HTML document rather than browsing it. When the document is 
serialized back to HTML by the editor, the "value" attribute in the HTML 
is generated from the "defaultValue" DOM attribute. OTOH the "value" DOM 
property is not serialized (and typically you won't change that in an 
editor anyway).

Think of it as currentValue and defaultValue. Both exists in the DOM, 
but only defaultValue is represented in the HTML source. The confusing 
part is that in HTML defaultValue is called "value", while in the DOM it 
is currentValue that is called "value".

Anyway, editing the value of an input field does change the DOM "value" 
attribute, but does not change the "value" content attribute in the 
underlying HTML.

regards
Olav Junker Kj?r


From olav at olav.dk  Thu Feb 24 03:47:01 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 12:47:01 +0100
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D53C0.6040209@earthlink.net>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>
	<421D20CB.3070009@olav.dk> <421D53C0.6040209@earthlink.net>
Message-ID: <421DBEB5.7080800@olav.dk>

Matthew Raymond wrote:
>    The Mozilla getSelection method doesn't actually return a DOM Range, 
> though, so I'm inclined to pass on it, even though we're introducing 
> window in WA1. It just strikes me as too complicated; it introduces a 
> completely new selection object, multiple ranges, et cetera...

This is like the IE model: a selection is is separate object, which may 
contain one ore more ranges. At least in IE this indirection is 
necessary since a the selection can be discontinuous e.g. several 
pictures different places in the same document (selected while holding 
the ctrl key down).

IE distinguishes between "text selection" and "control selection". 
Images, input controls, tables and absolutely positioned elements may be 
individually control-selected, which enables you to move end resize 
them. Continuous ranges of text (including objects) may be 
text-selected, but as far as I know, only one continuous text range can 
be selected at a time.
I don't know if Mozilla has a similar distinction?

Anyway, I agree this seem like overkill if you just want to manipulate 
the selection in a text-box. It might be useful to have some convenience 
methods to get the start and end points of a the current selection in a 
input field without having to walk through the selection and range objects.


>    Well, the question, though, is whether or not DOM Range provides 
> enough of an interface. In theory, you could do everything you need to, 
> but in reality the scripting could get so complex that you're rather 
> just use a built-in method like execCommand.

True. The execCommand encapsulates quite a bit of complexity. The 
problem with the IE version is that it is a black box. You cannot modify 
how a command works, you cannot create your own commands, and if you 
work outside of the box (and directly through the DOM), the undo history 
(which is the killer feature) is cleared. If WA1 should include 
execCommand, it should be a more general framework, which should allow 
you to create your own undoable commands. In the end this gets rather 
complicated.

It does make sense though, to standardize the execCommand interface, 
since lots of CMS frontends rely on contentEditable+execCommand, and 
this is an area where IE have a stronghold, since its still the only 
browser (as far as I know) that support contentEditable.

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Thu Feb 24 04:27:21 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 24 Feb 2005 07:27:21 -0500
Subject: [whatwg] Value attribute
In-Reply-To: <421DA6A7.5000105@olav.dk>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>	<421D20CB.3070009@olav.dk>
	<421D53C0.6040209@earthlink.net> <421DA6A7.5000105@olav.dk>
Message-ID: <421DC829.5090505@earthlink.net>

Olav Junker Kj?r wrote:
[Snip!]
> Think of it as currentValue and defaultValue. Both exists in the DOM, 
> but only defaultValue is represented in the HTML source. The confusing 
> part is that in HTML defaultValue is called "value", while in the DOM it 
> is currentValue that is called "value".
> 
> Anyway, editing the value of an input field does change the DOM "value" 
> attribute, but does not change the "value" content attribute in the 
> underlying HTML.

    In general, if you set a DOM property, it won't set the actual 
attribute in markup. In order to change the markup, I think you have to 
use the setAttribute method. However, I believe that the setAttribute 
method does change the DOM property.

    Internet Explorer, as I understand, completely ignores this and 
always makes a property and the corresponding attribute the same. In 
other words, IE is aspec.


From ian at hixie.ch  Thu Feb 24 04:51:58 2005
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 24 Feb 2005 12:51:58 +0000 (UTC)
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <421CB517.1030307@earthlink.net>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
	<Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
	<421CB517.1030307@earthlink.net>
Message-ID: <Pine.LNX.4.61.0502241226420.25653@dhalsim.dreamhost.com>


Boy did this get out of hand.

Matthew. I encourage you to send your proposals to this mailing list. The 
e-mail you sent with your proposal is still in my queue, along with all 
the other WA1 and WF2 proposals that have been sent and have not yet 
received technical replies. It will be given the same consideration as all 
the other proposals, including Tantek's and anything else I (or whoever 
the spec editor is at that time) come across.

There is no conspiracy here. Please relax. The only reason I suggested 
contacting Tantek is because I know he's been working on this topic, that 
he has some very good ideas, and that he is welcoming feedback. I would 
have thought that working with him on a proposal would have been more 
productive than working on independent proposals. However, that was merely 
a suggestion and was not meant to imply that other proposals would be 
ignored or given a different level of consideration.

In particular, please don't think that I will be swayed by flashy 
graphics, fancy markup, diagrams, or wiki-based development. At the end of 
the day I'm just looking at technical ideas on their technical merit, 
regardless of who came up with them and how they were presented. Some of 
the things in WF2 were originally just doodles people left on my 
whiteboard, others were formal proposals that went through the W3C or IETF 
recommendation tracks.

Also, progress on WHATWG specs is going at its own rate, and is not 
controlled by progress on external drafts or proposals.


On Wed, 23 Feb 2005, Matthew Raymond wrote:
> 
> In fact, I've been asking for a WHATWG wiki for quite some time.

I don't have the resources to set that up, but if you want to set up a 
wiki.whatwg.org site I could get you an account. However, I'm not really 
sure what the point is. As far as I'm concerned this mailing list is the 
most convenient way for me to handle input. I wouldn't monitor a wiki (or 
probably even look at it) if one was created.


> Oh, one other thing. If you're going to like to a spec, the page should 
> be static, not a wiki. Otherwise, you could inadvertently allow anyone 
> and their mother to change part of a WHATWG spec at will.

I do not intend to normatively reference easily editable resources. The 
links are currently purely informative to give people an idea of what was 
being considered when that part of the spec was written.


> Actually, you gave a specific time you'd be working on it...
> 
> "I'm not planning on touching the relevant sections of WA1 until 
> Tantek's drafts are much more stable."

I spoke ambiguously, my apologies. What I meant was that by the time I 
next touched those sections, I expected Tantek's drafts to be much more 
stable. (In particular, I am currently prioritising folding HTML4, XHTML1, 
and DOM2 HTML into WA1, adding the section on the Window interface, and 
speccing the new interfaces for networking and messaging. There is a LOT 
of work there.)


> > If your proposals are technically superior to other proposals, then, 
> > once it comes to including a calendar mechanism in the WA1 spec, the 
> > WHATWG members (probably represented by me) will use your proposals.
> 
> When will that be? When you're ready, or when Tantek is? (No offense to 
> Tantek. This is an argument of procedure rather than character.)

When I, or whoever is editing the spec, is ready.


> > > Might I also point out that the wikis you posted URLs to have NO 
> > > COPYRIGHT NOTICES, NO OBVIOUS LINKS TO A COPYRIGHT POLICY and NO 
> > > COPYRIGHT METADATA, and that the domain is that of THE COMPANY 
> > > TECHNORATI. Who's to say his company won't just turn around and 
> > > claim copyrights and patents to the whole mess?
> > 
> > All good points to raise with Tantek.
> 
> Not if you're linking to them through the WA1 spec.

Whatever becomes the calendar/card section of WA1, I expect it to be 
completely defined in the WA1 spec, not reference an external spec. 
(Except if the definition is in terms of an external data model, such as 
an alternate serialisation of vCard -- in that case, the serialisation and 
interpretation would be in WA1, but the data model and semantics would be 
in the external spec.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From olav at olav.dk  Thu Feb 24 06:18:16 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 15:18:16 +0100
Subject: [whatwg] Value attribute
In-Reply-To: <421DC829.5090505@earthlink.net>
References: <421A629B.2040409@mail.ru>	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>	<421B55A0.6080401@olav.dk>	<421D0123.8050202@earthlink.net>	<421D20CB.3070009@olav.dk>	<421D53C0.6040209@earthlink.net>
	<421DA6A7.5000105@olav.dk> <421DC829.5090505@earthlink.net>
Message-ID: <421DE228.60502@olav.dk>

Matthew Raymond wrote:
>    In general, if you set a DOM property, it won't set the actual 
> attribute in markup. In order to change the markup, I think you have to 
> use the setAttribute method. However, I believe that the setAttribute 
> method does change the DOM property.

Did a quick test: In Mozilla, IE and Opera setting an ordinary attribute 
through a DOM property seems to be equivalent to using setAttribute. The 
"value" property is handled differently though. In IE and Opera 
getAttribute("value") returns the same as the "value" DOM property, 
while in Mozilla it returns the same as the defaultValue property (which 
is the correct behavior, I think). However, using innerHTML in Opera 
seem to serialize the element correctly by using the defaultValue 
property as at content of the value HTML, as does Mozilla.

Anyway, your original statment that DOM Range couldn't work on the 
current value in an input field seems to be correct. The DOM Range may 
work on an Attr node but not any DOM attribute. The current value is in 
the DOM in the form of an property, but not in the form of a DOM Attr node.

regards
Olav


From olav at olav.dk  Thu Feb 24 07:36:43 2005
From: olav at olav.dk (=?UTF-8?B?T2xhdiBKdW5rZXIgS2rDpnI=?=)
Date: Thu, 24 Feb 2005 16:36:43 +0100
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421D0123.8050202@earthlink.net>
References: <421A629B.2040409@mail.ru>
	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>
	<421B55A0.6080401@olav.dk> <421D0123.8050202@earthlink.net>
Message-ID: <421DF48B.10103@olav.dk>

Matthew Raymond wrote:
> | var myRange = document.getSelection();
> 
>    The above gets the current selection within the document. If the 
> document doesn't have a selection, it returns document.createRange(). 
> Similarly, there will be a setSelection method:

You assume that the selection is a property of the document. This is 
like IE, while in Mozilla its a propery of the window (if I understand 
the API correctly).

I think it makes most sense to have the selection be a property of the 
viewport i.e. the window object. If we consider two frames containing 
two different views of the same document (this is theoretically possible 
according to the dom spec), it would seem natural to allow different 
focus and selections in each view. (If e.g. an HTML editor allowed two 
different wiews on the same page while editing, this would matter.)

Btw. the DocumentFocus interface in WA1 (section 11.3) also seem to 
assume that focus is a propery of the document rather than the viewport. 
Again I think its more correct to have it a property of the viewport.

regards
Olav Junker Kj?r


From mattraymond at earthlink.net  Thu Feb 24 08:10:27 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 24 Feb 2005 11:10:27 -0500
Subject: [WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
In-Reply-To: <421DF48B.10103@olav.dk>
References: <421A629B.2040409@mail.ru>
	<421B0D44.9040904@olav.dk>	<421B3AC0.2020805@earthlink.net>
	<421B55A0.6080401@olav.dk> <421D0123.8050202@earthlink.net>
	<421DF48B.10103@olav.dk>
Message-ID: <421DFC73.2060800@earthlink.net>

Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
>>| var myRange = document.getSelection();
>>
>>   The above gets the current selection within the document. If the 
>>document doesn't have a selection, it returns document.createRange(). 
>>Similarly, there will be a setSelection method:
> 
> You assume that the selection is a property of the document. This is 
> like IE, while in Mozilla its a propery of the window (if I understand 
> the API correctly).

    That's my understanding too, though I'm hardly an expert.

> I think it makes most sense to have the selection be a property of the 
> viewport i.e. the window object.

    Yeah, I was mainly trying to avoid breaking existing Mozilla scripts 
using window.getSelection. I suppose we could just rename the thing 
"getSelectionRange", though. The main question is whether we care about 
multiple selections and the like. Perhaps we could have 
getSelectionRange return the first selection in the part of the viewport 
that has focus...

> If we consider two frames containing 
> two different views of the same document (this is theoretically possible 
> according to the dom spec), it would seem natural to allow different 
> focus and selections in each view.

    Depends on whether the viewports are actually using the same 
document object. If each viewport has it's own document object that 
happens to be created from the same document, then the selections could 
just be obtained from the document object. I think that's the case when 
you open the same page in two different browser windows.

    I do see your point, though. For instance, two people could be 
viewing a web page together over some kind of conferencing software, in 
which case they could each be selecting something different in their own 
viewports but sharing the same document object.

> (If e.g. an HTML editor allowed two 
> different wiews on the same page while editing, this would matter.)

    Bad example. You wouldn't want to be running script on the DOM at 
the same time you're editing the markup. Point already made, though.

> Btw. the DocumentFocus interface in WA1 (section 11.3) also seem to 
> assume that focus is a propery of the document rather than the viewport. 
> Again I think its more correct to have it a property of the viewport.

   Yup, window.getSelectionRange it is, then...


From mattraymond at earthlink.net  Thu Feb 24 08:50:00 2005
From: mattraymond at earthlink.net (Matthew Raymond)
Date: Thu, 24 Feb 2005 11:50:00 -0500
Subject: [whatwg] [WA1] Markup for vCalendar and vCard
In-Reply-To: <Pine.LNX.4.61.0502241226420.25653@dhalsim.dreamhost.com>
References: <4215E89C.70303@earthlink.net>
	<6.2.1.2.2.20050218112823.0266cdb0@pop.mail.yahoo.com>
	<4219DAE3.8080604@earthlink.net>
	<Pine.LNX.4.61.0502211944160.32382@dhalsim.dreamhost.com>
	<421B55B9.4050007@earthlink.net>
	<Pine.LNX.4.61.0502221605480.12391@dhalsim.dreamhost.com>
	<421CB517.1030307@earthlink.net>
	<Pine.LNX.4.61.0502241226420.25653@dhalsim.dreamhost.com>
Message-ID: <421E05B8.1050906@earthlink.net>

Ian Hickson wrote:
> Boy did this get out of hand.
> 
> Matthew. I encourage you to send your proposals to this mailing list. The 
> e-mail you sent with your proposal is still in my queue, along with all 
> the other WA1 and WF2 proposals that have been sent and have not yet 
> received technical replies. It will be given the same consideration as all 
> the other proposals, including Tantek's and anything else I (or whoever 
> the spec editor is at that time) come across.
> 
> There is no conspiracy here.

    Give it up! I know it was you and Tantek flying over my house in a 
black helicopter last night trying to reprogram me with radio waves!

> Please relax.

    I find it's usually unwise to say this to someone who is truly upset. ;)

> The only reason I suggested 
> contacting Tantek is because I know he's been working on this topic, that 
> he has some very good ideas, and that he is welcoming feedback. I would 
> have thought that working with him on a proposal would have been more 
> productive than working on independent proposals. However, that was merely 
> a suggestion and was not meant to imply that other proposals would be 
> ignored or given a different level of consideration.

    Glad we cleared that up then.

> In particular, please don't think that I will be swayed by flashy 
> graphics, fancy markup, diagrams, or wiki-based development.

    I never meant to imply this. I was trying to avoid a situation where 
a section of the spec was being developed outside of WHATWG in a way 
that gave people unequal opportunity to express their views and opinions.

[Snip!]
> Also, progress on WHATWG specs is going at its own rate, and is not 
> controlled by progress on external drafts or proposals.

   That's what I wanted to hear.

> On Wed, 23 Feb 2005, Matthew Raymond wrote:
>>In fact, I've been asking for a WHATWG wiki for quite some time.
> 
> I don't have the resources to set that up, but if you want to set up a 
> wiki.whatwg.org site I could get you an account. However, I'm not really 
> sure what the point is. As far as I'm concerned this mailing list is the 
> most convenient way for me to handle input. I wouldn't monitor a wiki (or 
> probably even look at it) if one was created.

    I've had several situations where people didn't understand the ideas 
I was presenting because they were spread out over several emails. 
Often, someone would confuse a concept I was advocating with an 
older-but-similar concept I had abandoned. Take the following concepts, 
for instance:

  * <format>
  * <dateinput>
  * <date> (as an input control)
  * <idate>
  * <icomplex>
  * <dataentry>

    They're all closely related to each other. In fact, <dataentry> is 
pretty much the same as <icomplex>. If there was a simple wiki I could 
use to maintain my ideas about the general topic, I could simply post 
the URL at the beginning of a message rather than having to hunt down 
all my messages and giving a long explanation of what parts were relevant.

    If I can find a way to set up a wiki for WHATWG, though, you'll be 
the first to know.

>>Actually, you gave a specific time you'd be working on it...
>>
>>"I'm not planning on touching the relevant sections of WA1 until 
>>Tantek's drafts are much more stable."
> 
> I spoke ambiguously, my apologies. What I meant was that by the time I 
> next touched those sections, I expected Tantek's drafts to be much more 
> stable. (In particular, I am currently prioritising folding HTML4, XHTML1, 
> and DOM2 HTML into WA1, adding the section on the Window interface, and 
> speccing the new interfaces for networking and messaging. There is a LOT 
> of work there.)

    Oh, I know you're busy, and that it often takes you a long time to 
get to some portions of a spec. I objected to what I thought was you 
saying you wouldn't even look at anything until Tantek's draft ready, 
which appears to be a miscommunication at this point.


From ian at hixie.ch  Fri Feb 25 04:20:03 2005
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 25 Feb 2005 12:20:03 +0000 (UTC)
Subject: [whatwg] Introducing new elements is expensive
Message-ID: <Pine.LNX.4.61.0502251200130.16532@dhalsim.dreamhost.com>


I was just browsing through some of the proposals for WF2 and WA1 I've yet 
to respond to, and I noticed that several of them suggest introducing new 
elements.

While there are cases where new elements are appropriate, I'd like to 
encourage anyone making proposals to consider new elements to be very 
expensive. Introducing a new element:

 * Requires a new DOM interface.

 * Requires a lot of code to implement in native implementations.

 * Requires changes to HTML parsers, which is *very* hard.

 * Is a pain to implement in IE6.

 * Makes it a lot harder for authors to style the document in legacy UA,
   since the element doesn't appear in all legacy UAs, and not in the 
   same way when it does.

 * Makes it a lot harder for authors to navigate the DOM in script, as the
   elements have different index positions in the various DOM arrays.

I would recommend that suggestions avoid new elements, especially when 
those elements have a lot of attributes, and especially when the element 
has semantics very similar to an existing element.

Note that I consider the above problems to be a _lot_ worse than less- 
than-ideal fallback in legacy UAs. Speaking of fallback, I also consider 
it more important that legacy UAs get working fallback in all cases, thant 
that authors can provide ideal fallback if they want. My experience with 
the <object> element (which defaults to no fallback but allows for ideal 
fallback) is that authors rarely bother providing alternatives.

If you do introduce a new element, please include a detailed definition of 
the DOM interface that goes with it, along with definitions of each method 
and attribute on that interface. You should also include a detailed 
description of where the element can be placed, what can be placed inside 
the element, what each attribute does, what happens when the element has 
the wrong content, is in the wrong place, has the wrong attributes, or has 
attributes with the wrong values, and finally what the processing model is 
for when the element is correctly used. For an example of the detail you 
need, look at the definitions of elements like <base> in the WA1 spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From jim.ley at gmail.com  Fri Feb 25 04:56:50 2005
From: jim.ley at gmail.com (Jim Ley)
Date: Fri, 25 Feb 2005 12:56:50 +0000
Subject: [whatwg] Introducing new elements is expensive
In-Reply-To: <Pine.LNX.4.61.0502251200130.16532@dhalsim.dreamhost.com>
References: <Pine.LNX.4.61.0502251200130.16532@dhalsim.dreamhost.com>
Message-ID: <851c8d3105022504563c37481a@mail.gmail.com>

On Fri, 25 Feb 2005 12:20:03 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:

> * Is a pain to implement in IE6.

This is not true, implementing new elements is not a pain, other parts
of the spec are considerably harder, unless you can back statements
like this up, please don't use them, it makes the other statements so
much less believable.

As to all the information that you're saying need to be provided -
could you point to where that is in the spec for the datalist element?

Jim.