[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working
mattraymond at earthlink.net
Mon Jul 19 10:36:06 PDT 2004
Jim Ley wrote:
>> Considering you don't seem to be suggesting a better way to create
>>an emulation layer on IE,
> The alternative is simply not to use HTC's but straight script, it has
> a number of advantages:
> The arguments against are inline script and the hackish support of 1 event.
For the education of the readers of the mailing list, can you be
> The arguments for are lower security demands,
I presume you mean in XP SP2, which has not yet been released. This
also assumes that HTC support is turned off by default in SP2 for most
> provides the emulation
> layer on considerably more platforms and user agents, and you will not
> have any of the long list of problems with HTC's highlighted by Dean
> Edwards earlier in the list.
Here's the only message that I could find from Dean Edwards that
makes any kind of listing of problems with HTC:
In the message, Dean specifies the following as problems:
1) Path problems related to the location of the behavior files, which is
largely an annoyance rather than a serious problem.
2) Problems with servers mangling HTC files, which is correctable.
3) Uncertainty about how IE cashes behaviors.
4) Memory leaks, which seems to be a problem with IE JScript in general.
5) Crashes, which he says are far more likely in the testing phase.
Here's a later message he posts in reply to you:
"to implement the WF2's DOM extensions and to make use of things like
form validation, pretty much the only way to do it in IE is use
behavioral extensions. you could probably do a lot of it using pure
"this is an open specification. so anyone who wants to write a pure
This would suggest that for some of WF2, behaviors are the ONLY way
to go, but considering the age of the message, I'll leave it up to Dean
In a later message, it is fairly clear that Dean thinks HTC IS the
way to go and that he doesn't understand your opposition:
"can you outline your objections to HTCs? i am in touch with the IT
department of a huge company that has invested heavily in them (100,000
user intranet). although they have had some problems, it's my
understanding that they are not insurmountable.
> Dean has an awful lot of experience in scripting for IE and with
> HTC's, I do not believe any of the other members do, which is why I
> felt it relevant, if the others don't have the experience to judge if
> HTC's are a good decision or not, how was it made a requirement?
This assumes two things. First, you assume that other members don't
have experience with HTC, which may not be the case. Second, you assume
Dean, as a member, wouldn't bring the HTC issue back to the table if he
felt they made the wrong decision. I suspect that both your assumptions
>>what are your reasons for believing they have not considered
> That they came to an HTC is a requirement solution! (rather than this
> is the sort of tech we could use to provide emulation layers)
Your poor grammar prevents me from processing your statement.
>>>So it's the expectation of the WHAT-WG that users of Mozilla, Safari
>>>and Opera will get a severely degraded experience unless they upgrade
>> By that logic, all new features are a conspiracy to get everyone to
> No, features which degrade to a very much poorer state are, that's
> last ditch degradation, (like CSS and HTML, the content's all there,
> but you lose all the design) rather than graceful degradation.
You've been given every opportunity to suggest markup that
gracefully degrades as opposed to "last ditch degradation", and many
people have contributed to the specification other than the three people
who happen to be Opera employees. Near as I can tell, there is nothing
in this specification that is designed to force an UNNECESSARY upgrade.
>>>Well as I said before - it's one way to drive Opera sales.
>> Nevermind that you can get Opera for free if you're not bothered by
>>the small banner ad strip at the top.
> That's on desktops, unless something has changed radically, it's still
> a commercial only product on smartphones (where I use it, well try to,
> it struggles a bit on my hardware.)
Then do you have a suggestion about how new web forms and web app
standards can be implemented on such smartphones without software upgrade?
More information about the whatwg