[whatwg] Re: several messages

[Matthew Raymond]

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