- From: Andrew Clover <and-py@doxdesk.com>
- Date: Thu, 10 Jun 2004 18:35:31 +0900
Peter-Paul Koch <gassinaumasis at hotmail.com> wrote: > First of all, when I read the (very interesting) position paper, it > struck me that every described feature can be implemented in > JavaScript Am inclined to agree. I would prefer not to standardise mechanisms that could already be implemented just as well using an appropriate client-side scripting library. However, I *do* like many of the proposed extensions, especially where they offer a reasonable level of backwards compatibility. For example the new form element types and restrictions give the browser the opportunity to present more polished interfaces, whilst still allowing older UAs to input text (because legacy UAs will typically treat an unknown or missing type attribute as the default 'text'). There are also some features here that couldn't currently be done with scripting, for example localised text and timezone support in date controls, and e-mail/uri selection. [BTW, 'expdate' should clearly be named 'month'; it is not explicitly a credit card expiry date.] Validation is something that can be done by script, but could benefit from a standard browser interface. I would like to see the 'validate' event on form do the 'alerting the user that the entered value is unacceptable' action in all cases, even manually calling .validate() from script. Required fields, input.labels, "Handling characters outside the submission character set", fieldset-disabled and the suggested addition of a way to include HTTP Authentication login/logout on a web page are also welcome. autofocus would also be good, if it's meant to only focus when the window itself has focus, ie. not steal focus from other windows. This can't currently be done from JS so I assume this is what it's for. Things I'm not especially keen on, OTOH: - repeating form controls. Seems a *lot* of added complication for something that can currently be done pretty easily with DOM (cloneNode etc.). The name-[]-hacking bit is especially nasty, a way of including literal square brackets seems to be missing, and id duplication inside the template seems not be catered for. - <output> seems pretty redundant, providing no functionality that can't currently be done just as well using styled readonly inputs or plain spans. - the FormImplementation method of remoting seems redundant. DOM Level 3 LS and XMLHttpRequest already cover this ground, I would prefer to see browsers standardise on either of these. - user-modify. I am VEHEMENTLY opposed to the IE model of being able to arbitrarily edit non-form elements. This proposal has all the disadvantages of contentEditable, without the advantage of actually being IE-compatible. Suggest instead: <textarea type="text/html">some <em>emed/em> blah</textarea> which would much better fit the current Forms model and would also be compatible with legacy and other browsers that cannot supply HTML editing facilities. Other MIME types might also be appropriate, eg. text/xml, or text/csv to get a full tabular data editor. > maybe except for the server sent events and the clipboard > api (but even in those cases it might be possible). Clipboard API I don't really want to see, given the problems IE's implementation of such brought up. A better standardised drag-and-drop interface would be great though, as doing it with mouse events and IE's proprietary events is annoying-to-impossible to get right all the time. I really like the idea of server-side events, though I would prefer to have them set up by a scripting call rather than an HTML element. I would be particularly interested in sending DOM Mutation Events down a wire to synchronise DOMs, especially if the client end could send addEventListener requests to the server end to specify what it was interested in. That's not strictly web application-related, but it'd be cool. > The point is that JavaScript is not 100% reliable. Sure, and for normal web sites or documents reliance on JS is highly undesirable. However with "web applications" (assuming we've decided what they are...) it is unrealistic to unexpect that their entire functionality could be implemented without any client-side scripting. So if scripting is going to be a bit necessary, it might as well be a lot necessary. > To me, [eBay and Amazon] are not applications but web sites I agree. That's not to say they couldn't evolve to include or be web applications, but their core functionality IMO isn't and doesn't need to be. -- Andrew Clover mailto:and at doxdesk.com http://www.doxdesk.com/
Received on Thursday, 10 June 2004 02:35:31 UTC